Frederick P.Brooks,Brooks被认为是“IBM 360系统之父”,他担任了360系统的项目经理,以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献,他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖(National Medal of Techology)。早期,Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
看到如此丰富的人生简历,不禁让人羡慕又赞叹,《人月传说》就是他笔下的一个经典。
文章开篇以焦油坑(The Tar Pit)引出,焦油坑,让陷入其中的猛兽月石挣扎,越是难以挣脱束缚,最终陷入坑底。而大型的系统开发就是这样的焦油坑,各种问题纠结在一起,让人越陷越深,没有办法看清事情的本质。在其中,不要做一个纯粹的乐观者。
《人月神话》,那什么是人月?是在估计和进度安排中使用的工作量单位。Brooks认为,用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。 人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之 间不需要相互的交流。
保持设计的概念完整。无论对小软件还是大软件,都必须由一个设计师主导,最多两个人讨论来共同完成软件的整体设计。作为一个软件,一个系统,必须有一个清晰明确的概念模型,大家都在这个框架下工作,所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念,但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是,即使是总设计师一直是同一个人,他脑海中所认为理所当然的规则或者概念,很可能由于没有明确的文档化,而没有成为所有开发者共同的概念。在其他开发者编码的时候,就可能会生成与概念相抵触的东西(模块,功能,算法),导致整体结构的恶化。这个时候总设计师一定要即时发现,做出更正。这就是外科手术式的开发队伍。
所以作为软件工程的一名学生应该将规则或者概念要明确的文档化。避免整体结构的恶化。