软件工程第一次阅读作业

一、阅读完《构建之法》后的问题

1、第二章中提到单元门测试应该由作者负责。可某些情况下，功能的开发者本身就忽视了一些问题，所谓盲区。在他编写的单元测试中，即使代码覆盖率达到100%，也是很难发现这些问题的。

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

​ 我部分同意作者的观点，但如问题中所说，对个人能否构造出发现自己错误的测试用例表示怀疑。

2、在软件工程师的成长中，通过项目的锻炼可以做到对成熟的领域熟悉乃至精通，但是如何做到对于全新的功能或项目做到有思路，有大概路线？

​ 该问题来自第三章中软件工程师的职业发展部分。读完之后，我认为要成为一个高级的软件工程师，需要的不仅仅是工作经验或技术，对于项目的整体把握和感知也是十分重要的。

3、在结对编程中，领航员的工作定位实际上有些模糊，如何避免领航员比较闲或者无法给出良好建议？

驾驶员：写设计文档，进行编码和单元测试等XP开发流程

领航员：审阅驾驶员文档，监督驾驶员对编码等开发流程的执行........

​ 我认为，在结对编程中，还是驾驶员起主要作用，领航员仅仅是辅助的作用，发现代码或者设计中的问题。假使两个人水平不一，比如领航员水平较高，还有可能提出大量的问题，反而耽误开发效率。

4、相较于瀑布模型，迭代式开发对可拓展性要求更高。如何保证迭代式开发能够在最初的版本就完成一个可拓展性较高的版本？

MVP-Minimum Viable Product,最小可行产品，具体做法是：把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见。

​ 我自己的编程经验不足，对于如何在保持高可迭代性的基础上开发一个demo版本并不是很清楚，我认为这也是迭代式开发的一个难点。

5、敏捷编程聚焦于最重要的任务，缺少细致的规划，是否会导致在后续的版本出现bug后难以回溯修复？

​ 根据书中所介绍的敏捷编程的内容，敏捷编程需要一个高效的团队在Scrum Master的带领下完成最重要的任务。但是以用户当前最重要的需求为导向来推进项目，是否会导致项目的修补比较多？缺少完整的项目文档的情况下不断迭代是否会导致bug难以被回溯？

6、用户的需求在实际情况下并不稳定，甚至经常中途更改需求，如何挖掘客户可能会产生的潜在需求并准备一些预案？

​ 阅读了第八章需求分析之后，想到之前实习时接触到的一个项目。客户对于前端的要求一改再改并不断提出新的需求，由于之前没有考虑到一些需求，后续功能添加变得十分繁琐，很多代码不得不推倒重来，深感挖掘客户潜在需求十分重要。

二、“软件”和“软件工程”这些词汇是如何出现的-何时-何地-何人？

“软件”一词最早由John Turkey与1958年在Princeton于“The Teaching of Concrete Mathematics”这篇文章中提出

“软件工程”一词由Margaret Hamilton在NASA为阿波罗登月项目工作时提出。

三、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

版本管理软件名称	用户数目（估计）	优点	缺点
Git	31,100,000	适合分布式开发，强调个体，服务器压力较小，快速灵活，容易解决冲突，离线工作	模式上比SVN更复杂，不符合常规思维，代码保密性差
Mercurial	未查证	系统简洁，拓展性强，分支模型优秀	跨平台兼容性差
Trac	未查证	扩充性好，权限体系完备，灵活，可以和TortoiseSVN集成	不支持多项目，功能太少
Bugzilla	未查证	不收费，有中文版支持	只能管理缺陷

四、软件工程冷知识与趣事

​ 第一个电脑游戏出现于1962年，由麻省理工学院的计算机程序员Steve Russell与其团队一同编写，这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船，目标是击中并摧毁对方飞船，并且玩家还需要躲避屏幕中代表星球的小白点。而这款游戏并未给他们带来任何收益。（链接：https://blog.csdn.net/l_mloveforever/article/details/83860547）