【软件工程】第一次阅读做业

1.看完整部教材后，我仍然不懂的一些问题？

Q1：第四章 两人合做

• 4.5.4 “如何结对编程”中提到

  “驾驶员和领航员不断轮换角色，不要连续工做超过一小时，每工做一小时休息15分钟。”

  这里的“不能连续工做超过一小时，每工做一小时休息15分钟”是否太过绝对？有时候编写某个模块时，工做状态正好，若是忽然停下来去休息或者去作其余轻松的事，反而会大大影响本身的工做效率。以我本身为例，若是在很顺手地编写某一段代码时，被打断了一段时间，后面再继续时会感受以前的“手感”彻底不见了。这里是否是应该认为判断本身的效率降低时，选择去休息调整更好？

Q2：第九章 项目经理

• 9.3 提到“PM作开发和测试以外的全部事情”，这里设想一下，若是PM参与开发，是否是能更好地掌握当前的项目进度，从而更好地协调团队内部外部，调配各部门资源和时间，更顺利地完成项目计划呢（这里或许与书中问题中的舵手和划船手不一样，PM参与开发并不意味着失去方向，而舵手参与划船则会使得船失去方向、稳定）？

Q3：第十三章 软件测试

• 13.2.7的伙伴测试中，要求测试人员做为开发人员的一个伙伴，并对其模块在本地作必要的回归/功能/集成/探索测试。但是据书中前面所说，最好是开发人员本身写测试，由于开发人员是最清楚本身代码的人。那么，为何不让开发人员进行测试？或者说给每一个开发人员分配一个测试人员进行结对？

Q4：第十六章 IT行业的创新

• 16.1.5 “迷思之五：要成为领域的专家，才能创新”中提到

  “统计数据代表，70%的创新者说，他们最成功的创新，是在他们的拿手领域以外发现的”

  而关于领域内的专家有时候没有领域外的创新者那么有创意这个问题，是否是由于专家在这个领域研究得多了，被一些固有模式所绊住了呢？还有，若是创新就是知识->金钱的过程的话，那么咱们去了解多个领域是否是更有利于咱们创新呢？

Q5：第十七章 人，绩效和职业道德

• 17.1“领导力--带领团队成长”中，若是一个团队刚刚成立，有一我的以技术见长，而一我的在相关原理知识方面更胜一筹，两我的的其余如交际能力等很好且相差无几，那么这两我的哪一个更适合当团队的领导，带动团队成长呢？

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

• The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.（最先在工程背景下出版的术语“软件”是由Richard R. Carhart在兰德公司研究备忘录中于1953年8月出版的。）
• Margaret H. Hamilton began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering.（<font face="微软雅黑"在早期的阿波罗任务中，玛格丽特·汉密尔顿开始使用“软件工程”这个术语，以使软件具备硬件工程等其余领域的合法性。）

3.软件工程发展的过程当中有趣的冷知识和故事？

​  说一说Lua语言的由来吧。Lua 是一个小巧的脚本语言，由标准C编写而成，几乎在全部操做系统和平台上均可以编译，运行。是由三个巴西人Roberto Ierusalimschy、Waldemar Celes、Luiz Henrique de Figueiredo发明。发明的缘由是巴西石油公司PETROBRAS没办法使用指定的硬件，使用公众的资金须要经过一系列的严格手续，而且现有设备中什么平台什么系统都有，因此Lua被设计成一个基于ANSI C开发能够任意跨平台的语言。

4.目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

​   目前流行的源程序版本管理软件和项目管理软件：Microsoft TFS，Git, SVN, Mercurial，Trac等。其中版本管理软件排行榜

• Microsoft TFS

  优势：

  1. ​任务版上能将需求、项目进度尽收眼底，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
  2. 能有效实现 SCRUM，能与 VS 无缝接合。

  缺点：

  1. 搭建、维护tfs比较复杂，硬件要求也比较高。
  2. 整个系统是用 asp 实现的，用浏览器访问至关慢。

• Git

  优势：

  1. 公共服务器压力和数据量都不会太大。
  2. 速度快、灵活。
  3. 任意两个开发者之间能够很容易的解决冲突。

  缺点：

  1. 学习周期相对而言比较长。
  2. 不符合常规思惟。
  3. 代码保密性差，一旦开发者把整个库克隆下来就能够彻底公开全部代码和版本信息。

• Trac

  优势：

  1. 有良好的扩充性。
  2. Trac的权限体系是比较完备的设计。
  3. 很是灵活，能够为所欲为的定制，能够和TortoiseSVN集成。

  缺点：

  1. 不支持多项目。
  2. 需求和缺陷没有分离。
  3. 核心功能不多，不安装插件基本上无法用。

• SVN

  优势：

  1. 管理方便，逻辑明确，操做简单，上手快。
  2. 易于管理，集中式服务器更能保证安全性。
  3. 代码一致性很是高。
  4. 有良好的目录级权限控制系统。

  缺点：

  1. 对服务器性能要求高，数据库容量常常暴增，体量大。
  2. 分支的管控方式不灵活。

• Mercurial

  优势：

  1. 学习门槛较低。总体上看，须要掌握的命令要比git少不少。
  2. 能够一键彻底恢复到历史版本的某一个切面。
  3. 封装好。相比git，不多暴露一些实现内的细节。

  缺点：

  1. 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不肯使用。

  参考资料

  [1]几种经常使用的版本控制系统优缺点比较

  [2]http://www.javashuo.com/article/p-bgcdcykv-ch.html