最近拜读导师推荐的一本书 《代码的精进之路》 在这本书中，作者引用了许多名人谚语，一针见血，总是别有一番风味也能让你幡然醒悟。
命名
变量名
变量名应该是名词，能够正确地描述业务，有表达力。如果一个变量名需要用注释来补充说明，那很有可能说明命名有问题。
函数名
函数名要具体，它体现的是做什么，而不是怎么做。
类名
类名是一组数据和操作的封装。对于一个应用系统，我们可以将类分为两大类：实体类和辅助类。
实体类承载了核心业务数据和核心业务逻辑，其命名要充分体现业务语义，并在团队内达成共识，如Customer,Employee等等；辅助类是辅佐实体类一起完成业务逻辑得，其命名要能够通过后缀来体现功能，例如，用来为Customer 做控制路由的控制类CustomerController，对于辅助类，尽量不要用Helper,Util之类的后缀，因为其含义太过笼统。
包名
包代表了一组有关系的类的集合，起到了分类组合和命名空间的作用，包名应该能够反映一组类在更高抽象层次上的联系，例如Apple、Pear，我们可以将它们放在一个包中，命名为fruit。包的命名要适合，不能太抽象也不能太具体。如Apple，那么将Pear、Orange放进包中就不适合了；如果太抽象，称为Object，Object无所不包，这便失去了用包来限定范围的作用。
模块名
相对于包来说，模块的粒度更大，通常一个模块包含了多个包，模块命名要有唯一性，另外名称要反映模块在系统中的职能
命名保持一致性
保持命名的一致性，可以提高代码的可读性，每个概念对应一个词。在项目，通常约定方法名，如：crud操作中 create 新增，add 添加，remove 删除。
使用对仗词，遵守对仗词的命名规则有助于保持一致性，从而提高代码的可读性。像first/last这样的对仗词就很容易理解。
注释
像Brian W.Kernighan 说的那样：“别给糟糕的代码加注释—重新写吧。”
注释，不要复述功能，注释要能够解释代码背后的意图，而不是对功能的简单重复，真正的高手是尽量不写注释。
很多人（包括我在没阅读这边书之前）觉得命名规范只是细节，但命名其实很难。书中在这一章开头就引用了两个名人的谚语，言简意赅的表达了命名的重要性。就像Stack OverFlow的创始人Joel Spolsky说的：“起一个好名字应该很难，因为好名字需要把要以浓缩在一到两词中”，Martin Fowler也表示过“在计算机科学中有两件难事：缓存失效和命名”；所以好的命名可以保证代码不仅是被机器执行的指令，更是人和人之间沟通的桥梁。也像channing哥说的，好的代码看着，不是在看代码，而是像看一本书
规范
代码规范
- 代码格式，代码格式关系到代码的可读性，因此需要遵从一定的规范，包括缩进、水平对齐、注释格式等
- 命名规范，每种语言都有自己独特的命名风格，javascript是弱类型语言，会使用匈牙利命名法的习惯（这个还第一次见）
- 异常规范，要统一处理异常，异常处理不统一，有的场景对外直接抛出异常，有的场景对外返回错误码，这种不一致性通常会让人摸不着头脑，增加了服务的使用成本和沟通成本
函数
参数数量
最理想的参数数量是零（零参函数），其次是一（一元函数），再次是二（二元函数），应尽量避免三（三元函数）
如果函数需要3个以上参数，就说明其中一些参数应该封装为类了。
短小函数
函数的第一规则是要短小，第二规则是要更短小。有时保持代码的逻辑不变，只是把长方法改成多个短方法，代码的可读性就能提高很多。超长方法是典型代码的“坏味道”，对超长方法的结构化分解是提升代码可读性最有效的方式之一。
职责单一
一个方法只做一件事情（华哥跟我说了好多次，拆分函数，哪怕只有一句话，只要有助于语义显性化的表达，也是值得的），也就是函数级别的单一职责原则（SRP），遵循SRP不仅可以提升代码的可读性，还行提升代码的可复用性。因为职责越单一，功能越内聚，
精简辅助代码
辅助代码，它不是处理业务逻辑的核心代码，但如判空、打印日志、缓存检查等等，这些代码往往会在多个函数中重复冗余，如果辅助代码太多，会极大地干扰代码的可读性。因此我们应该尽量减少辅助代码对业务代码的干扰。让函数中的代码能直观第体现业务逻辑，而不是让业务代码淹没在辅助代码中。
组合函数模式
组合函数要求所有的公有函数读起来像一系列执行步骤的概要，而这些步骤的真正实现细节是在私有函数里面。组合函数有助于代码保持精炼并易于复用。
