用了两周的时间，大致过了一遍。书中讲述的很多方面可能此时并没有很深刻的体会，但是该书的预见性和分析还是很让人钦佩的。书中对项目、产品、程序、程序员等一系列对象的分析是相当精准的。虽然距今已有四十多年，但很多依旧在发生。 书中第一章就针对程序编程者来说，为什么我们会喜欢编程？在工作中又有怎样的苦恼？例如乐趣有：创建事物的纯粹的快乐，开发对他人有用的东西，持续学习的快乐等。苦恼有：依靠他人程序(而这些程序设计的并不合理、实现拙劣、发布不完整或者文档记录很糟糕)，不断重复寻找琐碎的bug等。 在一个产品的产出过程中，除了编程人员这个角色之外，还有项目经理，架构师，需求，测试等。 针对任务，如何正确对待人员数量和时间之间的关系，如何合理安排沟通、交流的工作，是延长了还是缩短的时间进度，以及如何安排计划、编码、测试等时间的分配。除了这些内部因素还有其他如客户需求等不定性因素，又如何能合理的应对。此外，针对团队的扩建，如何分配角色才能达到非常高的效率。书中有的给出了实例有的类比外科手术和厨房做出了类比。 ######书中观点：
- 进度安排，1/3计划，1/6编码，1/4构件测试以及1/4系统测试。(以后留心目前敏捷开发的时间安排，感觉怪怪的)
- Brooks法则：为进度落后的项目增加人手，只会使进度更加落后
- 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。
- 为了获得概念完整性，设计必须有一个人或者具有共识的小型团队来完成
- 对于非常大型的项目，将体系结构方面的工作与具体实现相分离是获得概念完整型的强有力方法。
He'll sit here and he'll say, "Do this! Do that!" And nothing will happen. ——HAPPY S. TRUMAN, ON PRESIDENIAL POWER
书中前五章主要概括的介绍了人员上可能存在的问题。之后介绍了具体的产品实现，例如过程，控制，规模，异常处理，产品性能与硬件之前的调整，语言选择与数据结构的重要性等。
- 在项目开始之前，首先需要一个贯彻执行的方针
- 其次就是良好的交流与组织，拥有一个合适的项目工作手册
- 然后是对整体过程胸有成竹以及对开发系统以及其他方面规模的控制
- 各式各样文档的编写与维护
- 从容的应对过程中的变化(唯一不变的就是变化本身)
- 工具的使用与管理(如果每个人都使用自己的一套工具，整合时应该会很麻烦吧)
- 测试过程 书中也提到了自动化文档，“自动”编程，图形化编程，高级语言带来的效率提升等。
任何人若想看到意见完美无暇的作品，他所想的那种作品过去不存在，现在和将来也不会出现。 ——亚历山大 · 蒲柏，《批判论文》
最后，提到了重用与增量式开发(个人认为类似如今的敏捷开发)。
Parnas 写道： 重用是一件说起来容易，做起来很难的事情。它同时需要良好的设计和卓越的文档。即使我们看到了非常罕见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。
增量开发就如今的敏捷开发，渐进的精化。在每个阶段，我们都有一个可运行的系统。其优缺点就不在此论述，可参照以下论点： 论敏捷开发的优缺点
我们理解也好，不理解也好，描述都应该简短精炼。 ——塞缪尔 · 勃特勒，《休迪布拉斯》
哈哈，晚安。
