当继续阅读这本书的时候，我发现里面的有些言论，以我现在的阅历还不能完全理解，但有几个我记忆非常深刻的点 ：
经验法则：
1/3 的时间用于计划
1/6 用于编码
1/4 用于单元测试
1/4 用于系统测试
这个时间规划我是有一些震惊的，原来我认为的最重要的编码时间在整个项目中却是所占时长最少的，只占到了1/6的时间；而在我们实际操作中是不太一样的的，通常我们都是粗略的计划一下，而更多的时间都是在程序编码上。这就违背了用户使用的初衷，只有把用户需求彻底了解，做一个功能完善的计划，才能有好的项目。还有就是软件测试。我们做的还远远不够呢。
外科手术队伍：
1. 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，Sackman和Humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。
2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。
3. 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。
4. 对于真正意义上的大型系统，小型精干的队伍太慢了。
5. 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。
6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
贵族专制、民主政治和系统设计：
1. 概念完整性是系统设计中最重要的考虑因素。
2. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
5. 体系结构、设计实现、物理实现的许多工作可以并发进行。
画蛇添足：
1. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
2. 结构师如何成功地影响实现：
i. 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。
ii. 听取开发人员在体系结构上改进的建议。
3. 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。