Author: 17373015 乔玺华
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 系统学习软件工程，通过时间实现个人的进步 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读《构建之法》学习软工开发流程、开发建议，同时提出问题，进行反思 |
一. 对于教材内容的提问
《构建之法》在2.1.2节中提及
单元测试必须由最熟悉代码的人（程序的作者）来写
我承认这个观点存在优越性，代码作者必然是最了解代码各部分的功能实现，了解每一行代码的目的和局限性，而且单元测试有时候需要开发对代码进行部分重构才方便进行，开发自己做这些重构也比较顺手。
-
但同时我认为开发工程师自己编写单元测试存在一下几个弊端：
-
大部分的开发人员缺少优秀的测试思想，单元测试很有可能只是十分简单的测试样例，能够通过单元测试发现bug的几率极低，这样的单元测试更加倾向于形式而不具有实际价值。
-
开发人员有可能在编写程序的时候，就对某个知识点存在错误的认知，这也会导致他在编写单元测试时仍然带者错误认识，即无法编写出能够发现该错误的单元测试
-
开发人员写业务代码的时间就已经十分紧迫，缺少足够的编写优秀的单元测试的时间。
-
-
组内测试人员为开发人员编写单元测试存在以下优势：
-
测试人员编写的单元测试能够保证用力的覆盖和全面性，拥有丰富的测试经验以及发现漏洞的敏锐能力
-
编写单元测试能够帮助测试人员更加了解具体代码的架构、流程等，为日后的测试打下良好的基础。
-
Q2：结对编程中两人的角色是否需要不停的轮换？
《构建之法》4.5.4节中提及
驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟，领航员要控制时间。
在赛车越野比赛中，并没有出现过领航员与赛车手不断轮换的情况，这是因为赛车手擅长驾驶汽车，而领航员擅长分析比赛路线以及周围情况，做出准确及时的判断，在结对编程中，我认为亦然。只有当结对编程双方能力相近，擅长领域相似的时候，才存在轮换的可能性，而在大多数情况下，必然是一人水平高出另一人，且两人必然擅长各自擅长的领域而没有太大的交际，驾驶员-领航员模式下，若是让水平较低的一方担任领航员，很有可能最终的结果是水平较高的乙方分饰两角，而水平较低的一方只能干坐，被动的接受。这种情况对于编程效率的提高没有任何帮助。
Q3：敏捷开发是否需要优质的开发文档撰写？
我通读了《构建之法》第六章敏捷流程，其中的敏捷开发给我留下了深刻印象，敏捷开发讲究的就是高速和高效，每日都开例会（立会），但这一切似乎都是口头一些讲述，似乎并没有提及开发文档的撰写，是敏捷开发为了追求速度的效率，跳过了开发文档的撰写，还是说敏捷开发有一套专属的开发文档撰写方法？如果确实有，那么老师可不可以大致描述一下敏捷开发的开发文档与平时的开放文档有什么区别？若是没有，那么是不是该考虑增加开发文档的撰写，因为一旦有紧急情况发生，原来开发小组的人员出现了缺失，需要新鲜血液补充时，新来人员可能需要一份书面的文档才能更好的了解项目内容，项目进度等，而口头的描述可能会出现遗漏或口误，导致不必要的麻烦。
Q4：PM是否需要具有很强的项目相关的专业能力吗？
在阅读了《构建之法》9.5中PM的能力要求与任务后，我注意到作者提及
一个合格的PM，需要..
一定的专业能力
个人认为作为项目经理，不仅需要极强的沟通能力，必然需要能够了解项目全貌以及其中大致的实现方式的能力，PM个人需要有过编写项目的经历，如果项目相关的专业能力不够，如何在紧要关头判断出优先级，做出正确的判断；同时项目经理需要知道各种技术的实现难度以及是否能够实现，这样在与客户交谈的过程中，才能够进行有效的交涉，为客户提供令人满意的服务，同时也不会为项目组接来某种极其困难或是根本无法实现的项目功能，合理根据工作量进行分工协作，领导团队的人必然需要有一个全面的知识储备，具体的实现细节或许并不需要太过清楚，但大致思路需要个人有所了解。而书中并没有提及项目相关的专业能力，而仅仅是泛泛而谈了一下
PM的专业就是理解和表达
Q5：代码覆盖率测试是否具有实际意义？
《构建之法》13.2.2节中提及
100%的代码被执行了，是不是意味着再也不用写新的测试用例了呢？
答案是否定的。
若是代码覆盖率测试结果无论高低，都需要进行后续的测试，那么为什么要进行代码覆盖率测试呢？我在网上进行搜索后，得到的反馈并不能说服我，如是用来发现没有被测试覆盖的代码，但在构建测试代码阶段必然会针对每个区域进行测试，又何来没有被测试覆盖的区域一说；代码覆盖率可以作为测试自我审视的重要工具之一，但这样的说辞并没有太大实际价值，并且对于后续的测试也不会有实质性的帮助，甚至代码覆盖率高存在让测试人员提前满足的可能性，导致之后的测试被弱化，岂不是得不偿失。
二. "软件"和“软件工程”词汇的由来
软件
-
时间：1953年8月
-
地点：美国兰德公司
-
人物：Richard R.Carhart
1953年Richard R.Carhart在备忘录中使用software一词
软件工程
-
时间：1950年代
-
地点：MIT
-
人物：Margaret Hamilton
Margaret Hamilton为阿波罗11号飞行器编写软件系统时提出
三. 软件工程发展的过程中有趣的冷知识和故事
Python名字的由来
这是荷兰人Guido van Rossum 于上世纪80年代末设计的一个语言，现在非常流行，Van Rossum 在起名的时候，想要一些“短的、独特的、有点神秘色彩的”东西，他是英国著名戏剧团体Monty Python超级粉丝， 就从中找到了灵感，用Python命名了这门新语言，命名自BBC电视节目Monty Python's Flying Circus。
From Wikipedia
Java名字的由来
James Gosling、Mike Sheridan和Patrick Naughton在1991年6月发起了Java语言项目。Java最初是为交互式电视设计的，但是它对于当时的数字有线电视行业来说太先进了。最初，这种语言被称为“Oak”，取自Gosling办公室外的一棵橡树。后来这个项目被命名为Green，最后被重新命名为Java，来自Java Coffee，爪哇咖啡来自印度尼西亚。
From Wikipedia
四. 源程序版本管理软件和项目管理软件
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）
| Name | Users | Projects |
|---|---|---|
| GitHub | 31,000,000 | 100,000,000 |
| Bitbucket | 5,000,000 | Unknown |
| Launchpad | 3,965,288 | 40,881 |
| SourceForge | 3,700,000 | 500,000 |
| GitLab | 100,000 | 546,000 |
| GNU Savannah | 93,346 | 3,848 |
| OSDN | 54,826 | 6,294 |
| Ourproject.org | 6,353 | 1,846 |
From Wikipedia
优缺点
Git
-
简介：Git是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL发布。最初目的是为更好地管理Linux内核开发而设计。
-
优点
-
Git分支的本质是一个指向提交快照的指针，速度快、灵活，分支之间可以任意切换。都可以在本地进行操作可以不同步到远程
-
离线工作，如果git服务器出现问题，也可以在本地进行切换分支的操作，等联网后再提交、合并等操作。
-
冲突解决，多人开发很容易就会出现冲突，可以先pull远程到本地，然后在本地合并一下分支，解决好冲突，在push到远程即 可
-
-
缺点
-
Git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。
-
工作目录只能是整个目录，而svn可以单独checkout某个有权限的目录。
-
学习成本较高，初学时比较简单，但一段时间使用后会感觉内容较多，存在难度
-
Mercurial
-
简介：Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于GNU General Public License (GPL) 授权的开源项目。
-
优点：
-
Mercurial 的文件对于新手来说相对完整与容易阅读，Mercurial 的用词与指令也比较接近Subversion 与CVS ，因此对于从那些系统转移的人们来说会比较亲切。
-
支援Windows，Mercurial 是使用Python 开发，而且正式版本在Windows 下执行顺畅(在Linux, Mac OS X 等系统也是)。
-
记录是不容侵犯的，Mercurial 的资料库结构比较像是不可变物件持续成长的集合。
-
五. 版本管理软件实践
Git
Mercurial
感想