第一部分 打好基础
第一章 欢迎进入软件构建的世界
软件构建是软件开发的核心活动;构建活动是每个项目中唯一一项必不可少的工作。
软件构建的主要活动包括:详细设计、编码、调试、集成、开发者测试(developer testing）(包括单元测试和集成测试）。
构建也常被称作“编码”和“编程”。
构建活动的质量对软件的质量有着实质性的影响。
第二章 用隐喻来更充分地理解软件开发
通过把软件的构建过程比作是房屋的建设过程，我们可以发现，仔细的准备是必要的，而大型项目和小型项目之间也是有差异的。
通过把软件开发中的实践比作是智慧工具箱中的工具，我们又发现，每位程序员都有许多工具，但并不存在任何一个能适用所有工作的工具，因地制宜的选择正确工具是成为有效编程的程序员的关键。
第三章 三思而后行：前期准备
准备工作的中心目标就是降低风险：一个好的项目规划者能够尽可能早的将主要的风险清除掉，以使项目的大部分工作能够尽可能平稳的进行。目前，软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划，因此准备工作就倾向于集中改进需求分析和项目计划。
你所从事的软件项目的类型对构建活动的前期准备有重大影响--许多项目应该是高度迭代式的，某些应该是序列式的。
如果没有明确的问题定义，那么你可能会在构建期间解决错误的问题。（找到需要打的靶）
如果没有做完良好的需求分析工作，你可能没能觉察待解决的问题的重要细节。（瞄准靶，选择好箭的飞行路线）
如果没有做完良好的架构设计，你可能会在构建期间用错误的方法解决正确的问题。架构变更的代价随着“为错误的架构编写的代码数量”增加而增加，因此，也要确认“架构”已经到位了。（根据距离的远近以及环境，选择适合的弓箭，安排每支箭的力度角度策略，力求最少的箭枝射中靶心）
架构包括：程序组织（主要构造块）、主要类、数据设计、业务规则、用户界面设计（如果需求阶段没有）、稀缺资源管理、安全性、性能、可伸缩性、互用性、国际化本地化、输入输出、错误处理、容错性、架构的可行性、过度工程（部分代码健壮，部分不健壮）、关于买还是造的策略、关于复用的策略、架构的总体质量、需求变更策略。
（评价：系统分析--类图静态、业务顺序图状态；业务类图--数据存储；通用类业务--平台框架组件）
第四章 关键的“构建”决策
本章关注的焦点是程序员和技术带头人必须（直接或间接）负责的准备工作。在向工地进发之前，如何选择合适的工具别在你的腰带上，你的手推车里该装哪些东西。
在高质量的软件中，你可以看到“架构的概念完整性”与“其底层实现”之间的关系。“实现”必须与（指导该实现的）“架构”保持一致，并且这种一致性
是内在的、固有的。这正是变量名称、类名称、子程序名称、格式约定、注释约定等这些针对“构建活动”的指导方针的关键所在。
假如没有一种统一的规则，你创作出来的东西将会充斥着各种不同的风格，显得混乱而邋遢。这些不同的风格将使你的大脑承受沉重负担--而这仅仅是为了理解不同编程风格之间的（本质上是随意的）差异。
大多数重要的编程原则并不依赖特定的语言，而依赖于你使用语言的方式。
在开始编程之前，做好一些约定。“改变代码使之符合这些约定”是近乎不可能的。
第二部分 创建高质量的代码
第五章 软件构建中的设计
无论是以何种方式来进行设计，小型项目也能和大型项目一样从精心的设计之中获益，而如果能认识到设计是一项明确的活动，你就更会获益匪浅。
5.1 设计中的挑战
设计是一个险恶的问题。你必须首先把这个问题“解决”一遍以便能够明确的定义它，然后再次解决该问题，从而形成一个可行的方案。
设计是个了无章法的过程（即使它能得出清爽的成果）。因为在此过程中你会犯很多的错误。还因为优劣设计之间的差异往往非常微妙。还因为你很难判断设计何时算是“足够好”了。设计到什么细节才算够？有多少设计需要用形式化的设计符号完成，又有多少设计可以留到编码时再做？什么时候才算完成。
设计就是确定取舍和调整顺序的过程。
设计受到诸多限制。
设计是不确定的。
设计是一个启发式过程。
设计是自然而然形成的。他是不断的设计评估、非正式讨论、写试验代码以及修改试验代码中演化和完善的。
5.2 关键的设计概念
软件的首要技术使命：管理复杂度
作为软件开发人员，我们不应该试着在同一时间把整个程序都塞进自己的大脑，而应该试着以某种方式去组织程序，以便能够在一个时刻可以专注于一个特定的部分。
所有软件设计技术的目标都是把复杂问题分解成简单的部分。子系统间的相互依赖越少，你就越容易在同一时间里专注问题的一小部分。精心设计的对象关系使关注点相互分离，从而使你能在每个时刻只专注于一件事情。在更高汇聚的层次上，包（packages）提供了相同的好处。
保持子程序的短小精悍也能帮助你减少思考的负担。从问题的领域着手，而不是从底层实现入手去编写程序，在最抽象的层次上工作，也能够减少人的脑力负担。
一个程序中的设计层次。系统1首先被组织为子系统2子系统被进一步分解为类3然后类又被分解为子程序和数据4每个子程序的内部也需要进行设计
5.3 设计构造块：启发式方法
找出现实中的对象。在确定设计方案时，首选且最流行的一种做法便是“常规的”面向对象设计方法，此方法的要点是辨别现实世界中的对象以及人造的对象。
形成一致的抽象。
封装实现细节。当继承能简化设计时就继承。
隐藏秘密（信息隐藏）。信息隐藏中所说的秘密主要分为两大类：隐藏复杂度；隐藏变化源。问题“这个类需要隐藏些什么？”正切中了接口设计的核心。在设计的所有层面上，都可以通过询问该隐藏些什么来促成好的设计决策。
找出容易改变的区域。
预料不同程度的变化。
保持松散耦合。
查阅常用的设计模式。
下列的启发式方法有时也很有用：高内聚性、构造分层结构、严格描述类契约、分配职责、为测试而设计、避免失误、有意识的选择绑定时间、创建中央控制点、考虑使用蛮力、画一个图、保持设计模块化
5.4 设计实践
分而治之
自上而下和自下而上的设计方法
建立试验性原型
合作设计
要做多少设计才够
记录你的设计成果
要点
软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助。
简单性可以通过两种方式获取：一是在同一时间所关注的本质性复杂度的量，二是避免生成不必要的偶然的复杂度。
设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序。
好的设计都是迭代的。你尝试设计的可能性越多，你的最终设计方案就会变得越好。
信息隐藏是个非常有价值的概念。通过询问“我应该隐藏些什么？”能够解决很多困难的设计问题。
文章参考https://wenku.baidu.com/view/d856fb1ba8114431b90dd859.html#