人月神话（一）

     人月神话40周年纪念版主要包括两部分，第一部分：第一到十五章，它是对1975年的第一版的观点的重印（除了一些无足轻重的修改）。第二部分：第十六章至19章，它开始则对更新的思想进行扩充，主要围绕“没有银弹”这篇论文展开。这边博客主要对该书的第一部分的一些观点谈一些我个人的感悟和观点。

    第一章：焦油坑。该章将大型系统开发形象的比作焦油坑，开发人员则是焦油坑中的大型强壮的动物，在其中剧烈挣扎。它让我们认识了系统开发这个行业，以及充满在这个职业中的乐趣和苦恼！乐趣主要是创建事物和不断的学习，烦恼则很多。首先，往往是由他人来设定目标、供给资源和提供信息，通俗来讲就是编程人员不是老板，只是打工的，在公司IT部门也只是一个功能部门，很少能参与公司高层的决策。其次，编程人员需要依赖队友，然而这个世界上流氓和猪队友并不少。下一个烦恼，也是大家谈的最多的，找bug。如果只是单纯的设计，开发还是一件很美好的事。最后一个就是，IT行业是一个追求速度的行业，产品需要快速出来，这就是为什么大部分程序猿要加班加点的原因了。

   第二章：人月神话。人指的是开发人员的数量，而月则指的是开发所花的时间。该章有几个观点，首先，系统开发过慢是盲目的添加人手是错误的，因为添加人手，需要添加培训和交流的时间。另外，提到了软件开发，时间比例的分配，计划1/3，编码1/6，测试1/2，无疑将测试是重中之重。

   第三章：外科医生。Harlan Mills建议大型项目的每一个部分由一个团队完成，但是该队伍以类似外科手术的的方式组建，而并非一拥而上。

   第四章：贵族专制、民主政治和系统设计。在进行结构上的决策时我们要实行专制，由一些智力精英来告诉可怜的实现人员来如何工作。这样设计出来的系统才会有概念完整性，系统使用起来才会更方便。

   第五章：画蛇添足。改章提醒结构师要考虑设计的实现成本，不能进行过分的设计。这就要求结构师要和开发任务尽早并持续的交流，因为系统实现人员决定了成本性能。

   第六章：贯彻执行。怎样让系统结构师的决策能够贯彻执行？改章提到了几个方法，文档化的规格说明-手册（文档在大型团队里真的很重要）；形式化定义（决定了文档的精确度）；会议和大会；多重实现；操作日志；产品测试（测试部分是监督本门，具有公正性）。

   第七章：为什么巴比伦塔会失败。巴比铁塔是人类继诺亚方舟后的第二大工程，它有清晰的目标、足够的人力和材料、技术，更拥有足够的时间，但它为什么会以失败告终呢？就是因为，各部落之间不能很好的交流，形成组织。交流的缺乏导致争辩、沮丧和群体猜忌，很快大家开始分裂，这足以看出交流和组织的重要性。交流的方式有很多种，而减少交流的办法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构反应出对详细交流的需要会相应减少。

   第八章：胸有成竹。这一章列出了击中工作量的估计的工作方式，告诉我们时间是最好的老师。要想估计编程人员的生产率，需要不断分析以前的实践数据得出结论。

   第九章：削足适履。要让项目规模和作为成本的程序空间搭配的恰到好处。

   第十章：提纲挈领。项目经理的任务是制定计划，并实现计划，但是只有书面计划是准确和可以沟通的。少量的关键文档封装了项目经理大量的工作，这就要求项目经理能抓住重点。

   第十一章：未雨绸缪。不变只是愿望，变化才是永恒！所以在计划之前我们要做很多实验，才知道那个计划好。同时我们要不断的根据变化更改我们的系统设计和组织结构，这就要求他们刚开始就有拓展性。同时在修复bug时我们压迫使用能支出副作用的程序设计方法，不然会导致更多的bug。

  第十二章：干将莫邪。巧匠因为他的工具而出名。关键字：目标机器、辅助机器、数据服务、高级语言、交互式编程。

   第十三章：整体部分。如何开发一个可以运行的系统？如何测试系统？如何将进过测试的一系列构建集成到逸测试过可以依赖的系统？关键词：剔除bug的设计、构件单元测试、系统集成调试。

  第十四章：祸起萧墙。当项目出现延误时，我们需要分析原因。这时候一个富有热情、老练的、熟练的计划和控制小组是非常重要的。他们可以评审未按时到达里程碑的原因，他们深受投资人和开发人员喜欢。

   第十五章：另外一面。如何很好的表达自己的观点，字不如图，图不如表。