软件工程第一次阅读做业

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

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

代码的做者最了解代码的目的、特色和实现的局限性。因此，写单元测试没有比做者更合适的人选了

​ 我部分赞成做者的观点，但如问题中所说，对我的可否构造出发现本身错误的测试用例表示怀疑。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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