前言
有时候业务交付压力使得开发人员只关注了交付本身，而忽略了质量，但作为一名研发人员，质量上是不能够作让步的。有些业务金融敏感，搞砸了很可能损害公司商业利益，自己也丢掉饭碗。因此，重申质量的重要性是很有必要的。
质量是上百万次全身心投入的结果，需要落实到每天，每小时之中。开发工作中，我们通常会遇到2种情形，一种是新特性开发，特点是与原有代码关联较少，另一种是特性增强，需要改大量原有代码。开发人员通常会想先把功能开发完成，再去重构、优化，虽然说出发点不错，但稍后等于永不(Later equals never)。
这里我提出自己的想法，抛砖引玉。
- 对于自己编写和改动的部分，有重构思路可以直接着手修改，不然拖到转测了后只会不了了之。对于非特性开发范围的不合理的代码，需要认真评估。
对于有把握的重构、优化(必须能够评估影响)，不要害怕修改。重构其实不意味着重写，提取方法，修改参数命名等等利用IDE是比较安全便捷的。我们要胆大心细，谨慎地修改，修改后一定要自测通过，确保DevOps测试用例通过，最好申请重构单号，单独做一次commit，在代码评审时请大家评审自己的改动。 - 对于无法评估的影响范围和后果的修改，坚决不修改，要学会敬畏，否则一个配置的改动将引发大灾难。
作为开发，要做到小处诚实，放下身段，谦虚审慎承认代码现状，做到不自欺，而后思改进。
写代码跟写文章一样，结构条理清晰，如白居易的诗一样通俗易懂，代码即注释，注释太多可能预示着功能的难以理解，代码含义应由自身表达，重构时直接以用代码代替文字描述列大纲，从上到下去编写。
此外重构的过程，遵循小步快跑，重构完一个独立的代码片段应该及时验证。
整洁代码定义
衡量代码质量的唯一有效标准：WTF/minute in code review，意思是代码评审者每分钟骂出”WTF”的频率=w=
写整洁代码，要遵循大量小技巧。
把写代码当成故事来讲，让听故事的人能够清晰的了解整个故事情节。
破窗理论：一栋建筑的窗户破了，如果没人去修理，那将越来越多人的破坏其他窗户。意思是环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。
代码开发中深受破窗理论影响，想必每个开发都会遇到代码中一串长长的if else if条件代码块在不断膨胀，因为人们刚开始觉得不对劲，但是想了想应该有历史原因而效仿着前辈，继续写着shit code，却没有人想着用多态或者查表得方式重构下。
什么是整洁代码
几乎没有改进的余地的代码即好代码
- 通过所有测试
- 没有重复代码
- 体现系统中的全部设计理念
所有程序都由极为相似的元素构成，如“在集合中查找某物”，一旦出现这种情况，可以把实现手段封装到更抽象的方法中。
一个人写代码的过程，读与写花费时间的比例超过10:1，因此要先让代码易读。
让营地比你来时更干净，消除重复和提高表达力。
命名
名副其实
- 一旦发现更好的名称，就换掉旧的。
- 上下文在代码中要被明确的体现出来，降低代码的模糊度。
避免误导
举例：accountList的list有特殊含义，考虑accounts, accountGroup, bunchOfAccounts
做有意义的区分
xxxInfo，xxxData是废话
一些准则
- 使用读得出来的名称
- 使用可搜索的名称
- 避免使用新的编码约定
- 类名应是名词或名词短语
- 避免使用Manager, Processor等？
- 方法名应当是动词或动词短语
- 使用解决方案领域名称
- 添加有意义的语境
- 前缀不要添加没有用的语境，短名称足够清楚就比长名称好
函数
- 短小、还要更短小。100行以内，20行最佳
- 只做一件事。判断一个函数是否只做了一件事，就看是否能再拆出一个函数
- 每个函数一个抽象层级，自上而下读代码
- Switch语句可以考虑利用多态，移动到工厂底下
- 使用描述性的名称，长而具有描述性的名称，比短而令人费解的名称好，比描述性的注释好；命名方式保持一致
- 函数参数
- 函数参数尽量少，超过3个参数可以考虑参数对象的方式。没有参数时需要注意是否大量运用上下文，大量运用上下文不是一个好的设计。
- 标识参数丑陋不堪，不要往参数传入布尔值（意味着true做一件事，false做另一件事）
- 遵循数学约定表示，如new Point(x, y)也是见参知义。
- 动词、动名词做为参数名称
- 无副作用，函数只承诺做一件事，但实际是谎言。
- 避免使用输出参数。
- 分隔指令（做某件事）与询问（判断语句）
- 使用异常替代错误码，因为返回错误码意味着可能要马上进行处理
- 抽离try/catch块
注释
- 别给糟糕的代码加注释，重新写吧。
- 注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败，注释总是一种失败。把力气用在写清楚代码上。
格式
- 关系密切的概念和代码应该互相靠近，便于阅读理解，如函数调用，调用者放在被调用者的上面。
- 变量声明应该靠近使用的位置
- 遵循一个编程规约，如阿里Java编程规约
声明：本站所有文章均为原创或翻译，遵循署名 - 非商业性使用 - 禁止演绎 4.0 国际许可协议，如需转载请确保您对该协议有足够了解，并附上作者名 (Tsukasa) 及原文地址
