《人月神话》1975 笔记.doc

《人月神话》1975笔记《人月神话》的观点:是或非?我们理解的也好,不理解的也好,描述都应该简短精练。塞缪尔·巴特勒,(ProgrammingSystemsProduct)开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量,将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量,这些高成本的构件在根本上是相互独立的。“满足我们内心深处的创造渴望和愉悦所有人的共有情感”,提供了五种乐趣:..创建事物的快乐..开发对其他人有用的东西的乐趣..将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力..面对不重复的任务,不间断学****的乐趣..工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动,其存在、,这个行业具有一些内在固有的苦恼:..将做事方式调整到追求完美,是学****编程的最困难部分..由其他人来设定目标,并且必须依靠自己无法控制的事物(特别是程序);权威不等同于责任..实际情况看起来要比这一点好一些:真正的权威来自于每次任务的完成..任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外..人们通常期望项目在接近结束时,(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢..,它比其他所有因素加起来影响还大。,某些任务无法在不损害结果的情况下加快速度。:“一切都将运作良好”。,所以我们期待在实现过程中不会碰到困难。,我们的构思是有缺陷的,因此总会有bug。,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。——培训和相互沟通。,我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。,我们缺乏数据估计。,所以在管理和客户的压力下,我们常常缺乏坚持的勇气。:向进度落后的项目中增加人手,只会使进度更加落后。:任务重新分配本身和所造成的工作中断;培训新人员;额外的相互沟通。,优秀的专业程序员的工作效率是较差程序员的十倍。(Sackman、Erikson和Grand)、Erikson和Grand的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。、精干队伍是最好的——尽可能的少。,其中一个项目经理,常常是最佳的人员使用方法。[留意一下上帝对婚姻的设计。],小型精干的队伍太慢了。,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是高成本、速度缓慢、不充分的,开发出的产品无法进行概念上的集成。、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性,又能得到多位协助人员的总体生产率,还彻底地减少了沟通的工作量。第4章贵族专制、“概念完整性是系统设计中最重要的考虑因素”。“功能与理解上的复杂程度的比值才是系统设计的最终测试标准”,而不仅仅是丰富的功能。[该比值是对易用性的一种测量,由简单和复杂应用共同验证。],设计必须由一个人或者具有共识的小型团队来完成。“对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”[同样适用于小型项目。]“如果要得到系统概念上的完整性,那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。”、规则对行业是有益的。外部的体系结构规定实际上是增强,而不是限制实现小组的创造性。。(architecture)、设计实现(implementation)、物理实现(realization)的许多工作可以并发进行。[软件和硬件设计同样可以并行。,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。:..牢记是开发人员承担创造性的实现