构建之法——个人阅读作业2

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	个人阅读作业#2
我在这个课程的目标是	认真完成课程要求并提高相应能力
这个作业在哪个具体方面帮助我实现目标	了解构建的理论知识，并尝试使用持续集成/持续部署工具

一、阅读提问

1.第1章中提到了Cocomo模型，认为某种项目的时间花费遵守公式

​ \(Person*Month=2.4*KLoC^{1.05}\)

其中的\(KLoC\)表示一千行代码。查阅资料可以发现实际上的Cocomo模型远比此公式复杂，但是作者给出这样的简化公式应该是基于一定的考虑。

不过如果仅从作者给出的公式出发，根据软工课程要求，平均每人大概2000行代码，如果一个团队用5个人计算，按照此公式可以得出完成任务大概需要27人月，即需要5个月左右才能完成。实际上课程所给时间远比此时间短，但是往年的同学仍然很好地完成了课程任务。那么这是因为作者给出的这个公式有问题，还是说由于我们的课程远比实际中的软工要简单，因此可以将时间大幅缩短呢？

2.第6章中提到了敏捷流程，作者提出了一些同时也是我想问的问题(并且没有解答)，即任务是靠成员认领的，就免不了会出现任务没人认领、任务和能力不匹配等情况(应该说这种现象在我们之中很常见，将来的开发过程中多半也会碰到这种情况)。这时候应该怎么办？

3.在第4章里作者提到当有助于程序逻辑的清晰体现时可以使用goto语句。但是现在许多人都支持“goto有害论”，认为goto完全可以被替代，任何时候都不应该使用它。我认为如果goto语句确实可以让逻辑更清晰，用goto也无妨，但“逻辑清晰”并不好定义，因为我们在写代码时有很大可能是因为用goto更简单所以就使用goto，这样未必能保证逻辑更清晰(甚至可能会使结构混乱)。在我看来，goto一旦使用不当，会对代码结构造成很大的影响。因此是否对goto的使用进行严格限制(或干脆不使用)会更好一些？

4.在第6章和第8章等地方作者都有谈到对任务完成时间的估计，这样的估计是基于团队内部状况而进行的估计。本学期我选修的一门课程《信号处理与信息推断》指出这种估计称为“内部视角”，其往往是很不准确的。例如格力手机，董明珠估计一年销量为一亿台(被问及原因时，董明珠列举出了类似“我们掌握核心科技、质量有保证”等原因，这是一种典型的内部视角)，然而实际销量却惨不忍睹。同理，我们在软件开发时用这样一种纯内部视角来估计时间，会不会造成严重失误呢？

5.第9章中提到了项目经理，项目经理的责任很大，能力要求也比较高。那么对于几乎都没有什么经验的我们来说，在软工课中谁来担任这个角色呢？或者说，如果大家都认为无法担当项目经理的角色应该怎么办？或者说，我们的软工课程由于有一定的简化，是否可以不需要项目经理？

二、调研源代码版本管理软件

这里主要说一下github、gitlab、Bitbucket。

由于定位都一样，三者在主要功能方面并无多大区别。例如都有拉取请求、代码审查、内联编辑、问题跟踪、Markdown支持、双向认证、fork/clone等功能。

github是目前全球最大的开源社交编程及代码托管网站，有着众多的用户和巨大的开源库。对于协作项目来说github是最佳的选择。其限制项目不能超过 1 GB且单个文件不能超过 100 MB。

gitlab有开源版本，适合自建系统且其私有库免费，但其只支持git。从其他软件导入可能会有些麻烦。

Bitbucket是唯一支持Mercurial的，但其使用人数并不多，而且UI设计比较迷惑。

三、调研持续集成/部署工具

Gitlab CI

采用OO课程第三单元第一次作业的内容，并在本地用Maven重建，写好单元测试并和yml文件(实际上yml文件就是照搬了样例的文件)后进行提交，触发相应脚本。仓库在这里。最后结果如下：

配置Runner的灵活性较大，可以比较方便地部署在服务器上。

Github Action

用相同的工程，修改yml文件(虽然我把原先的yml也一起commit了，但并不起作用)并按照官方文档的格式编写maven.yml，可以看到顺利通过：

仓库在这里。

依托于github，Github Action也可以自定义并方便别人复用，由此可能会产生很多有意思的点子。

个人关于CI/CD的看法

持续集成/部署的精髓就在于自动化。由于可以自动执行预先要进行的操作，对于项目的测试、管理等就会方便许多，也解决了代码合并时的诸多问题。这样，开发人员和测试人员就不必把较多的精力放在集成问题上，可以节约人力和物力。

不过对我个人来说，第一次接触CI/CD，并看不出两者的差异和适用范围。但是相关对比可以参考这里。