几乎在每个团队，都至少有一份代码规范，或者代码的check list。然也就仅仅是一份清单。
每次团队复盘时，都会有一条，我们要写好代码，然“好代码”是什么样子，什么标准，全取决于各人的水平。
每个程序员也都知道code review的重要性，然排期很紧张，难得做一次。宁可花时间追查问题，也不做防御性准备。
这些现象，是不是特别平常，虽然很想改变，但又是无力感呢。
程序员对代码的追求态度决定了职业生涯的高度，代码的质量决定了生活质量。
为什么会有上面提到的现象，大概有这两方面的原因：
1、每个人对“好代码”的观念不一样
2、对于“坏味道”缺乏明确的表象判断，也就很难提出明确的改进措施
好代码
什么样的才是好代码，耳朵听出老茧的那句话“高内聚，低耦合”，可是这句话，太抽象了，类似之前总结的SOLID原则[1]，需要更具体的特征。这也类似于要先把书读厚的原因。
怎么培养对代码的审美高度？
首先需要大量阅读好代码，可以去阅读很多开源项目。
其次找个导师，让自己的代码多被审视。
坏味道
如果说好是没有标准的，那坏是有限的。
对象健身操
这是Thoughtworks文集中，有一套对象健身操。保持9条规则。
1、 方法只使用一级缩进
2、 拒绝使用else关键字
3、 封装所有原生类型和字符串
4、 一行代码只有一个“.”运算符
5、 不要使用缩写
6、 保持实体对象简单清晰
7、 任何类中的实例变量都不要超过两个
8、 使用一流的集合
9、 不要使用任何Getter/Setter/Property
重构
经典书籍《重构》、《Clean Code》都是让代码质量提升的优秀教材。它们都是工具书，时时拿出来对照书本检查代码。
在《重构》中，明确列出了多项“坏味道”，并给出了重构方法：
1、 Duplicated Code（重复的代码）
2、 Long Method（过长函数）
3、 Large Class（过大类）
4、 Long Parameter List（过长参数列）
5、 Divergent Change（发散式变化）
6、 Shotgun Surgery（霰弹式修改）
7、 Feature Envy（依恋情绪）
8、 Data Clumps（数据泥团）
9、 Primitive Obsession（基本型别偏执）
10、 Switch Statements（switch惊悚现身）
11、 Parallel Inheritance（平行继承体系）
12、 Lazy Class（冗赘类）
13、 Speculative Generality（夸夸其谈未来性）
14、 Temporary Field（令人迷惑的暂时值域）
15、 Message Chains（过度耦合的消息链）
16、 Middle Man（中间转手人）
17、 Inappropriate Intimacy（狎昵关系）
18、 Alternative Classes with Different Interfaces（异曲同工的类）
19、 Incomplete Library Class（不完整的程序库类）
20、 Data Class（单纯的数据类）
21、 Refused Bequest（被拒绝的遗赠）
22、 Comments（过多的注释）
当然，实际工作中，不能消除所有坏味道，但只要能做到命名合理、没有重复、各个代码单元(类、函数)体量适当、各个代码单元有明确且单一的职责、各个代码单元之间有恰当的交互，就已经是质量相当高的代码了。
我会按上面的内容结合实际工作，出一份Clean Code系列[2]，早日让代码摆脱坏味道。
References
[1] SOLID原则: https://www.zhuxingsheng.com/tags/SOLID/
[2] Clean Code系列: https://www.zhuxingsheng.com/tags/Clean-Code/
