软工个人阅读作业2 —— 构建之法与CI/CD

项目	内容
这个作业属于哪个课程	2021春季计算机学院软件工程(罗杰任健)
这个作业的要求在哪里	个人阅读作业#2
我在这个课程的目标是	阅读思考教材，调研软工工具
这个作业在哪个具体方面帮助我实现目标	泛读、提问、实践

Part1：阅读提问

Q1：单元测试与自动测评机相比有何优劣，能否在一定条件下被替代，或者说互补？

软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的板块定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能够得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。—— 2.1单元测试

该问题在我学习OO课程时就已经产生，即花费大量时间构造单元测试，不如直接使用脚本文件构建自动评测机，通过大量数据试错来避免人工编写单元测试，来覆盖全部分支语句的痛苦。因此从这个角度，单元测试似乎能被自动评测机完美替代？
但通过阅读教材，我找到了该想法的漏洞所在：

问：如果用随机数以增加测试的真实性，好么？
答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这个错误，则无济于事。我们还是要用随机数等办法“增加测试的真实性”，但不是在单元测试中。单元测试不能解决所有的问题，不必期望它会发现所有的缺陷。

即我体会到单元测试侧重于日常、高频率、小规模的检测，目的在于精确的定位一个小模块中错误的位置，它的局限性在于无法测试出由程序员自身错误思想造成的逻辑问题，e.g.漏写的代码。而所谓的自动评测机旨在通过对一个相对完整的项目进行整体评估，可以通过大量试错来判断整个代码是否存在逻辑漏洞，但缺陷在于无法准确定位错误位置，并且必须在代码已经完成较为完整的功能后才能测试，无法做到步步为营。
因此可见二者的优势与缺陷恰好互补，前者伴随着代码书写的全程，保证每步代码实现符合预期，后者则从整体的角度验证代码是否具有逻辑漏洞，适合项目后期的综合测试。

Q2：实践工程中使用Goto语句真的不会被同行吐槽吗？

函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

从刚刚接触计算机编程时，就被无数老师学长告诫过“禁用Goto”，因此我刚看到这句话时是十分震惊且疑惑的，毕竟巨擘Edgar Dijkstra在Go To Statement Considered Harmful也提到过，使用if...else + for/while 能实现全部的句间逻辑，因此禁用Goto能优化程序整体的质量与结构；同时联想到单元测试，不使用Goto也利于理解与查错。
但带众多高级语言中，对Goto的态度都大相径庭。Java尽管将Goto当作了关键字，但是禁用Goto语法，而C++/C#却支持Goto语法。
因此我的疑问是，除了书中提到的多重循环结构中使用Goto error;跳出，还有哪些合理且被业界同行所广泛接受且使用的用法？还是说要杜绝捡了芝麻丢了西瓜，直接明确禁止使用Goto？

Q3：良好的结对编程是团队合作完美进行的必要条件吗？

为什么这一节要讲这么多两人合作的反馈问题？因为，如果软件工程师连一对一的合作都做不好，不能有效地去影响同伴，让合作双方都能从合作中收益，提高水平，那大家就别扯什么团队合作这些事。 —— 4.6 两人合作

我认为该论据存在偷换概念的可能。即“一对一的合作”本身与"团队合作"就并非同一概念，施行方式也完全不同。根据前文提到的结对编程，一对一合作强调程序员双方对同一程序/项目，在同一时间，同一地点，轮流进行开发与审查工作，因此二者投入的时间精力期望十分接近，而这样就会导致如下问题：“倘若碰到大佬与萌新组队，可能会产生1+1<1的负面效果”即由于二者均需要对同一项目代码进行开发，因此大佬在书写代码的同时需要花大量的精力向萌新解释自己的“高级算法\高级思路”，同时萌新也无法提出有效的建议；并且多数情况下，大佬对萌新的代码可以说是~~深恶痛绝~~的，即极易出现萌新刚刚颤颤巍巍地敲出两行代码后，就被大佬以“代码格式不符合规范”，“内存申请太过于鲁莽”，“边界问题没有考虑”等等一系列问题为由打断，而纠正问题的时间成本难以计数，也无法保证以后不会再犯。
而后者——“团队合作”则不存在上述问题，因为在团队合作大多采取“按能力/技能分配任务”的原则，即会根据每个小组成员的能力与技术栈分配不同内容/不同任务量的工作。这样不仅能保证大佬的能力能充分的发挥，还能给予萌新循序渐进的缓冲学习期。

Q4：在老板驱动的模式中，既然可能存在领导未必懂得软件项目管理等问题，那是否有必要在职位晋升时将这些作为考核要求?

这种模式当然有它的问题：领导对许多技术细节是外行；领导未必懂得软件项目的管理，领导的权威影响了自由的交流和构造。—— 5.3.5 老板驱动的流程

排除走关系的可能，大部分公司的团队领导要么是从外企挖来的该领域的精英，要么是从本企业一步一步摸爬滚打上来的资深人士，因此至少在晋升领导前，他们在技术细节/软件项目管理等方面肯定不是一无所知的。那么问题可以更新为，”需要要求项目经理，或者说官僚模式中的小老板/中老板随时更新技术栈，并作为其能否胜任leader一职的考核指标吗？“

Q5：作为”卑微“的乙方，开发团队该如何面对变化无常的需求？

另外，很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。软件团队可以分析技术的发展趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。 —— 8.1.1 获取和引导需求(Elicitation)

这一部分书中描述的比较理想化，但并没有点明在实际项目开发时的代码组织层面，开发人员应该如何应对，因此会产生以下细节问题：

是该如文中所说，”推测用户可能产生的新需求“，在完成基本需求后抓紧空闲时间尽可能多的完成潜在的新需求，以备无患？
还是投入全部精力尽善尽美完成恰好够的代码，并等待重构？(尽管对于许多使用祖传代码的项目，重构的开销可能过于庞大)

为了解决上述问题，我通过查阅资料，找了一种可能的解决方案，即采用原型法(Prototyping Apprach)，其大体流程如下图，

其核心在于

获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。

Part2：调研源代码版本管理软件

1：Github

GitHub是通过Git进行版本控制的软件源代码托管服务平台，除了允许个人和组织创建和访问保管中的代码以外，它也提供了一些方便社会化共同软件开发的功能，即一般人口中的社区功能，包括允许用户追踪其他用户、组织、软件库的动态，对软件代码的改动和bug提出评论等。

2: Gitlab

GitLab 是由 GitLab Inc.开发，一款基于 Git 的完全集成的软件开发平台（fully 集成软件 development platform）。另外，GitLab 且具有wiki以及在线编辑、issue跟踪功能、CI/CD 等功能。

3：Bitbucket

Bitbucket是Atlassian公司提供的一个基于web的版本库托管服务，支持Mercurial和Git版本控制系统。

4：GitHub与GitLab对比

GitHub	GitLab
免费且代码开源	仅允许自己团队的网站开发人员对代码进行开发
免费方案下不允许在organiztion里建立仓库	允许用户免费在organization中建立仓库
GitHub中没有内置的CI，其Actions是由第三方供应商提供	Gitlab提供了100%的内置CI，并持续对其进行开发维护
根据用户的身份来验证其是否能使用该仓库	开发人员有权利决定谁有访问该仓库的权限
GitHub拥有一个极其庞大的开发人员交流社区。有上百万的活跃用户在Github上交流问题	Gitlab提供community event将项目贡献者与开源系统联系在一起
GitHub提供了一个平台去存储项目，并且提供了任务管理，bug追踪等功能	Gitlab提供了auto devops

5：相同点

都是基于web的Git仓库，均支持Markdown，支持双向认证
具有拉取请求，代码审查，内联编辑，高级权限管理等功能
均提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所

Part3：调研持续集成/部署工具

1：Gitlab CI

项目地址

Clone OO_2020_pre2_task0，使用maven创建项目，完成简单的junit测试单元
完成.gitlab-ci.yml，上传项目到仓库，触发CI

2：Github Actions