第一章 引言
我们最需要掌握的就是，提高代码质量的科学方法。
第二章 缺失的科学
软件设计的科学就是为软件做计划、制定决策的科学。
它能帮助大家做出这类决定：
- 程序的代码应当采用什么结构
- 是程序的速度重要还是代码容易阅读重要
- 为满足需求应该选择哪种编程语言
软件系统中任何与架构有关的技术决策，以及在开发系统中所作的技术决策，都可以归到软件设计的范畴里。
软件设计的基础规则
定义： 告诉你事物是什么，应当如何使用。
事实： 是关于事物的真实陈述，每一点真实的信息都是事实。
条例： 是给你确切的建议，它包含某些具体的信息，用于制订决策。但是条例并不能帮你绝对的预测未来，也不能帮你发现其他真理，它们通常会告诉你是否需要采取某些行动。
规则： 是永远为真的事实，它涵盖了很多领域的知识。它们帮你发现其他重要的真理，帮你预测未来要发生的事情。
计算机科学是对信息处理所作的数学研究。他并不像一些人认为的那样，是关于计算机编程的学问。
软件管理的科学和软件设计的科学
软件管理的科学告诉我们的是，如何为程序员分配工作，如何制定发布计划，如何估量任务所需的时间，诸如此类，比如敏捷软件开发。
软件设计的科学 ... 在任何语言中编写程序时都应当遵循的若干基础定律和规则。
软件复杂性的主要根源在于缺乏科学。
第三章 软件设计的推动力
在编写程序时，我们应当知道自己为什么要编程，最终目标什么。
有没有办法，可以把各种软件的目标都汇总到一起？如果有，那么整个软件设计的科学就有了方向，因为我们知道自己要做什么。
其实，全部软件都有一个相同的目标：帮助其他人。
《微博四特新世界美语词典》里是这么定义帮助的： (让人)能更容易的做某事；帮助；协助。特指定完成部分工作，减轻或分担工作量。
在评估开发或维护软件系统的建议时，它能给用户多少帮忙绝对是一个重要而且基础的问题。
总之，在软件设计时，应当把目标-帮助他人-视为应该考虑的最重要因素。这样，我们才能认识并了解软件设计真正的科学。
软件设计科学的目标：
- 确保软件能提供尽可能多的帮助
- 确保软件能持续提供尽可能多的帮助
- 设计程序员能尽可能简单的开发和维护的软件系统，这样的系统才能为用户提供尽可能多的帮助，而且能持续提供尽可能多的帮助
第四章 未来
在设计软件时，应该做怎样的决定？面对众多的可能，哪一个才是最好的？我们不是要绝对的好坏，而是要知道，这些可能的选择中，哪些最好。
软件设计方程式：
D = V/E
其中：
D 表示这个变化的合意程度（可取程度）。我们对此项工作的需求有多么迫切
V 表示它的价值，该变化有多少价值
E 表示完成这个变化的成本
这个公式的意思是： 任何一点改变，其合意程度与其价值成正比，与所付出的成本成反比。
方程式中的价值
- 价值的可能性和潜在价值
- 平衡危害
- 赢得用户的价值
成本
预测某个变化的成本时，重要的是要考虑牵涉的所有投入，而不仅仅是编程时间，研究要花多少时间？开发人员的沟通要花多少时间？所作的思考要花多少时间？简单地说，与这个变化有关的每一点时间，都是成本的一部分。
维护
- 时间，所有的变化都需要维护。
- 考虑现在价值和未来价值。
- 功能的价值随时间变化。
成本 E = 实现成本 Ei + 维护成本Em
价值 V = 当前价值 Vn+ 未来价值Vf
完整的方程式
随着时间的流逝这个方程式就变成了
其实，几乎所有的软件设计的决策都完全忽略了未来价值与维护成本的对比，有时候当前价值和实现成本足够大，始终在决策中占有决定性的地位，但是这种情况是少见的。一般来说，软件系统都需要维护很长时间，大多数情况下，未来长期受益和维护成本才是真正需要考虑的，与之相比，当前价值和实现成本变得无足轻重。
更合意的是这样的工作：虽然实现成本很高，维护成本却会下降，如果维护成本会随时间推移而逐步降低，这项工作就会变得越来越有价值，所以我们才说这样做更合意。
简而言之：相比降低实现成本，降低维护成本更加重要。
设计的质量
设计质量的好坏，正比于该系统在未来能持续帮助他人时间的长度。
不可预测的结果
未来的某些事情，是我们所不知道的。程序员犯的最常见也是最严重的错误，就是在其实不知道未来的时候去预测未来。
在进行决策时，未来才是最重要的事情，但在进行决策时，考虑未来的变数和尝试预未来，是有区别的。
在软件设计时，可以根据已知信息做某些决策，目的是为了创建更好的未来(提升价值，降低维护成本)，而不必预测未来究竟会发生什么具体的事情。
当然，也有少量例外，有时候你确切知道未来短期会发生什么，便可以据此决策。如果这样做，必须对未来有相当的把握，而且这种未来必须触手可及。无论你多聪明，肯定没有简单的办法准确的预测长期未来。
第五章 变化
软件必须随环境变化而变化，才能适应所处的环境。
变化定律： 程序存在的时间越久，它的某个部分需要变化的可能性就越高。
关键在于，你不需要不预测什么会变化，你需要知道的是，变化必然会发生，程序员保证尽可能合理的灵活性，这样，不管未来发生什么变化，都可以应付得了。
软件设计的三大误区：
- 编写不必要的代码
- 不要编写不是必须的代码，并且要删除没有用到的代码
- 代码难以修改
- 僵尸设计：对未来做太多假设、不仔细设计就编写代码
- 避免僵尸设计： 设计程序时，应当根据你现在确切知道的需求，而不是你认为未来会出现的需求
- 过分追求通用
渐进式开发及设计
它要求按照特定顺序，一点一点的设计和构建系统。
第六章 缺陷与设计
缺陷概率定律 ： 在程序中新增缺陷的可能性与代码修改量成正比。
最好的设计，就是能适应外界尽可能多的变化，而软件自身的变化要尽可能少。
如果不添加代码，不修改代码，就不会引入新的缺陷，这是软件设计中的一条主要规律。
永远不要 “修正”任何东西，除非它真的有问题，而且有证据表明问题确实存在。
避免重复
理想情况下，任何系统里的任何信息，都应当只存在一次。
使用各种编程技巧，让各处的代码可以“使用”，“调用”，“包含”已有的其他代码。
遵守这条规则的一个强有力的理由，就是缺陷概率定律。如果新增功能时可以重用代码，就不需要写太多代码，引入错误的可能性也就随之减少了。
第七章 简洁
简洁
简洁定律 ： 软件任何一部分的维护难度，反比与该部分的简洁程度。
某一部分代码越简洁，未来进行变化的难度就越低。
一致性
一旦你理解了某种的复杂性，就不必再进行重复劳动。
可读性
代码的可读性主要取决于字母与符号之间的空白排布。
可读性的另一部分重要的内容将就是为变量、函数、类等选择合适的名字。
名字足够长，能够完整的表达其意义或描述其功能，但不能太长，以免影响阅读。
注释
第八章 复杂性
主要： 新增功能
其次： 1. 扩展软件的用途
2. 新增程序员
3. 做无谓的改变
4. 困与糟糕的技术
5. 理解错误
6. 糟糕的设计或者不做设计
7. 重新发明轮子
糟糕的技术
出现复杂性的另一个常见原因就是，系统里选择了错误的技术。
既然无法预测未来，现在就决定要选择什么技术并不简单，好在，在开始使用之前，你可以通过三个因素来判断技术是否 “糟糕”，生存潜力、互通性、对品质的重视。
生存潜力
某种技术的生存潜力，就是它持续获得维护的可能性。
互通性
互通性，指如果需要，从一种技术切换到另一种技术有多难。
对品质的重视
这是一种更主观的衡量，其思考是考察最近的发布中，产品是否更加完善了。
其他原因
在选择技术时，还有其他因素需要考虑，主要是它是否简洁、是否符合软件的基本用途，在衡量完所有的实际因素之后，也可以考虑个人喜好。
复杂性及错误的解决方案
通常，如果某件事情变得非常复杂，也就意味着绝不是表面的复杂那么简单，而是设计出了问题。
真正要解决的问题是什么？
如果事情变得复杂，不妨回头看看真正要解决的是什么问题。
复杂问题
问题复杂，解法不一定复杂，相反，在处理此类问题时，你必须更努力的追求代码的简洁。
大多数麻烦的设计问题，都可以用在纸上画图或写出来的办法找到答案。
第九章 测试
你对软件行为的了解程度，等于你真正测试它的程度