笔记-代码精进之路：从码农到工匠

我有一个梦想，我写的代码，可以像诗歌一样优美。
我有一个梦想，我做的设计，能恰到好处，既不过度，也无不足。

整洁面向对象分层架构 （Clean Object-oriented and Layered Architecture， COLA ）

本书的结构本书共分为三大部分：技艺部分、思想部分和实践部分。

命名其实很难

命名为什么难呢？因为命名的过程本身就是一个抽象和思考的过程，在工作中，当我们不能给一个模块、一个对象、一个函数，甚至一个变量找到合适的名称的时候，往往说明我们对问题的理解还不够透彻，需要重新去挖掘问题的本质，对问题域进行重新分析和抽象，有时还要调整设计和重构代码。因此，好的命名是我们写出好代码的基础。

Martin Fowler也表示过，他最喜欢的一句谚语是：“在计算机科学中有两件难事：缓存失效和命名。（There are only two hard things in Computer Science: cache invalidationand naming things.）

1. 变量名
   变量名应该是名词，能够正确地描述业务，有表达力。
2. 函数名
   函数命名要具体，空泛的命名没有意义。例如，processData()就不是一个好的命名，因为所有的方法都是对数据的处理，这样的命名并没有表明要做的事情，相比之下，validateUserCredentials()或者eliminateDuplicateRequests()就要好许多。函数的命名要体现做什么，而不是怎么做。
3. 类名
   实体类承载了核心业务数据和核心业务逻辑，其命名要充分体现业务语义，并在团队内达成共识，如Customer、Bank和Employee等。
   辅助类是辅佐实体类一起完成业务逻辑的，其命名要能够通过后缀来体现功能。例如，用来为Customer做控制路由的控制类CustomerController、提供Customer服务的服务类CustomerService、获取数据存储的仓储类CustomerRepository。
4. 包名
   包（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．要解释背后意图