第一章 欢迎进入软件构建的世界
这章阐述了软件构建的重要性，软件构建大体上就是说具体程序员做的工作，而不是需求收集人员，产品设计人员，业务分析人员，架构设计人员，测试人员，运维人员等做的工作，虽然这些人的工作在整个软件开发生命周期中也非常的重要，但是一个软件开发的最主要的部分却是具体程序员做的那部分事情。一般的软件公司里具体程序员的数量应该占很大的比重，大多数的程序员也是具体程序员，只有很少的程序员经过多年的工作学习能成为项目经理，业务分析人员，架构师等高级软件从业人员。具体程序员是我这里提出的，具体程序员做什么工作呢？理解架构师做出的架构设计，做你负责的模块的详细设计，做出自己的负责模块的开发计划，编码，单元测试，和其它模块的负责人联调，做集成测试，遇到问题后调试，解决测试人员提出的BUG，以及软件上线后排查线上的问题等等。如果你做的是这些工作，那你就是具体程序员，你做的大多事情就是软件构建的事情。当然，还有一部分程序员，在小公司，或者做着一些不太正规的小项目，除了具体的软件构建工作，还得和客户沟通需求，设计大体架构，部署维护，解答客户问题等工作，尽管这样，软件构建还应该是你工作中最主要的一部分，应该大多数人都做过类似的项目或者在类似的公司里工作过。无论如何，只要你是个程序员，就应该系统的，好好的学习下软件构建的技能和知识，这比你学很多种语言，尝试很多种花哨的新技术要值很多，至少我看了这本书的其中几章有这个体会，第一次认真考虑软件构建中的一些基础的，细节的，基本的，通用的思维方式，编码技巧和规范。
第二章 用隐喻来更充分的理解软件开发
这章总的来说可读可不读，没啥太大的收获。我们平时把软件编码叫做写代码，让外行人听起来像是在写文章，就是把你心里的想法一点一点的有条理的写出来，在这一点上，编码和写文章确实有相似之处，但写文章一般是你自己写，编码则需要和别人合作。还有在软件设计的时候，我们经常拿盖房子来比喻，盖房子之前要先画好蓝图，整体结构，考虑好水、电的布局等，盖一个小狗窝和盖一栋大楼的过程也是不一样的，做一个小软件和一个超大型的软件的过程也是不一样的。如果你能很好把软件的开发过程想象成某些生活中具体的例子，找到他们的相似之处和不同之处，你就能更好的理解软件开发，以及利用这些隐喻来与人更好的沟通。你脑子里如果有很多这样的隐喻，在你做软件设计时就会不经意的想起来，成为你思考和权衡不同方案的工具。第三章 三思而后行：前期准备
做任何事情都需要前期准备，在软件开发中更是如此，尽管如此，还是有很多程序员接到任务后就是想着尽快编码，很多老板不重视软件开发的前期准备。要想保证一个软件的质量，在前期准备，需求分析，架构设计，编码，测试，维护等每一个环节都要重视质量。具体程序员接到任务的时候要检查一下在你之前的那些软件活动有没有准备好，如果需求中有好多没有说明的地方，架构设计也不明确，你不知道需要和其它模块之间如何通信，基础组件啥也没有，这种情况下进行详细设计和编码会很受罪。和同事老板达成前期准备重要性的共识之后，就是如何做前期准备以及如何判断前期准备已经做好的技巧，这些是更实用的地方。如何做前期准备基本上是需求分析人员，产品经理和架构师的关心的问题，而判断前期准备是否已准备好则是具体程序员也需要具备的能力。首先要判断你做的软件的类型和规模，如果你做的是一个长期的项目，一期一期的做，就更适合敏捷开发和迭代式开发，做一些基本的前期准备就可以开工了，先把最核心的功能实现，每隔一段时间把一些新需求加入设计和编码中来，设计和编码可以结合起来，需求也不用一下子就写的特别全面，先写出最基本的需求。如果你要做一个性命攸关的系统，如航天软件，医疗软件等，前期准备就应该更严格，需求规格说明书要尽量详细，设计也要花很长时间来做，尽量防止以后改动。根据你的项目的性质来选择更迭代化还是更瀑布式的开发。
问题定义应该是前期准备的第一个环节，用短短的几句话来说明你做的软件解决什么问题？商业意义是什么？如果这个都不明确，那你做这个软件干啥？
明确的需求在前期准备也很重要，需求要明确，全面，至少在接下来的一次开发迭代中需要的信息都要明确，而且不矛盾。没有明确的需求，测试人员就没法写测试用例，客户也没法理解如何使用系统，程序员也不知道如何设计编码。需求是不可能完全不变的，所以要针对需求变化制定一系列措施，比如每隔两周响应一次客户提出的需求变化，而不是无规律的频繁的接受用户需求变更；做一套需求管理系统；让老板，客户每个人都了解到频繁需求变化带来的后果；尽早的识别出可能的需求变化，以在架构设计的时候就提前考虑进去等。书中有一个检查需求质量的check list，写的很具体，很有指导作用，这本书的信息量很大，很难压缩在几篇读书笔记里，具体大家看书吧。
架构设计要做到什么程度呢？架构设计包括好多个组成部分，程序如何组织，每个模块间如何通信，每个模块都负责什么？主要的类有没有定义出来，主要的数据是哪些？结构是怎样的，有哪些表？需要遵循哪些业务规则？大体的用户界面有没有设计出来？有哪些稀缺资源需要管理？如何管理？软件的安全需要什么样的级别，进行威胁建模了吗，都有可能面临哪些安全问题？哪些部分需要着重考虑性能问题？如果软件的使用者增大后，如何扩展软件满足用户需求？这个软件和其他已有软件或者系统的交互性如何？是否需要支持国际化？软件应该在哪个模块输入用户数据，哪个模块输出，在那一层检测IO错误？系统的错误处理策略是怎样的，检测到错误是否需要传递给调用者，还是只记录日志就可以了，是所有模块都要对数据有效性进行验证呢，还是有些模块可以假设输入的数据是干净的？系统的容错性是怎么考虑的，都需要容哪些错？系统架构的可行性如何，有没有先做出一些原型进行验证？有没有考虑过系统的健壮性，在考虑健壮性的时候是否进行了过度设计，对一些基本不会出现的情况进行了设计？有些模块或者功能是否直接买一套比自己做更划算？哪些模块可以重用，或者已经有可重用的模块？架构是否足够灵活，以很容易的面对需求的变化，是否对几乎以后肯定会有的需求进行了考虑？优秀的架构都是经过多次决策最终选定的比较靠谱的一个，在你具体进行详细设计和编码之前先针对架构师设计出来的架构问一下上面这些问题，判断一下架构是否已经准备好。
前期准备所花费的时间是不容易把握的，也没有个固定的衡量标准，但前期准备是必须要做的，前期准备的根本目的是降低风险，提高项目质量。