软工第二次阅读作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人阅读作业#2要求 |
| 我在这个课程的目标是 | 提高工程能力，成为一名真正的软件开发者 |
| 这个作业在哪个具体方面帮助我实现目标 | 了解真正的软件工程，学习版本控制与集成部署工具 |
阅读提问
1、单元测试中作者自己测试最好吗，单元测试使用随机数真的没有意义吗？
在《构建之法》第二章第一节中有这么一段话：
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。
如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，则于事无补。我们还是要用随机数等办法“增加测试的真实性”，但不是在单元测试中。单元测试不能解决所有问题，不必期望它会发现所有的缺陷。
作者认为单元测试需要由最熟悉代码的作者本人来编写。
在我自己写完代码的时候，我一般有两种状态，一种是十分不安，因为我在写的过程中用了一些自己不熟悉的算法数据结构或者我意识到一些地方好像需要对一些特殊值进行特殊处理，但是我在第一遍编写的时候没有进行这样的操作；第二种状态就是觉得程序应该没有什么大问题，一种比较自信的状态。对第一种状态，由作者本人来编写单元测试非常合适，理由也正是作者所说的那样，作者是最了解代码的特点和实现的局限性的人。但事实上对于编写较为简单的代码的基本单元，后一种状态可能更多一点，前面的状态可能更是由于功能的过于复杂或者集成度过高带来的。而对第二种状态，开发者往往很难自己找出漏洞， 开发者已经具有了思维定势，并且对于简单的基本功能已经胸有成竹，这个时候我觉得应该需要专业的软件测试人员来辅助进行测试，他人往往能想到很多自己想不到的地方，这样更能够找到bug。
不过真实情况下无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，所以往往软件测试的目的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。而大量使用专业软件测试人员会大量增加成本，所以如何有一个低成本的方法呢？我觉得就是随机数。
作者因为下次运行无法重复错误就否定随机数在单元测试中的作用。但是我觉得随机数测试程序所产生的错误数据完全可以记录下来增加到单元测试数据库中，从而保证可以复现与回归测试。
当然也有一种可能性是随机数的成本还是略高？单元测试的目的是快速的对一个基本的功能单元进行快速的基本测试。并不要求尽量找出所有bug，只需要保证基本的简单的功能正常执行即可，所以可能单元测试的目标就是简单测试所有路径，在单元测试的上层有更复杂的，集成度更高的集成测试，这一部分是需要重点测试的。
2、结对编程是否太理想化了
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等 .
结对编程看上去是个很美好的东西，两个人一起，角色不断互换，一起思考，一起解决问题。但是在实际的操作中，每个人都有自己独特的节奏，独特的风格，例如有人倾向于提前设计好整体架构乃至所有细节，而另一个人更倾向于直接去莽，在写代码的过程中不断改进，这样一起工作的话是不是会出很多问题？面对同一个问题，两人可能会有不同的解决的方式，而这两种方式并无优劣之分，只是各有特点，此时会不会因为风格差异问题导致合作出现问题？还有在"领航员"复审代码的时候，"驾驶员"会不会要不断的被打断工作节奏，不断的解释等等。
3、对于“小强”的处理
小强地狱（Bug Hell）。如果开发人员的小强（Bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他唯一能做的就是修复小强，直到小强数量低于此阈值。
个人觉得是不是对于每个bug，都应该在出现的时候分析一下，如果这个bug的修复不需要变动整个架构，是小问题，就可以记录下来之后修改，优先完成项目，如果是大问题就需要立即修改？而不是仅仅靠数目就去修bug？
4、复审相关问题
复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。
我觉得复审者还是需要尽量调查完全之后再提出一些问题，否则是不是很容易打扰到开发者？一些小问题可能只要再浏览一遍代码就可以很容易的明白，如果因为这些小事就频繁打扰开发者，会不会影响开发者的工作效率？
5、创新相关
但是在实际中，你会发现很多成功的企业进入了一个创新者的困境（Innovator'sDilemma）。当成功的企业步入中年，它们当年发迹的市场成熟了，当年赖以成功的创新技术成了主流的成熟技术，又叫“维持性的技术”，在成熟的市场和维持性的技术环境中，技术的创新并不是影响企业成败的主要因素。然而，颠覆性的创新会带来产品和市场的巨大风险，这些企业中的流程、价值观和文化会排斥颠覆性的创新。那些没有成功包袱的小公司反而能把颠覆性的创新带到市场，挑战成熟企业的霸主地位。
小公司确实能将创新带到市场，但我觉得创新的主体更可能是大公司，并且小公司很难通过创新去挑战成熟企业的霸主地位。大公司体量大家业也大，我觉得比较容易分出一小部分资源做出创新的尝试。并且新的市场如果有小的公司先去试水，发现效果不错，大公司也很容易通过其庞大的资源以及市场碾压小公司，从而将小公司的创新变成自己的“创新”。
源代码版本管理软件
这三者有许多相同的基础特点：拉取请求、代码审查、内联编辑、问题跟踪、Markdown支持、双向认证、高级权限管理、托管的静态网页、功能丰富的API、Fork / Clone Repositories等等。
- GitHub
- 他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。你可以通过Github评论，提交错误。在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。
- GitLab
- GitLab服务也是基于Git版本控制开发的。尽管GitLab功能与其主要竞争对手GitHub类似，但仍有一些主要特点。GitLab有几种不同的形式，如适用于企业的GitLab SAAS，以及用户的个性化解决方案GitLab Community Edition。Gitlab免费用户可以拥有无限数量的私有存储库。当然为了满足客户要求，GitLab也有企业版，在其基本功能之上增加了一些额外的功能，从而改善了与在线工具，工作流和服务器管理等的交互。错误跟踪和基于Web的代码编辑。与LDAP(轻量级目录访问协议)集成，允许在Internet上定位和访问各种资源。GitLab EE支持多种LDAP服务和组同步。支持Git导入.
- BitBucket
- BitBucket服务也非常类似于GitHub，但是它的大部分功能也略有不同。BitBucket最适合小型开发团队，随着团队的成长，BitBucket提供了与GitHub和GitLab相比更温和的定价条件。BitBucket还为团队提供了灵活的部署模式。BitBucket集成Jira工具。BitBucket和Jira在整个开发阶段都做了整合，通过集成的错误跟踪组件，JIRA自动更新有关检测到的问题的信息。
- 其主要的缺点在于不开源和系统不稳定。
持续集成/部署工具
Gitlab-CI
使用oo的pre2task0代码，重新写成maven工程的形式。代码库
- 简单的测试代码
- 在线编译测试结果
Github Action
与前面使用几乎相同的代码，代码库
- 运行结果
使用CI/CD工具后的感受
CI/CD可以及时的在push之后进行构建与单元测试，方便及时发现代码中的bug。
相比github，gitlab的优势是gitlab可以支持父子管道同时运行，配置可以划分成更小的子管道，而github没有管道编排，导致管道运行时间更长。
但是github提供了一个开源市场，可以轻松地找到第三方工具/插件构建的模板。