人月神话阅读笔记03

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　《人月神话》阅读笔记

　　人月神话最初听到这本书的名字时，猜测是是一本奇幻小说。后来通过网络知道，这是衡量软件开发过程中的一个工时术语，如30人月，可能是5个人6个月的工作量，抑或是3个人10个月的工作量，或者其它。针对这个不确定的算法，因此就成了神话，这个命题其实是个伪命题，根本没法衡量和评估，因此作者说是个神话。
　　冷冰冰的公式好像是对的，但是里面缺少了“人”的因素，计划问题、沟通成本、技术熟练程度、态度问题、风险问题等要素。简单、武断地重复一下 Brooks 法则，“向进度落后的项目中增加人手，只会使进度更加落后”。在众多软件项目中，由于业务需求和范围的不确定性，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
　　软件开发的团队要像“外科手术队伍”（the Surgical Team），包括“外科医生”、“副手”、“秘书”、“管理员”、“程序员”、“测试员”、“语言专家”等角色。每个角色分工不同，共同协作，责权利分明，完成这台“手术”工作。外科医生就是俗称的主刀来负责整个开发队伍，即首席程序员。他来定义产品的技术原型，开发规范、开发框架，负责系统的整体架构与管理工作。“副手”作为“外科医生”的助理，承担相应的职责，尤其是协调与沟通方面的职责，还有一些编码方面的工作。其他角色人员都是各司其职，各尽其责。
　　实际的软件开发队伍，优秀工程师的生产效率是普通工程师的十倍以上，这个比率已被证明，为什么差异会这么大呢？这个与“人”的因素有很大关系，经验能力、熟练程度、代码风格、质量高低、BUG多少等因素有关系，综合在一起，形成了十倍以上的关系。在软件开发过程中，系统架构与设计实现一定要分开，只有这样，才能取得良好的效果。
　　“贵族专制、民主政治和系统设计”（Aristocracy, Democracy, and System Design），在进行软件系统架构与设计之前，概念上一定要保持一致性和完整性，不能有似是而非的定义，最好用形式化语言定义。一定要站在前人的肩上，吸收国内外的精华，为我所用，不要盲目的闭门造车。先学习，再创新，一定要打好基本功。不能盲目的自大，亦不能妄自菲薄，一定要认识自己。在整个团队中，架构、分析、设计和开发文档一定要完善，齐套，保证所有的人员都遵循这些规章制度，并且有合理科学的检查与校验机制，形成闭环。

　　之前的我总是觉得文档并不是很重要，直到我看了这本书后感觉在一个项目中很多环节不可缺少，在以后的学习或生活中我会更加努力完成这些。