很多地方都提到了这本书，我就想学习下，天天在地铁上下班的时候看了。第一个想法就是感觉如果经验不足的话读本书，真的感觉印证的想法不多，在中间和后面的几张的阅读都是浑浑噩噩的。不过还是总结下自己的想法。
1）关于不同方面的比例：
1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand
其实挺吃惊的，原来一直感觉在开发中编程才是最主要的环节，是一切的根本。自从参加了工作之后，发现编程的地位越来越不重要了。在开发过程中。软件项目团队被建议，使用三分之一的时间对项目进行各种规划、设计，实际的编程时间并不是主要时间部分，余下一半时间被用来进行各种测试，检测、排除软件中的各种问题。
2）人和月
给推迟的软件项目增加人手将使得项目更加推迟。所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所以软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。
3）概念的完整性
系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。
4）巴别塔的失败--交流
我是一个不善于交流的人，可是发现一个一个项目的进度和产品的各个方面的质量保证都在交流和监督。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。