读《人月神话》

   翻开扉页，购书日期：2003.2.10。实在汗颜，且此类书，我的案头还有许多。
   在两周中抽出时间，翻看完了这本传说中的经典。
   总的感觉，收获并不多，虽说有些东西并未能完全理解，但大多在作者看来是未来的东西，已早成为现实。大致看来，没有什么新的概念。
   于是，也谈不上读后感，只是把看的过程中的笔记重新写一遍，当作另一个自已的索引吧。
   (注：突然下决心，凡是看完一本书，都应有一篇读书笔记，否则，有可能就白看了)。

   若干前言，序言，将本书称为神品。
   来，看书吧。

   一：焦油坑
   编程是什么？许多人痛苦挣扎的焦油坑。它是乐趣与苦恼共存的创造性活动。
   有些体会吗？没有，那你，转行吧。

   二：人月神话
   哇，这么快就切入主题了。
   2.1：人月不能用来衡量工作的规模。但显然大家都是用这个来衡量，作者并未讲不用这个还能用啥。
   2.2：1/3计划，1/6编码，1/4构件及早期测试  1/4系统测试。嗯，一半时间用来测试。我所在公司现在的状况确实如此。只不过领导们把
   测试多是安排在了加班时间中。
   2.3：向进度落后的项目中增加人手，只会使进度更落后。这有些绝对了，如果添加的人手得力，还是可以提升进度地。

   三：外科手术队伍
   嗯，这是很专业的队伍。
   3.1：大型项目划分为若干部分，每一部分一个团队，团队按外科手术队伍的方式组建。外科医生难求噢。
   3.2：由系统结构师来协调若干个外科医生。

   四：贵族专制，民主政冶和系统设计
   4.1：为了得到概念上的一致性，需要无任何歉意的贵族专制。
   4.2：在稳定体系统结构下的实现的设计，同样需要创造性，不要低估或悲观。
   4.3：体系结构未完成，编程人员做啥？作者说：很简单，体系统结构完成后，再雇佣他们。
   4.4：有时，体系结构、开发实现、物理实现可以同时开始和并发进行。

   五：画蛇添足
   5.1：结构师与承包商与开发人员应该有良好的交流准则和机制。
   5.2：设计师的第二系统往往会有毛病：一是过分设计，二是对已落后的技术进行细化和精练。

   六：贯彻执行
   6.1：文档化的规格说明很有意义，另外，可再进行形式化定义，一种为主，一种为辅。
   6.2：周例会，年度大会的作用。
   6.3：多重实现可保证定义更简洁，更规范。是这样的吗？
   6.4：总结FAQ是好的工作方式。
   6.5：产品测试小组是顾客的代言人。

   七：为什么巴比伦塔会失败
   7.1：失败的原因，缺乏交流以及相应的组织。
   7.2：大型项目中的交流方式：电话，会议，手册。有些落伍了，呵呵。
   7.3：项目工作手册的制作方式。
   7.4：大型项目中的正确组织架构。其中，最关键的角色，产品负责人和技术主管的多种协作方式。

   八：胸有成竹
   8.1：对编程人员生产率的若干调查，得出结论：
   8.1.1：我们总是对人员的工作时间做了不现实的估计，某些其余时间被忽略了，这差不多占一半时间。 
   8.1.2：交互越多，生产率越低，大致有1-3倍的差距。
   8.1.3：使用适当的高级语言，可以将生产率提高5倍。 

  九：削足适履
   9.1：程序空间也是成本，开发人员必须为此设计目标和实现。(显然，现在对此的要求大大降低了)
   9.2：规模控制的方法：制定总体规模预算，个体间多交流勾通。
   9.3：空间相关技能：功能与空间，空间与时间，技术积累。
   9.4：数据的表现形式是编程的根本。仔细思考程序的数据会得到好的效果。

   十：提纲挈领
   10.1：文档的作用(在管理方面)：项目监督，预警，查查列表，状态控制，汇报的数据基础。
   10.2：软件项目的关键文档：目标，技术说明，进度，预算，工作空间分配，组织图。
   10.3：只有书面文档才是精确，可勾通，可检查的。

   十一：未雨绸缪
   11.1：构建一个试验性的系统，然后抛弃它。
   11.2：为变更做准备，为变更设计系统。
   11.3：为主更建立更强大的团队，组织结构要更灵活。管理与技术人员可互换，最小化人员间的接口。
   11.4：程序维护通常是开发成本的40%,缺陷恢复通常以20%-50%的几率引入新Bug。
   11.5：软件维护是提高混乱度的过程。
   
   十二：干将莫邪
   12.1：配备专门的工具管理人员的必要性。
   12.2：我们需要的工具：目标(辅助机器)以及合理的进度安排(这点可能已经不是什么工具了)。编程工具，文档系统，性能仿真器。
   12.3：解释高级语言与交互式编程。

   十三：整体部分
   13.1：整体考虑一个系统，我们需要：
         使Bug更不易产生的方式来设计。
         编写测试规格说明，采用精化方式，自上由下设计.
         采用结构化编程。
   13.2：早期测试的四步：本机调试，内存转储，快照，交互式调试。
   13.3：系统集成调试的方法：使用经过调试的构件单元搭建系统。 

  十四；祸起萧墙
   14.1：使用里程碑来控制进度。
   14.2：采用关键路径技术来判断偏离的关键。
   14.3：老板应该尽量减少角色冲突来得到更真实的报告。
   14.4：需要拥有能了解状态真相的机制或者是通过计划和控制小组。

   十五：另外一面
   15.1：用“如何做”来代替说教之词。
   15.2：程序文档的需求：使用程序，验证程序，修改程序的不同需求。
   15.3：弱化流程图的作用，并简化之。
   15.4：用程序来自动生成文档。

   十六：没有银弹
   16.1：软件的根本任务——打造构成抽象软件实体的复杂概念结构，它始终未得到改进，所以，生产率不能得到数量级的提升。
   16.2：软件开发的根本困难是：规格说明、设计和测试这些概念上的结构(我没太明白噢)。
         软件系统的内部特性：复杂性、一致性、可变性、不可预见性。
   16.3：解决次要问题的一些方案：高级语言、分时、统一编程。
   16.4：银弹的希望：
         高级编程语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证、环境和工具、工作站。
   16.5：针对概念上根本问题的有前途的方法：
         购买构件、需求精练、快速原型、增量开发、培养卓越的设计人员。
  
   十七：再论“没有银弹”
   17.1：作者回应某些反驳“没有银弹”的评论。
   17.2：面向对象技术的现实情况。
   17.3：重用的情况。
  
   十八：《人月神话》的观点：是与非？
   复习人月神化中的重要的十五个观点。

十九：20年后的《人月神话》
   19.1：概念完整性需要结构师来保证。
   19.2：开发第二个系统的问题，再强调：盲目的功能，无确定的用户群，瞎猜。
   19.3：图开界面的成功。
   19.4：用增量开发模型取代不正确的瀑布式开发。
   19.5：信息隐藏的重要，不应该对开发人员公布所有技术文档，大多数，接口足以。
   19.6：人月配备与进度的平衡，再次进行证明。
   19.7：人的作用决定一切，推荐《人件》一书。
   19.8：构件开发。
   19.9：软件工程的状态和未来。
   
   应该说，第十九章是最重要，也是我们最应该关心的一章，但可惜的是，由于年代过于久远，并未看到什么新鲜的东东。