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