软件工程第一次阅读作业
软件工程第一次阅读作业
浏览《构建之法》后的一些问题
1、关于结对编程的形式
关于结对编程，书中提到：
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。
...
总之，如果运用得当，结对编程可以取得更高的
投入产出比（Return of Investment）。
的确，如果以这样的形式进行结对编程，出现bug的概率会大大降低，也有助于遵守各种编程规范。但是，这样的方式无疑舍弃了“并行”的优势，尤其是在进行到逻辑简单，难度较低的部分时，出现bug的概率不高，若两人分工同时进行，无疑可以大大提升完成速度。我的疑问是，结对编程是否更适合在学习、培训过程中采用？在实际生产中结对编程真的能取的更高的投入产出比吗？
2、关于第六章中敏捷流程对于需求变化的欢迎
第六章中，对于敏捷开发的原则，提到：
- 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
需求的变化一直是乙方最为头疼的问题之一。我理解敏捷流程中通过快速迭代的方法来适应需求变化的原理，但是，对于那些已经定好、实现完成的需求的变化，仍然需要推翻原本的设计与实现，再进行更改。对于这类已经确认过、且实现完成的需求的更改，我认为多少是有些不合理的。那么在实际生产中，对于这种需求变化，也应无条件接受吗？或者说对于需求变化的欢迎的极限应该在哪里？
3、关于创新的问题
第16章中，部分人对创新想法的反馈中，有：
没有人需要这些方案
在实际中根本行不通
大众不会理解这个创新
在一个创新想法，尤其是一个颠覆性的创新、跨度较大的创新想法出现时，在当时的场景下常常出现“找不到应用场景”、“短时间内不知道有什么用”的情况出现，某种程度上也符合上述书中列举的理由。那么对于这样“短期内不知道能有什么用”的创新想法，应如何客观的评价其前景？应投入多大的时间、精力在其中？
4、创新者大多是非专业领域人士
同样在第16章，书中提到
这个想法看起来没什么错，我们不就是为了成为某个领域的专家，才来上学，拿学位，希望拿到学位之后成为专家，然后再开始这个领域的创新？但是统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。
那么作为计算机专业的学生，将来必然是“领域内”人士之一，那么如何避免形成如同“领域专家”的固化思维，导致自己的创新思维收到限制呢？
5、如何降低理解误差的问题
全书中多处提到，在团队合作中应多交流、多沟通，才能提到合作效率。这一点我非常赞同。但是在团队中的成员们相互沟通的过程中，对于一个问题，即使达成了共识，也常常因为每人的思维方式不同，导致双方心中的答案并不一致。书中提到的尽量面对面交流确实相比文字、语音交流的效果更好，但也不能避免这一问题的出现。那么有什么好方法能尽量降低理解误差，确保大家达成”共同意见“时，每个人脑中的理解都是相同的呢？
“软件” 和 “软件工程” 这些词汇是如何出现的
“软件”一词最早来源于John Tukey与1958年发布的论文The Teaching of Concrete Mathematics中。因此，认为是John Tukey发明了软件一词。
“软件工程”由女科学Margaret Hamilton在为阿波罗11号研制软件的过程中发明，目的是将软件工程与硬件或其他工程学类做出区分。
主流项目管理软件的使用人数、优缺点
根据网上资料，几款主流项目管理软件使用人数从多到少的排名为
1、GitHub
2、SourceForge
3、Bitbucket
4、GitLab
5、Assembla
在网上搜索了相关的信息如博客，知乎后，总结相关项目管理软件的优缺点如下：
- Microsoft TFS
- 优点：方便小团队对于需求、进度的掌握，集成了项目管理、版本控制、BUG追踪等功能，且与VS完美接合。
- 缺点：搭建复杂，硬件需求高
- GitHub
- 优点：功能极其齐全，方便交流合作
- 缺点：学习成本较高，需要通过较长时间的学习、熟悉后才能流畅使用各种命令
- Trac
- 优点：扩充性好，权限体系完备，较为灵活
- 缺点：不支持多项目，汉化不完整，中文支持较差
- Bugzilla
- 优点：免费，且有中文支持
- 缺点：只能管理缺陷，功能较少
- Apple XCode
- 优点：自动创建分类图表，撤回、重做、保存等常用功能使用方便，不需要命令、代码
- 缺点：在版本更新后，部分插件可能失效，导致诸多问题。
- Mercurial
- 优点：有revset，拓展性好，部署较为简单
- 缺点：强制向下兼容
