标签：
文/罗恩良
优秀编码很难。即使在有很多编码书籍、编程规范的情况下，绝大部分项目输出的代码依旧质量不高。
为什么会出现这种情况？我觉得主要是因为不分轻重、面面俱到，“面面俱到”必然导致“面面不到”。数十本编码必读的书籍、好几千页、22 种坏味道、72 种重构方法，让绝大多部程序员不堪重负，根本记不住，更不说有效地应用了。
那有没有简单有效的方法快速提升团队的编码水平，人人都能写高质量优秀代码？
本篇文章总结提取出优秀编码最重要的四个原则，不用面面俱到，只是简单地应用了此四原则，我所在部门团队的编码水平就提高了一个层次。团队有部分成员也反馈现在的编码水平和二个月前的编码已不在同一个层次。
我个人认为，函数单一抽象层次是优秀编码中最重要的原则，没有之一！单一抽象层次指一个函数或者方法中所有的操作处于相同层次。
如上图所示，一个函数或方法中所有的操作处于相同逻辑层次。
过分深层的缩进，或者“嵌套”已经困扰了计算机界达几十年之久，而且至今仍然是产生混乱代码的罪魁祸首之一。
Noam Chomsky 和 Gerald Weinberg 做过一份研究表明，很少有人能够理解超过 3 层的嵌套 (Yourdon 1986a)，很多研究人员建议避免使用超过 3 层的嵌套。
如上图所示，以卫语句取代嵌套条件表达式是最少化缩进的精髓之一。卫语句可以把我们的视线从异常处理中解放出来，集中精力到正常处理的代码中。
上面这段代码可以改编成下面的样式：
▼
总结： 如下图所示，简化复杂的 if else 语句，基本就是三个手段：
针对头重脚轻的 if else，尽早使用 return 返回，从而减少嵌套层次；
合并分支。有些分支持执行的内容相同，可以合并成为一个分支；
扁平化。这个例子就是扁平化最好的示例。
优秀代码不是越少越好，而是理解它所花的时间越少越好。
代码应当使别人理解它所需的时间最小化---这就是非常重要的“可读性基本定理”。
清晰表达式原则是这个基本定理的一个重要原则之一。
什么是清晰表达原则？以下是一些例子，请各位参考。
▼
前面讲的三个原则都是在讨论如何编写良好的函数，编写良好易读的代码行和代码块，现在我们来把注意力放在代码组织的更高层面，这一部分将涉及到软件设计中最重要的能力——类的职责分配问题。
如果你编写的类有几十个甚至上百个方法，或上千行代码，一般都说明这个类设计上有问题了。
类和人一样，职责多的类就像职责多的领导，领导需要秘书和助理，因为秘书和助理能帮助领导从琐事中解放出来。巨型类也一样，也需要辅助类把与主业务逻辑无关的事移除出去。
哪些琐事应该交给助理来处理？不产生数据的函数，不修改数据的函数，或有输入就有明确输出的函数，不和外部对象交互的函数等。
下面是两个例子：
▼
理解函数所花的时间，应该越短越好。
笔者认为人人都能写优秀代码，优秀代码都是一遍一遍地改出来的。允许先写肮脏的代码，但必须重构它。
标签：
原文地址：http://blog.csdn.net/huawei_esdk/article/details/52535462
