个人阅读作业#2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 学习软件工程基础知识以及培养软件开发能力和项目组织能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 对软件开发流程有基本的了解； 学习用CI/ID进行项目的集成与部属 |
P1 阅读提问
Q1 单元测试必须由作者本人来写吗？
代码的作者最了解代码的目的、特点和实现的局限性。所以,写单元测试没有比作者更适合的
人选了。——《构建之法》p25
作者认为，代码的作者对代码是最了解的，相较于他人对这一块的代码所表达的含义以及功能的认知程度更高，因此更容易利用代码的特性去构造更加合适的测试样例。
诚然，我在这方面与作者的观点一致，既然程序员有责任编写功能代码，同时也有责任为自己的代码编写单元测试，但是作者的说法似乎欠缺了一点，单元测试应该不仅仅由作者本人来写。
单元测试的目的是检测被测代码在特定条件下的行为是否正确，是为了证明这段代码的行为和我们期望的一致。不过这里的“期望”究竟是指谁的期望呢？显而易见的是，程序员编写这段代码的目的是为了交付任务，也就是去满足他人所提出的要求，所以这里的“期望”理所当然的应该是需求者的“期望”。可是程序员在设计的时候，可能会由于考虑的不太周全而导致自己所认为的“期望”与需求者的“期望”有所偏差。那么在进行单元测试的时候，程序员所提供的测试样例也仅仅只能用来测试该单元与自己的期望一致，也就是只能测试到自己考虑到的部分，而其它特殊的情况或者一些边界条件其实并没有覆盖到，显然这样的单元测试是不符合要求的。因此除了由本人进行测试外，还应当有更加了解需求方的测试人员去进行一些额外的测试，从而弥补代码作者所没有考虑到的部分。
Q2 单元测试理应覆盖代码所有路径吗？
单元测试应该覆盖所有代码路径
单元测试应覆盖所测单元的所有代码路径,包括错误处理路径。为了保证代码覆盖率,单元测
试必须测试公开的和私有的函数/方法。——《构建之法》p27
作者认为单元测试应该覆盖所有的代码路径，可是凭借我们的经验而言，代码容易出错的地方往往是具有转折特性的部分。若代码中某一结点后面的所有分支意义相近，例如switch-case语句，其实我们只需要测其中一条普通分支以及具有转折意义的default分支即可，这两种路径在这一部分的测试中足够具有典型意义，没有必要为了所谓的覆盖率而对每个switch的分支都去建立一个测试样例，这样做显然是冗余且耗费时间的。
Q3 SCRUM方法中靠时间驱动冲刺阶段真的很高明吗？
冲刺阶段是时间驱动的(Time- boxed),时间一到就结束。这个特点看似不起眼,但其实它有
效地断了各种延期想法的后路,很高明。——《构建之法》 p117
SCRUM的敏捷开发方法给我展现的是一个高效的、目的明确的、专注的软件开发方法，它将程序员的专注力最大化，让其在某一段时间内以最高效的方式去解决某个问题。我很是敬佩这个方法的高明之处，因为它确实是一种很高效的方法。但是我对“时间一到就结束”这个说法还存有疑虑。
对于有些任务，完整的实现与还差一小部分便能完成（从代码量的角度上考虑，而不是功能性），其结果所能提供的功能有可能是截然不同的，甚至可能由于就只差一点点部分，而导致整个系统无法使用。倘若有一部分人的工作在规定的时间内未能完成，这会对下一次任务的分配或者计划的安排产生较为严重的影响。因此我认为冲刺阶段的结束的标志应当不止有时间，还应该包括此次任务的完成程度。如果某一个人负责的关键部分还差一小部分完成，应当让其冲刺直至这部分完成。虽然这样做不如作者所说的“时间驱动能够有效的断了各种延期想法的后路”，但是给未来带来的帮助是巨大的。
Q4 PM与开发和测试人员所负责的任务应当独立么？
PM做开发和测试之外地所有事情
——《构建之法》 p194
PM诞生之初的意义就是为了解决客户需求与软件实现不匹配、团队之间配合不匹配等问题，第一个成功的PM也是作为开发人员的程序员。
有些时候美好的设想往往会与实际的成果有所出入，一个软件框架的设计也不仅仅只依靠一本规格说明书而决定。倘若PM与开发测试人员只是单纯的各司其职，势必会存在信息不平等的地方。比如当前的框架虽然能满足现有的需求，但是否能具有更好的可拓展性？就算具有拓展性也是否能够更好的针对未来应有的需求？对于这些问题的解决需要开发人员对用户需求以及市场情况具有更加深刻的了解；同样的PM所设计的规格说明是否更加有利于实现？不同形式的说明是否会对软件的开发过程产生较严重的影响？由于PM与开发人员的信息不平，才会导致双方在施展工作时产生这些问题。因此PM需要参与到宏观层面的软件框架设计，同样开发人员的leader也要参与到客户需求的分析以及产品的调研，从而让软件变得更加可用与有用。
Q5 创新人士的关键特点真的是“屡败屡战”么？
从以前开始，成功人士都会以“我只不过是更勤奋”、“我只不过是更加坚持不懈”等口吻来宣扬自己的成功经验，虽然这种”鸡汤“式的发言确实能够调动起大家的情绪，给大家一种”只要你付出的更多，你也能做到“的错觉，从而获得大多数人的认可，但是这样做真的有用么？真的只用凭着一腔热血埋头苦干就能获得相应的成功么？如果是这样的话，那烈日炎炎下的播种的农民，挥洒着汗水的建筑工人，哪一个不比我们有着更加强烈的意志力？为什么他们就不能获得相应的名气，冠以”成功人士“的头衔呢？（这里扯远了）
因此书中所说的”创新人士的关键特点是屡败屡战“这句话是不准确的。这些创新人士是如何分析失败的？通过何种途径准确的搜集到了失败的信息以及从哪些角度分析了失败的原因？获取并分析了失败的原因后，他们又从哪些角度改善了自己的想法？
上面只是针对于有过失败经验的团队来说。那么没有失败过，出道即巅峰的团队呢？他们在做每一个项目前怎样做到了缜密的分析？上海米哈游公司从第一步游戏《fly me 2 the moon》到《崩坏学园2》,到《崩坏三》,再到《原神》一步步走向成功与闻名，但是他们真的有不断地经历过失败，不断地”屡败屡战“么？他们的每一代游戏无论是画面还是技术（除了策划）的成长都是有目共睹的，但是透过光辉的表象，他们内部所处理的细节，所考究到的地方，一定是数不胜数。对于这一类成功典型，不是”屡败屡战“造就了他们的成功，而是在失败前，他们就已经做了足够多的准备去规避失败。
所以仅仅用”屡败屡战“去涵盖创新人士、成功人士所付出的努力，显然是不负责任的。创新人士的”成功“特点应当渗透到了每一处，而这才是我们应当学习的。
P2 调研源代码版本管理软件
GitHub、Bitbucket、GitLab 都是基于git做版本控制的代码托管平台，都具有如“拉取请求”、“代码审查”、“内联编辑”、“问题跟踪”、“双向认证”、“第三方集成”等特点，同时他们也各自具有独特的特色。
Git通过非线性开发历史的可视化工具和导航工具的帮助，支持流畅的版本合并和分割，有很多令人称道的功能，如“快速搜索”、“社区交流”、“项目共享”等特点，但GitHub所有的服务并不是免费的，同时具有文件大小限制。
gitlab完全免费，用户可以拥有无限数量的私有存储库 ，同时也有适用于企业的GitLab SAAS，以及用户的个性化解决方案GitLab Community Edition。不过界面相对较慢，也会有存储库常见的技术问题等。
BitBucket最适合小型开发团队，随着团队的成长，BitBucket提供了与GitHub和GitLab相比更温和的定价条件。BitBucket还为团队提供了灵活的部署模式。 但系统比较不稳定，而且项目不开源。
P3 调研持续集成/部署工具
3.1 GitLab CI实践
项目地址：https://gitlab.buaaoo.top/2021_SE/oo_firstHomework
build与test结果如下：
项目build输出如下：
3.2 Github Acitions实践
3.3 比较与总结
GitLab CI/ID和GitHub Actions都提供了持续集成、持续部署的功能，使得集成新代码时许多流程都采用自动化的方式实现，不需要让程序员过多的关注这些部分，从而提升了工作的效率。Gitlab CI/ID的语法更为清晰简洁，而GitHub Action的语法比较繁琐。不过GitHub Action支持许多开源的插件，因此更适合灵活应对一些常见的任务。
