软件工程第一次阅读作业

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	个人阅读作业-阅读和调研
我在这个课程的目标是	学习现代软件工程开发的模式，提高团队协作能力
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》了解现代软工概念并调研源代码管理方法及CI/CD方法

阅读提问

问题1：事后诸葛亮会议的部分内容是否可以融入前面的每日例会

书中15.3节提到

一个里程碑结束了，接下来怎么办？团队有什么经验教训？产品怎么才能做得更好？我们常说“软件的生命周期”——这个软件开发的周期结束了，生命也结束了。我们能不能像医学的尸体解剖一样，把这个软件开发的流程解剖一下？解剖的过程可以叫：Postmortem，Retrospective，Review，事后诸葛亮会议，等等……

根据书中提到的项目回顾模板，其中部分问题出现的原因源于团队沟通不够全面，时间、分工安排不够合理等，而实际上这些问题在产品未发布时已经可以发现，若在平时的例会中对这些问题进行剖析及解决而非留到最后复盘，整体开发流程是否能够更顺利呢？

问题2：”小强地狱”中的阈值如何界定

文中11.5.5节中提到

如果开发人员的小强数量超过衣柜定制，则此君被送入“小强地狱”，在地狱中，他唯一能做的就是修复小强，直到小强数量低于此阈值。这一阈值游团队根据实际情况来确定，要注意：开发人员同时“入狱”的人数应在全体成员的5%-30%之间，若比例太高，则要考虑阈值或小强数量的计算方式是否合理（是否只包括某一严重程度以上的Bug）。在项目过程中，阈值不宜频繁调整，最好事先宣布阈值，然后每天早上每日例会宣布入狱/出狱名单。

小强地狱的初衷是在不影响整体功能的情况下，暂时忽略一些小问题，而将进度向前推。一方面，要使得项目仍能够正常推进，不能产生“大怪物”而造成投鼠忌器的下场，另一方面，又要保持“入狱”人数在全体成员的5%-30%不能太高，如此，Bug数目的阈值的界定便十分重要。我们是需要根据团队的能力进行设定还是根据Bug的修复难度、影响程度进行划分呢？

问题3：结对编程中驾驶员和领航者的角色互换是否需要如此高频

书中4.5节提到

驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。

结对编程最主要的目的还是通过两个人所写的代码不断处于“复审”状态从而提高设计质量和代码质量，及时发现并解决问题。若进行结对编程的两名成员水平差异较大，如书中所说，此时程序各方面质量取决于水平更高的那位，那么是否还需要频繁的交换驾驶员和领航者的角色呢？书中提出不要连续工作超过一小时的原因显然是为了避免长时间工作引起的效率下降，并保证二者对编码上享有平等的决策权力，但是对于水平更高的成员来说，如此是否会真的提高效率呢。或许让自己一直承当驾驶员的职务进行编写代码，能更快，更有效的完成整体开发，而为了结对编程而进行的角色互换此时是否还能取得所谓的更高的投入产出比？

问题4：是否存在又多又快有省的软件产品

书中9.3节提到

一个软件产品几乎无法同时做到又多又快又省。在别的领域也类似，中国在大跃进期间提出了多快好省的要求。最后只得到一个”多“——人多。

大部分优秀的团队可以做到三个目标中的两个：

多，快，但是不省

多，省，但是不快

快，省，但是不多

虽然说”鱼和熊掌不可兼得“，但是根据文中所述，似乎还是存在又多又快又省的软件产品，可否举几个例子？

问题5：公众利益的界定

书中17.8节软件工程师的职业道德提到

原则1 公众

软件工程师的行为应与公众利益一致

之前一款游戏《辐射76》中夹带私货，日常任务中出现唱着我国国歌的日常怪物，公然辱华，被国人一致抵制，显然该游戏开发商的行为是违背公众利益的。但最近俄乌冲突爆发，FIFA22紧急移除俄罗斯队，但俄乌双方孰是孰非我们暂时无法界定，游戏开发商此种行为是否可以视为违背公众利益呢？

调研源代码版本管理软件

Git管理工具的相同特点

• 代码审查

• Pull/Merge requests

• 内联编辑

• 问题跟踪

• 支持在线代码编辑

• 支持Markdown

• 双向认证

• 高级权限管理

• 托管的静态网页

• Fork/Clone Repositories

• 第三方集成

• 功能丰富的API

Git管理工具的不同点对比

	GitHub	GitLab	Bitbucket	Coding
开源性	项目开源但自己不开源	开源	不开源，但在购买托管服务的方案中提供了产品定制的功能	不开源，但开放了WebIDE的源代码
支持导入的代码仓库类型	Git,SVN,HG,RFS	Git	Git,SVN,HG	Git,CodePlex,Google Code,HG,SourceForge,SVN
免费计划	Free Plans容许托管无限的公有代码仓库，随时进行clone, fork 和 contribute，对磁盘使用没有限制。可是，项目不能超过 1 GB和单个文件不能超过 100 MB	Small teams plan 容许 5 个成员加入，公有/私有仓库均免费。当项目大快到达 1GB 时，会有邮件通知	cloud-hosted plan 容许无限数量的用户在无限数量的公共和私有项目上进行协做，而且每一个存储库有 10GB 的空间限制	免费计划容许 10 个成员在无限数量的公共和私有存储库上协做，但强加了 1 GB 的总体存储限制

调研持续集成/部署工具

Gitlab CI

感谢同组的fzc同学创建好了group并配置好了Runner，所以我只需要编写.gitlab-ci.yml上传便可进行CI测试，结果如图：

 

项目为简单的汉诺塔c语言实现

仓库链接：http://gitlab.oo.buaa.edu.cn/setest/xwq-ci

Github Action

编写.yml文件利用action的overflow进行测试，结果如图：

 

项目为汉诺塔python语言实现

仓库链接：GitHub - Sharp1129/action-test

Gitlab CI特点

• 作为Gitlab自带的持续集成解决方案，代码使用 GitLab 进行托管，Gitlab CI天然集无需额外配置，功能集成度较高

• Gitlab CI的触发为Git提交检索.gitlab-ci.yaml文件触发，其免去了第三方CI服务器对利用webhook定时请求Gitlab的压力

• 其构建包含构建日志，容易溯源追踪

• 其CI过程利用gitlab自带的邮件通知，不用额外配置通知

Github Actions特点

• actions可以作为CI/CD使用，但是它不只是CI/CD，本质上是一组docker容器组成的Workflow，可以完成包括CI/CD在内的许多自动化操作

• Github上提供很多action的集成插件，可以直接调用他人写好的插件，十分方便