焦油坑和人月神话--人月笔记1

　　焦油坑的意思说明了即使你足够强大，也无法摆脱束搏而沉到坑底。感觉用这个比喻来形容软件开发再合适不过了。当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。

 职业的乐趣

    （1）创建事物的纯粹快乐

    （2）开发出对他人有用的东西

    （3）整合零部件，收到预期效果

    （4）学习的乐趣

    （5）像诗人一样创造的乐趣

职业的苦恼

   （1）追求完美

   （2）由他人来设定目标，供给资源，提供信息

   （3）寻找琐碎的bug

   （4）调试和查错往往是线性收敛的 

   （5）产品在即将完成或者终于完成的时候， 却已显得陈旧过时

这， 就是编程。 一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。

 

向进度落后的项目中增加人手，只会使进度更加落后。 -Brooks法则

　　这是这本书给我印象最深的一句话，也是本书的核心观点之一。虽然乍一看很反直觉，但却又是如此契合软件开发的现实情况。一方面，部分任务由于次序上的限制不能分解，人手的添加对进度没有帮助。 另一方面，即使是可分解的任务，子任务间需要相互沟通和交流，增加了培训和相互交流的成本。

乐观主义

　　乐观主义假设一切都会运转良好，而不会遇到任何的风险和问题，这是程序员的通病，对项目盲目的乐观，而恰恰实际情况是在实际开发中遇到一个疑难问题耽误几天或一周的时间。

人月神话

　　用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。

　　假设人月可以互换，则为了缩减周期需要投入更多的人，为了让更多的人都有事可做就需要细分任务，细分任务自然增加了系统分解和后期集成的工作量，细分任务间无法避免的依赖和关联自然增加了沟通的成本和工作量。而且由于任务的细分需要引入文档等重量级的沟通工具，原始的需求信息在需求，设计，开发，测试等多个环节传递很难真正保证我们需要的概念完整性。

　　如果一个系统按功能点估算有200个功能点，按一个功能点200-300行代码计算，整个系统规模在5万行代码左右。这是一个中小型的项目或系统。如果按照总生产率80行/天计算，则总工作量在20人月左右。根据非线性关系我们可以估计理想情况或者说性价比最好的情况是投入5人4个月完成，当人数增加一倍时候进度只能压缩到3个月。当人数再增加到15个人的时候，进度压缩到2个月，这个时候增加再多的人就已经没有用了，对于这种规模的的系统，2个月可能就是进度极限了。

进度灾难

　　除去了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。

　　以上便是人月神话前两章的要点整理，无怪乎这本书有如此高的评价，然文中提到的部分观点自己没有切身体会，但是能够从整体上获得对软件项目有一个重新的认识。这本书在一些不涉及具体技术的方面，很有先见性和指导性，我想这也是这本书的普适性这么强的原因之一。