我有一个梦想，我写的代码，可以像诗歌一样优美。
我有一个梦想，我做的设计，能恰到好处，既不过度，也无不足。
整洁面向对象分层架构 （Clean Object-oriented and Layered Architecture， COLA ）
本书的结构本书共分为三大部分：技艺部分、思想部分和实践部分。
命名其实很难
命名为什么难呢？因为命名的过程本身就是一个抽象和思考的过程，在工作中，当我们不能给一个模块、一个对象、一个函数，甚至一个变量找到合适的名称的时候，往往说明我们对问题的理解还不够透彻，需要重新去挖掘问题的本质，对问题域进行重新分析和抽象，有时还要调整设计和重构代码。因此，好的命名是我们写出好代码的基础。
Martin Fowler也表示过，他最喜欢的一句谚语是：“在计算机科学中有两件难事：缓存失效和命名。（There are only two hard things in Computer Science: cache invalidationand naming things.）
- 变量名
变量名应该是名词，能够正确地描述业务，有表达力。 - 函数名
函数命名要具体，空泛的命名没有意义。例如，processData()就不是一个好的命名，因为所有的方法都是对数据的处理，这样的命名并没有表明要做的事情，相比之下，validateUserCredentials()或者eliminateDuplicateRequests()就要好许多。函数的命名要体现做什么，而不是怎么做。 - 类名
实体类承载了核心业务数据和核心业务逻辑，其命名要充分体现业务语义，并在团队内达成共识，如Customer、Bank和Employee等。
辅助类是辅佐实体类一起完成业务逻辑的，其命名要能够通过后缀来体现功能。例如，用来为Customer做控制路由的控制类CustomerController、提供Customer服务的服务类CustomerService、获取数据存储的仓储类CustomerRepository。 - 包名
包（Package）代表了一组有关系的类的集合，起到分类组合和命名空间的作用。包名应该能够反映一组类在更高抽象层次上的联系。例如，有一组类Apple、Pear、Orange，我们可以将它们放在一个包中，命名为fruit。
保持一致性
每个概念对应一个词，并且一以贯之。例如，fetch、retrieve、get、find和query都可以表示查询的意思，如果不加约定地给多个类中的同种查询方法命名，你怎么记得是哪个类中的哪个方法呢？同样，在一段代码中，同时存在manager、controller和handler，会令人感到困惑。因此在项目中，作者通常按照表1-1所示的约定，保持命名的一致性。
多使用对仗词
- add/remove
- increment/decrement
- open/close
- begin/end
- insert/delete
- show/hide
- create/destroy
- lock/unlock
- source/target
- first/last
- min/max
- start/stop
- get/set
- next/previous
- up/down
- old/new
小心注释
如果注释是为了阐述代码背后的意图，那么这个注释是有用的；如果注释是为了复述代码功能，那么就要小心了，这样的注释往往意味着“坏味道”（在Martin Fowler的《重构：改善既有代码的设计》一书中，注释就是“坏味道”之一），是为了弥补我们代码表达能力的不足。就像Brian W.Kernighan说的那样：“别给糟糕的代码加注释——重新写吧。
1．不要复述功能
2．要解释背后意图
