第一部分，前四章内容，给我的感觉不深入，还没有什么让我觉得特别提神醒脑的内容。但是也还是有一些观点能够让我感到略有体会，可能是自己还是太菜了。这里只做一个简单的纪要。

　　首先，如果是自己成为一个项目的需求分析者，和整个代码架构和结构的主要设计者，其中提到的几个checkList（需求核对表、架构核对表）是可以参考的，倒不至于说其中的每一点都必须满足了才能去推动需求，那样也不现实，而是把它作为一个参考，看看还有哪些可以满足，但是当前没有做好的，这在经验不足的时候可以作为一个重要的参考。

　　其次，有一些内容，也是让我有感同身受。自己经历的过程中虽有体会，但没有这么总结出来：

　　1.对于软件构建来说，“努力创造真正的原创成果”的开发效率，往往低于专注于重用以往项目的一些设计思想、代码以及测试用例的开发效率。--这里主要是为了说明，代码的重用性很重要，所谓的努力创造真正的原创成果应该是往反方向努力。这一点是显而易见的。

　　2.能有效地开发高质量软件的人们,在长年累月中积累了大量的技术、技巧和诀窍。技术并不是规矩( rule ),它只是分析工具( analytical tools )。好的工匠知道完成某项工作要用哪样工具,也知道该怎样正确地使用。程序员也该这样。编科方面的知识学得越多,你脑中的工具箱中就会有更多的分析工具,也会知道该在何时用这些工具,以及怎样正确地使用它们。--这里的启发主要还是，我们要尽量接触多的工具，知道不同的工具优劣，适用范围。从这一点上，也说明了广度比较重要，对比不同的技术，在各自领域的优势和劣势，能够帮助我们更合理地去使用不同的技术解决各自擅长的领域问题。

　　3.一个“险恶”的问题：你必须解决了这个问题，才能知道如何解决是优雅的，有效的。--这里确实有体会，但是一方面来说，从设计的角度，确实经验很重要，也就是说确实是解决了才会更好地去解决这个问题。但是这种能力我认为是可以迁移的，如果底子够好，经验也比较多，涉及的领域广泛，维度也比较高的话，那么解决了一个问题，就能解决一大批同类型的问题，这是可以积累的。