2022-BUAA-SE 第一次作业

2022-BUAA-SE 第一次作业

项目 内容
这个作业属于哪个课程 课程社区的链接
这个作业的要求在哪里 作业要求的链接
我在这个课程的目标是 了解并提高自己对软件工程的认识和实践能力
这个作业在哪个具体方面帮助我实现目标 架构层面能够使用先进的技术构建一个软工项目，流程上能够科学地依据软工的思想管理开发过程，实践上能够通过编写代码提高自己的动手能力

阅读作业

  • 问题1：老师提到团队角色中PM(Program Manager)是一定要承担具体的任务的，而且应该具有多重的能力：专业、交际、销售......但是对于学生团队来说，一个商业上的Rookie应该如何发现自己的PM潜力？（第五章-团队中的角色与合作）
    作为学生大家都是青涩的，面对软工课程上大部分都是阴差阳错组成的队友，如何在这样的条件下选拔出PM、DEV、TEST等角色？界限不是泾渭分明的，但是软工课也仅仅只有16周。
    从名人比如乔布斯的经历来看，好像他们天生就会包装产品一样，而不是像乔布斯的同伴一样只是作为一个开源社区的极客分享自己的想法。乔布斯天生就是一个具有魅力场的PM。以我的个人经验来看，做性格测试之类的也许是一条判断自己角色的方法，但从结果来看其实测试也并不完全准确，而且根据指标来定人不太合理。而且在大作业的经历中我们也常常被这个问题所困扰，故索性组成为小组长 -> 组员的简单层次结构，由project manager发号施令，这是一个比较烦人的问题。

  • 问题2：玄学的"code complete"

    什么叫代码完成（Code Complete[1]）？
    就是我们认为所有应该写的代码都写了，所有应该实现的功能都实现了。
    那就是可以发布了？
    不，代码都写了。但是代码中可能有很多小强，各个模块之间的合作还有很多问题。Beta用户看到产品后，说不定要提不少修改意见。但是，我们毕竟是把“我们认为所有应该写的代码都写了，功能都实现了”。这是一个了不起的事件。一个团队经过几个月的努 力，从无到有，从简到繁，把几个月前的远景变成了可以运行的软件，也许我们还有许多问题，但这无疑是很值得庆祝的！
    在TFS上，就是所有的代码任务（Task）都完成了。也许我们现在还有许多缺陷（Bug），还有一些与测试相关的任务。这些事情要留到以后稳定阶段才能全部解决。

    老师在第7章开发阶段的日常管理提到“所有应该写的代码”写完时就是"code complete"了，剩下的工作应当在稳定阶段才能解决。但我们在现实中常常遇到的问题是在规划时未曾想到的需求和功能常常使代码无法正常结束，过一段时间又想加一点“必要的功能”，会使开发阶段莫名的延长一段时间。由于主观和客观的原因，团队很可能在需求分析时并不能特别全面的看待问题，在scrum过程中突然发现了缺陷，以至于complete了，但没有完全complete的情况存在。

    招数: 砍掉功能
    有一个模块看来不能实现预期的设计需求，时间快到了，怎么办？
    砍！
    芸芸：可是我们花了很多心血才把设计做到目前的地步，好像再努一把力，就可以成功了。现在撤退，我真是不忍心呀，这不是浪费以前的投入么？
    果冻：对呀，我们可能只需要额外的三天，不，只要额外的三个通宵就可以了。再说我们可以以后接着修复任何新问题。
    阿超：这些话好像有理，但是细一想，都没道理。芸芸，你听说过 “沉没成本（Sunk Cost）” 这个词没有？没有的话，应该上网查一查，好好学学。果冻，从你做事的历史来看，如果类似的功能需要N个单位时间才能最终完成，那么我们没有理由相信新功能会花少于N个单位时间。
    如果砍掉了这些发生问题的功能，那么代码还能算complete吗？流程上，确实能作为一个产品发布，是“complete”了，但是从“我们认为所有应该写的代码都写了”其实又没有完成。把这种情况称为"code uncomplete"也许可以更能让团队铭记这些经验教训。

  • 问题3：有错不改的合理性

    微软的Excel日期存在闰年bug，但是大家并没有对这个错误进行修改
    1）几乎所有现存文件的日期数据都要减少一天，所有依赖于日期的Excel公式也要做检查和修改。这在现实生活中是很难办到的。
    2）Excel的日期问题解决了，但是其他软件还是有这个Bug，数据文件在不同软件中使用，就会有很头痛的兼容性问题。

    老师讲到因为很头痛的兼容性问题导致微软不敢也很难修复这个bug，也就是从成本角度来比较修bug与不修bug的利弊来做选择。但是如果不修这个bug，未来的预期只能是基于该bug产生越来越多的bug，为未来埋下一颗本可以拆除的炸弹。商业上来讲也许短期成本是合理的，但长此以往就会为微软的产品留下沉重的历史包袱（比如windows的底部任务栏、不统一的界面、为了适配而臃肿等问题），影响更长远的发展。相反，对于android开发，google就在逐渐“从头来过”，逐渐使用kotlin来替代历史包袱同样逐渐沉重的java语言，为未来打开局面。

  • 问题4：“解决问题”是不是技能的“反面”？

    Bill 说技能的反面是 ”Problem Solving” – “解决问题”, 这个听起来有点绕，我们看看IT 人士熟悉的一个例子吧。 一个IT 专业的大学生来面试, 简历上写“技能: 精通 Visual Studio C# 编程”。于是面试官请他实际用VS IDE 写一段程序 (冒 泡排序)。一个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。例如:
    嗯, 怎么开始一个C# 的命令行程序呢?
    定义数组是怎么弄的? 是“int [] arr”还是“int arr[]”, 还是 ArrayList，还是 Array 。哦, 我平时都是上网查的. 哦, 我不知道还有 MSDN 网站。
    嗯, 为什么编译没过呢, 哦, 这里少一个分号。
    嗯, 怎么设断点? 怎么定义命令行参数? 额, 我要查一查…
    你发现他把时间都花在“解决 (低层次) 问题”上了, 你想考察的“算法技能”、“C# 程序设计技能” 都无暇顾及。注意, 这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?

    作者通过面试的片段，佐证了Bill认为技能的反面是解决问题的观点。但是根据我经历的一些面试来看，面试官们对于（实习生/学生）来讲更喜欢提问智力和理解题，更看重你进入团队之后的发展，因为优秀的人理解力、对于知识的适应力都要更强一些。反而是对经验丰富但层次并不高的软件工程师更侧重于通过项目经历来衡量，对于他来说，通过他的项目就可以看出来这个人是否是一个称职的职员，通过他的技能熟练度可以看出他对工作是否上心。因此我认为，解决问题反而是一种很珍贵的能力，只有会解决问题，才具有了解决一切项目和业务的基本功。技能的反面应该是不熟练、懒惰等（也许可能是翻译的问题？）。

  • 问题5：单元测试与功能测试的区别？

    以下的测试术语主要是测试软件的功能。在表7-1所列的测试中，测试的范围由小到大，测试者也由内到外——从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。
    Unit Test 单元测试——在最低的功能/参数上验证程序的正确性
    Functional Test 功能测试——验证模块的功能

    我对这里的单元测试和功能测试的界限产生了困惑——看起来貌似是一样的。根据查阅的资料貌似区别在于测试的对象不同。

    功能测试是站在用户的角度从外部测试应用查看效果是否达到单元测试是站在程序员的角度从内部测试应用

调研源代码版本管理软件

  • 什么是版本控制软件
    版本控制软件通俗来讲就是帮助程序员更方便更科学更系统地管理自己所编写的代码版本以及更高效的完成代码任务合作的工具。在没有版本控制软件之前，程序员编写的大规模代码呈现出版本多、溯源难、协同编码易出现冲突等特点。源代码版本控制软件就是为了帮助程序员高效的解决以下这些繁琐的问题。(以git举例)
    • 备份文件： git add . | git commit -m ...
    • 记录历史: git log | git status ...
    • 回到过去: git reset --hard
    • 多端共享： git remote ...
    • 团队协作： git branch / merge / checkout ...
  • 常见的版本控制软件类别
    版本控制软件主要有CVS（Concurrent Versions System）、SVN（Subversion）、GIT三种。
    • CVS
      • 中心化设计：在一台服务器上建立一个源代码库，库里可以存放许多不同项目的源程序。由源代码库管理员统一管理这些源程序。每个用户在使用源代码库之前，首先要把源代码库里的项目文件下载到本地，然后用户可以在本地任意修改，最后用CVS命令进行提交，由CVS源代码库统一管理修改。这样，就好像只有一个人在修改文件一样，既避免了冲突，又可以做到跟踪文件变化等。
      • 无法并发提交：在传统的版本控制系统中，一个开发者检出一个文件，修改它，然后将其登记回去。检出文件的开发者拥有对这个文件修改的排它权。没有其它的开发者可以检出这个文件-- 并且只有检出那个文件的开发者可以登记所做的修改。
      • 不支持离线提交
    • SVN
      • 和CVS类似，SVN也使用中心化的服务器
      • 按文件存储每个文件的修改记录
      • 有全局版本号
    • GIT
      • 分布式的设计：每个仓库的重要性天生相同
      • 按元数据方式存储文件变化，更轻量
      • 切换分支方便
  • 常见的版本控制软件区别
    • GITHUB:
      • 无限的免费公开仓库空间
      • 有限的免费私人仓库空间
      • 流行程度更高
    • GITLAB:
      • 允许免费设置仓库权限
      • 允许用户选择分享一个 project 的部分代码
      • 通过 innersourcing 让不在权限范围内的人访问不到该资源
    • bitbucket:
      • 无限的免费公开仓库空间
      • 无限的免费私人仓库空间
        除此以外，我认为他们都是类似的基于Web的Git远程仓库，都提供了分享开源项目的平台，都提供了较为完整的wiki和CICD等项目介绍以及部署工具。但是GITLAB和bitbucket从代码的私有性来讲更好，GITHUB作为开源社区更理想。

调研持续集成/部署工具

  • 使用Github Actions在push时触发编译、测试、运行 代码库链接
    yaml脚本代码


  • 方便实用。对于没有接触过CI的我来讲，github actions为我提供了一台能够执行简单脚本命令的服务器，容易上手。同时具有良好的开源脚本库可以供我们选择使用。能够快速建立起一套CI/CD流程。

  • 技术上，github actions相比travis等老牌CI服务商，并没有特别巨大的功能领先，主要是凭借着强大的用户群体以及脚本复用市场，得到了用户深深的青睐。我认为更适用于小型项目以及快速上手。

  • 从使用体验来讲，gitlab ci和github actions除了actions market以外并没有太大区别，但是gitlab ci可能需要更多的用户配置（比如执行平台、runner等设置）因此我认为更适合中大型团队进行个性化的全方位配置。

  • Travis依托github的市场，能够自动抓取更新指定的多个仓库进行自动测试部署，适合拥有多个项目的大型公司或者开发者使用。

posted @ 2022-03-08 22:51  WuhuAirforce  阅读(74)  评论(2)  编辑  收藏  举报