在意代码。消除重复代码和提高表达力。
必须时时保持代码整洁。
注意命名，而且一旦发现有更好的名称，就替换掉旧的命名。
第二章、有意义的命名。——想要给变量一个好的命名就要学好英语。没有英语功底连个命名都很难做到。
a、名副其实。如果名称需要用注释来补充，那就不是名副其实了。
b、做有意义的区分。要区分名称，就要以读者能鉴别不同之处的方式来区分。
c、使用读得出来的名称。
d、使用可搜索的名称。
单字母名称仅用于短方法中的本地变量。名称长短应与其作用域大小相对应。若变量或常量可能在代码中多处使用，
应赋予其便于搜索的名称。
类名和对象变量名应该是名词或名词短语。
方法名应该是动词或动词短语。
第三章、函数
函数的规则：短小、更短小。
if语句、else语句、while语句等，其中的代码块应该只有一行。改行大抵应该是一个函数调用语句。这样不但能保持
函数短小，而且，因为块内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。
函数应该只做一件事。
每个函数一个抽象层级。？？——难！！
创建一个描述与注释所言同一事物的函数即可。
自顶向下读代码：向下规则
使用描述性的名称。选择描述性的名称能理清你关于模块的设计思路，并帮你改进。追索好名称，往往导致对代码的
改善重构。
函数参数。最理想的参数数量是零(零参数函数)，其次是一，再次是二，应避免三参数函数。有足够特殊的理由才能
用三个以上的参数。
我们惯于认为信息通过参数输入函数，通过返回值从函数输出。
如果函数看来需要两个、三个或三个以上的参数，就说明其中一些参数应该封装为类了。
普遍而言，应避免使用输出参数。如果函数必须要修改某种状态，就修改所属对象的状态吧。
函数要么做什么事，要么回答什么事，但二者不可兼得。函数应该修改某对象的状态，或是返回该对象的有关信息。
两样都干会导致混乱。
第六章 、对象和数据结构：
隐藏实现并非只是在变量之间放上一个函数层那么简单。隐藏实现关乎抽象！类并不简单地用取值器和赋值器将
变量推向外间，而是暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体。
接口内部之定义了方法，却没有方法的具体实现。把方法的声明和实现分开了。
看了代码整洁之道才真正的了解到学好英语的重要性。
别返回null值，别传递null值。
第八章 边界
如果你使用类似Map这样的边界接口，就把它保留在类或近亲类中。避免从公共API中返回边界接口或将边界
接口作为参数传递给公共API。
给第三方程序包做学习性测试。
呵呵，终于明白了什么叫封装变化。
整洁的边界：边界上会发生有趣的事。改动是其中之一。有良好的软件设计，无需巨大的投入和重写即可进行修改。在使用我们控制不了的代码时，
必须加倍小心保护投资，确保未来的修改不至于代价太大。边界上的代码需要清晰的分割和定义了期望的测试。应该避免我们的代码过多的了解第三方
代码中的特定信息。依靠你能控制的东西，好过依靠你控制不了的东西，免得日后受它控制。我们通过代码中少数几处引用第三方边界接口的位置来
管理第三方边界。在边界两边推动内部一致的用法，当第三方代码有改动时修改点也会更少。
第九章 单元测试
测试代码和生产代码一样重要。保持测试代码的整洁同样重要。
没有了测试，你就会失去保证生产代码可扩展的一切要素。正是单元测试让你的代码可扩展、可维护、可复用。
覆盖了生产代码的自动化单元测试程序组能尽可能地保持设计和架构的整洁。测试带来了一切好处，因为测试使
改动变得可能。
整洁的测试要素是：可读性。明确、简洁和足够的表达力。
整洁测试遵循5条规则：
1、快速
2、独立
3.可重复
4、自足验证
5、及时
第十章 类
遵循标准Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有
实体变量。很少有公共变量。公共函数应跟在变量列表之后。
类应该短小。单一职责原则。
类的名称应当描述其职责。命名也是帮助判断类的长度的第一个手段。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个职责，只有一个修改的原因，并与少数其他类
一起协同达成期望的系统行为。
让软件能工作和让软件保持整洁，是两种截然不同的工作。我们中的大多数人脑力有限，只能更多地把精力放在让代码能
工作上，而不是放在保持代码有组织和整洁上。
内聚。 类应该只有少量实体变量。内聚性高意味着类中的方法和变量相互依赖、互相结合成一个逻辑整体。
保持内聚性就会得到许多短小的类。
将大函数拆分为许多小函数，往往也是将类拆分为多个小类的时机。程序会更加有组织，也会拥有更为透明的结构。
开放封闭原则。对扩展开放(extends)，对修改关闭。
依赖倒转原则。
第12章 迭进
测试消除了对清理代码就会破坏代码的恐惧。
在重构过程中，可以应用有关优秀软件设计的一切知识。提升内聚性，降低耦合度，切分关注面，模块化系统性关注面，缩小
函数和类的尺寸，选用更好的名称，如此等等。这也是应用简单设计后三条规则的地方：消除重复，保证表达力，尽可能减少
类和方法的数量。
用心是最珍贵的资源。
第11章 系统
我们应该只去实现今天的用户故事，然后重构，明天再扩展系统、实现新的用户故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、
重构以及它们打造出的整洁代码，在代码层面保证了这个过程的实现。
软件系统与物理系统可以类比。它们的架构都可以递增式的增长，只要我们持续将关注面恰当地切分。
最佳的系统架构由模块化的关注面领域组成，每个关注面均用纯Java(或其他语言)对象实现。不同的领域之间用最不具有侵害性的方面或
类方面工具整合起来。这种架构能测试驱动，就像代码一样。
模块化和关注面切分成就了分散化管理和决策。
第13章 并发编程 (这一章很好，多读几遍)
对象是过程的抽象。线程是调度的抽象。
并发是一种解耦策略。它帮助我们把做什么(目的)和何时(时机)做分解开。在单线程应用中，目的与时机紧密耦合。
解耦目的与时机能明显的改进应用程序的吞吐量和结构。从结构的角度来看，应用程序看起来更像是许多台协同工作的
计算机，而不是一个大循环。系统因此会更易于被理解，给出了许多切分关注面的有力手段。
第14章 逐步改进 (例子)
第17章
每次看到重复代码，都代表遗漏了抽象。
