软件工程第一次阅读做业

软件工程第一次阅读做业

浏览《构建之法》后的一些问题

一、关于结对编程的形式

关于结对编程，书中提到：

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工做。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一块儿工做。他们一块儿分析，一块儿设计，一块儿写测试用例，一块儿编码，一块儿作单元测试，一块儿作集成测试，一块儿写文档等。

...

总之，若是运用得当，结对编程能够取得更高的
投入产出比（Return of Investment）。

的确，若是以这样的形式进行结对编程，出现bug的几率会大大下降，也有助于遵照各类编程规范。可是，这样的方式无疑舍弃了“并行”的优点，尤为是在进行到逻辑简单，难度较低的部分时，出现bug的几率不高，若两人分工同时进行，无疑能够大大提高完成速度。个人疑问是，结对编程是否更适合在学习、培训过程当中采用？在实际生产中结对编程真的能取的更高的投入产出比吗？

二、关于第六章中敏捷流程对于需求变化的欢迎

第六章中，对于敏捷开发的原则，提到：

1. 敏捷流程欢迎需求的变化，并利用这种变化来提升用户的竞争优点

需求的变化一直是乙方最为头疼的问题之一。我理解敏捷流程中经过快速迭代的方法来适应需求变化的原理，可是，对于那些已经定好、实现完成的需求的变化，仍然须要推翻本来的设计与实现，再进行更改。对于这类已经确认过、且实现完成的需求的更改，我认为多少是有些不合理的。那么在实际生产中，对于这种需求变化，也应无条件接受吗？或者说对于需求变化的欢迎的极限应该在哪里？

三、关于创新的问题

第16章中，部分人对创新想法的反馈中，有：

没有人须要这些方案

在实际中根本行不通

大众不会理解这个创新

在一个创新想法，尤为是一个颠覆性的创新、跨度较大的创新想法出现时，在当时的场景下经常出现“找不到应用场景”、“短期内不知道有什么用”的状况出现，某种程度上也符合上述书中列举的理由。那么对于这样“短时间内不知道能有什么用”的创新想法，应如何客观的评价其前景？应投入多大的时间、精力在其中？

四、创新者大可能是非专业领域人士

一样在第16章，书中提到

这个想法看起来没什么错，咱们不就是为了成为某个领域的专家，才来上学，拿学位，但愿拿到学位以后成为专家，而后再开始这个领域的创新？可是统计数据代表，70%的创新者说，他们最成功的创新，是在他们的拿手领域以外发现的。

那么做为计算机专业的学生，未来必然是“领域内”人士之一，那么如何避免造成如同“领域专家”的固化思惟，致使本身的创新思惟收到限制呢？

五、如何下降理解偏差的问题

全书中多处提到，在团队合做中应多交流、多沟通，才能提到合做效率。这一点我很是赞同。可是在团队中的成员们相互沟通的过程当中，对于一个问题，即便达成了共识，也经常由于每人的思惟方式不一样，致使双方心中的答案并不一致。书中提到的尽可能面对面交流确实相比文字、语音交流的效果更好，但也不能避免这一问题的出现。那么有什么好方法能尽可能下降理解偏差，确保你们达成”共赞成见“时，每一个人脑中的理解都是相同的呢？

“软件” 和 “软件工程” 这些词汇是如何出现的

“软件”一词最先来源于John Tukey与1958年发布的论文The Teaching of Concrete Mathematics中。所以，认为是John Tukey发明了软件一词。

“软件工程”由女科学Margaret Hamilton在为阿波罗11号研制软件的过程当中发明，目的是将软件工程与硬件或其余工程学类作出区分。

主流项目管理软件的使用人数、优缺点

根据网上资料，几款主流项目管理软件使用人数从多到少的排名为

一、GitHub

二、SourceForge

三、Bitbucket

四、GitLab

五、Assembla

在网上搜索了相关的信息如博客，知乎后，总结相关项目管理软件的优缺点以下：

• Microsoft TFS
  • 优势：方便小团队对于需求、进度的掌握，集成了项目管理、版本控制、BUG追踪等功能，且与VS完美接合。
  • 缺点：搭建复杂，硬件需求高
• GitHub
  • 优势：功能极其齐全，方便交流合做
  • 缺点：学习成本较高，须要经过较长时间的学习、熟悉后才能流畅使用各类命令
• Trac
  • 优势：扩充性好，权限体系完备，较为灵活
  • 缺点：不支持多项目，汉化不完整，中文支持较差
• Bugzilla
  • 优势：免费，且有中文支持
  • 缺点：只能管理缺陷，功能较少
• Apple XCode
  • 优势：自动建立分类图表，撤回、重作、保存等经常使用功能使用方便，不须要命令、代码
  • 缺点：在版本更新后，部分插件可能失效，致使诸多问题。
• Mercurial
  • 优势：有revset，拓展性好，部署较为简单
  • 缺点：强制向下兼容