前四章为整本书所讲解的内容打下了基础
前两章先是解释了Software Construction（软件构建）的概念，然后又通过Metaphors（隐喻）使我们更充分的理解软件开发。
第三章则告诉我们在进行软件构建之前，需要Measure Twice，Cut Once（三思而后行），充分的考虑到构建之前的1.问题定义、2.需求分析、3.架构规划三个阶段中所出现的问题，以及如何去检验问题（参照检验表）。越早的发现问题则会减少很多不必要的开销。
第四章则告诉我们在进入构建之前需要确认的关键性的信息：明确所使用的编程语言的优点和缺点、明确代码规范，包括命名格式等；以及通过核对表核对主要的构建实践方法。
Chapter 1.Welcome to Software Construction
1.1什么是软件构建
软件开发过程中包括了许多不同的活动
· 问题定义
· 需求分析
· 架构规划
· 软件架构或高层设计
· 详细设计
· 编码和调试
· 单元测试
· 集成测试
· 集成
· 系统测试
· 功能强化
软件构建有时被称作“实现”，它有时被叫作“编码和调试”，有时也称之为“编程”
构建活动主要包括：详细设计，编码，调试，单元测试
1.2软件构建的重要性
· 构建活动是开发软件的重要组成部分
构建活动在整个软件开发中所占的时间为30%-80%之间
· 构建活动在软件开发中处于枢纽地位
分析和设计是构建活动的基础，对系统进行测试是其后续工作
· 把主要精力集中于构建活动，可以极大地提高程序员的生产效率
程序员的效率系数是10-20
· 构建活动的产品，源代码，往往是软件的唯一精确描述
需求说明和设计文档可能会过时，但源代码却总是最新的。因此，源代码必须具有最好的质量
· 构建活动是唯一一项必不可少的工作
Chapter 2. Metaphors for a Richer Understanding of Software Development
隐喻通过把软件开发与你所熟知的事情联系在一起，从而使你对其有更深刻的理解。
· Writing Code（写代码）
软件开发的过程，就是一行行编写代码的过程，如果是一个小的问题，我们可以直接用写代码来比喻，如果是大的问题，Writing Code可能并不能很好的描述软件开发的过程
· Growing a System（养成系统）& System Accretion（系统积累）
软件开发的过程，就是向原有系统中增加格外功能，逐渐养成积累成一个完善的系统
· Building Software（建造软件）
软件开发的过程，使用Building来形容，就好像建房子一样先打地基，然后房间架构搭建，最后才是放入门，电视等一系列家具，并且这些家具是可以在不改变地基，房间架构的情况下随意更换的。Building Software隐喻暗示了许多诸如计划、准备、执行等工作阶段。
· The Intellectual Toolbox（智能工具箱）
软件开发的过程有很多的方法和技巧，比如设计模式，面向对象的六个设计原则等等，在不断的开发过程中，我们会常常通过这些设计模式去解决问题。工具箱隐喻有助于帮助我们保留一切方式、技巧、技术等，并在适当的时候使用它们
· Combing Metaphors （复合隐喻）
隐喻之间并不互斥，多条隐喻可以来形容一个软件开发，Building Software和System Accretion，就能很好的描述我们现在所开发的项目
Chapter 3. Measure Twice, Cut Once: Upstream Prerequisites
“Measure Twice, Cut Once”对应我们中文：三思而后行
3.1前期准备的重要性
准备工作的中心思想就是降低风险：一个好的项目规划者能够尽早的将主要的风险清除掉
目前项目开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划
3.2辨明你所从事的软件的类型
3.3问题定义的先决条件
从客户的语言来定义问题
3.4需求的先决条件
稳定的需求是软件开发的圣杯。一旦需求稳定，项目就能有序平稳的进行。
可以通过核对需求表来分析需求是否好
功能需求核对
1.是否详细定义了系统的全部输入/输出，包括来源、精度、取值范围、出现频率、输入/输出格式？
2.是否详细定义了软件/硬件的外部接口？
3.是否列出了用户想要做的全部事情？
4.是否定义了每个任务所用到的数据？
非功能需求核对
1.是否为全部必要的操作？
2.是否描述了期望响应时间，处理时间，吞吐量等指标？
3.是否详细定义了安全级别？
4.是否定义了可靠性？错误检测和恢复策略？
5.是否包含对“成功”/“失败”的定义？
需求质量核对
1.需求是用用户的语言书写的吗？
2.需求之间是否冲突？
3.需求是否足够清晰？
4.需求是否都可测试？
5.是否描述了所有可能对需求的改动，包括各项改动的可能性？
需求的完备性
1.对于开发前无法获得的信息，是否详细描述？
2.如果产品满足这个需求，那么就是可接受的？
3.你对全部需求都感到舒服吗？你是否已经去掉了那些不可能实现的需求？
3.5架构的先决条件
架构的质量决定了系统的概念完整性，进而决定了系统的最终质量
好的架构应该包括下面几个内容：
· Program Organization（程序组织）
· Major Class（主要的类）
· Data Design（数据设计）
· Business Rules（业务规则）
· User Interface Design（用户页面设计）
· Resource Management（资源管理）
· Security（安全性）
· Performance（性能）
· Scalability（可伸缩性）
· interoperability（互用性）
· Internationalization/localization（国际化/本地化）
· input/output（输入输出）
· Error Processing（错误处理）
· Fault Tolerance（容错性）
· Architectural Feasibility（架构可行性）
· Overengineering（过度工程）
· Buy-vs.-Build Decisions（关于买还是造的问题）
· Reuse Decisions（关于复用的决策）
· Change Strategy（变更策略）
· General Architectural Quality（架构的总体质量）
3.6花费在前期准备上的时间长度
Chapter 4. Key Construction Decisions
4.1选用一门合适的语言
明确所使用的编程语言的优点和缺点
4.2编程约定
明确代码规范，编码风格，命名
4.4选择主要的构建实践方法
