软工第二次阅读作业

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰任健）
这个作业的要求在哪里	个人阅读作业#2
我在这个课程的目标是	完整的体验一次软件开发，和同学合作做出一个有用户的软件项目；在开发过程中学习工程化方法；在体验中明确自己的想法与目标
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》，系统性的初窥软件工程；调研并使用持续集成和持续部署工具，为后面的软工学习和训练打下基础

阅读提问——阅读《构建之法》之后

1. 单元测试谁来写？

单元测试必须由最熟悉代码的人（程序的作者）来写。

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

——2.1.2 好的单元测试的标准

作者认为单元测试最好是由程序作者来写。但是我认为仅由代码作者来写单元测试实在是存在很大的局限性。首先需要明确的是，单元测试是为了让自己负责的模块功能定义尽量明确，以及模块的质量能够得到稳定的、量化的保证。而往往程序的作者在构思和编写代码时就已经定型了大致的流程和细节，那么无论是在编写程序还是在构建单元测试时，往往会有高度一致的思路，换句话说就是如果程序作者在最初未考虑周全的地方，那么往往会一直受限无法弥补之前未思考周全的地方。就好比一个厨师按自己的想法做了一道菜，然后自己尝试感觉很不错，但是给顾客或者同事品尝时，虽大体口味一致，但难为会有一定的辅料是厨师为考虑到的。因此，除非是程序作者要求调用模块的人只能按照自己的思路调用之外，最好是不仅要程序的作者来编写单元测试，更需要团队中和此作者开发相近的其他人来辅助编写单元测试，这样或许才能最大程度的保障达到单元测试的目的。

2. 结对编程中角色互换

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

——4.5.4 如何结对编程

按照作者的说话，驾驶员和领航员之间的角色应该进行频繁的轮换，但是我认为如此频繁的轮换是否会影响正常的程序编写的进行？驾驶员主要进行编码和单元测试，而领航员主要进行审阅文档，设计测试用例等相关事项。从我自身而言，一个小时或许是编码刚刚上头的时候，也是代码编写最顺手的时候，此时如果中断并且更换职责和任务，那么思路将会被打断，且再回来继续进行编码时会需要时间来重新"找感觉"，会造成一定程度上的不必要的损失。因此，对于驾驶员和领航员而言，驾驶员在编码上刚刚渐入佳境就被打断，职责和领航员进行交换，对于驾驶员而言，编码的感觉被打断，等一段时间之后在上手编程就又需要时间来缓冲，有一定的时间损耗。其次，二人的编码习惯会有一点的差异，如此频繁的交换编程，或许会造成代码在细节上产生差异，反而会产生不好的结果。

3. 推动信息共享与沟通

第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当人，对牵涉到的技术机密、安全性等信息要采取必要的保护措施。

——7.2.1 推动信息共享与沟通、

作者在此部分提出在项目开发时所有的信息都要保留下来，甚至是自己修改的低级bug也要保留下来，以便共享和学习所有的经验。我的问题就是真的有必要去保留所有信息吗？首先，一个项目，多个开发人员，多次开发和修改必定会产生极为大量的信息，不可否认的是信息必定会有很多重要信息，但是同样也会包含大量的冗余的信息，例如，我今天修改了这个“笔误”，他明天也修改了一个“笔误”，这些信息的存在是否会有使信息冗余使总结复盘工作量无意义的增加的嫌疑呢？其次，文档、交流、决定等基本就用于团队的不断迭代开发查阅上，团队项目总结上，或许也需要给用户一份实时的总结文档，那么我们是否应该对所有的未经过处理的记录进行一系列的总结，以便更轻易和系统来分析和总结项目，而不是去翻阅以往所有的记录，这是否存在浪费时间的嫌疑？然后，信息的共享和沟通，也会用于给后来的同事学习经验，相比于一份完整不加以处理的信息，经过总结和归纳的文档或者说信息是否会更好，以及是否会带来更高的效率呢？所以我觉得或许经过分析和总结删除掉同类型和无意义的信息后的文档或许或是一个更好的选择。

4. 典型用户

我们宁可从小部分人出发，要非常明确地定义谁是我们的用户。

——10.1.3 怎样定义典型用户

我赞成作者所说的软件不是为所有人服务的，那么考虑用户群体就是一个非常重要的问题。一款软件，一款带有商业和盈利性质的软件，从商业的角度来看，当然是用户群体处于一个较广阔的范围最好，以保证最大的收益。即使是一款针对特定用户群体的软件，用户群体有一定的范围，但是我认为也不至于到作者所说的小部分人的程度吧。毕竟软件的评价包括这款软件的商业价值，从小部分人出发而瞄准的用户群体真的能够带来较大的商业价值吗？

5. 赢者通吃

这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。

——16.2 创新的时机

虽然在软件这个行业竞争激烈而且残酷，但是真的已经是到了一种赢者通吃的环境下了么？中小型创业者几乎不可能出现通吃某个巨头公司在相同方向上的产业吧，亦或者说赢者通吃，巨头公司能够扫荡某一方向上的所有中小创业公司，那么中小型创业公司出路又在哪里？

调研源代码版本管理软件

GitHub / GitLab / Bitbucket相同点：

均基于git进行代码管理；
均能够fork和pull request；
具有issue追踪的功能；
能够编写wiki文档；
提供功能丰富的API；
支持代码片段分享；

不同点在于：

	GitHub	GitLab	Bitbucket
版本控制系统	仅有git	仅有git	Mercurial和git
免费情况	Free Plans允许托管无限的公有代码仓库；但是项目不能超过1GB和单个文件不能超过100MB。	cloud-hosted允许无限数量用户在公共和私有项目上合作；但是每个存储库有10GB的限制。	无限制的所有仓库个数；无限制的磁盘空间；Small teams plan允许5个成员加入。
私有性		开源，支持搭建私有的gitlab服务，确保数据安全；私有性更好。
适用对象	均适用	均适用，尤其对于注重代码私密性的企业和个人适用	一般用于小型团队；依赖Bitbucket其他项目的大型团队也适用