释义好代码

1、近况

世间百态人情暖，万般滋味皆生活。

近来年底，互联网的寒冬也传递到了我的身边。工作以来感觉这两年的时光是最开心的。但行业的整体下行，致使裁员已经蔓延到大大小小的公司。很好的一个朋友喜提大礼包，离开了曾经的岗位。而另外一个朋友也因为身体原因匆匆入院了，据他说明年开年回来就准备run了。尽管天下无不散筵席，但临别时的伤感、离开后的冷清也让我感觉生活中少了些什么......

2、引言

书接上回，上一节我给出了好代码的定义，你且别往前翻了，问问自己是否还记得。

想不起来没关系，再重复一遍，易读性、可维护性、可复用性、可测试性。最后一次重复了，不管你用什么办法（记东西要用自己的方法，每个人思维模式不一样），记住它们好吗？

那今天这篇我们就展开着四项详细聊聊。

3、易读性

马丁福勒曾经说过：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”，翻译一下：任何傻瓜都可以写电脑可以理解的代码。好的程序员写人能够理解的代码。好好好，你话是真多。此话不假，当我们看到一段“乱七八糟”、“很难理解的代码”、“又不得不去查BUG”的代码时候，难免会骂上两句：“holy shit!”。

那易读性的代码有哪些特征呢？

我愿意用一句话总结：规范！！！

3.1、命名和注释

条目	说明
精准命名	函数名要准确表达函数“做什么”
限定命名法	项目中采用一致的命名法（驼峰，蛇形，匈牙利等）
有效注释	解释“为什么”，“怎么做”，甚至“怎么用”

通常情况下函数名已经能够说明该函数“做什么”了。有人会想那还要注释干嘛？注释主要作用是说明“为什么”、“怎么做”，更甚至可以补充“如何用”。

3.2、代码风格

条目	意义	建议
空行	1. 语意分割	逻辑断层的地方增加空行
行数	1. 鲲之大，一“屏”放不下，避免滚轮冒烟 2. 什么都要只会害了你，避免看完后面忘前面	建议：20 - 80
列数	同上	建议：120

风格通常就是我们项目中经常提到到checklist，每个团队都会制定自己的规范，当然也有一些小团队无规范可言。无规矩不成方圆，良好的代码习惯不仅让你自己代码写的有迹可循，它对团队的效率提升也是非常显著的。

3.2、技巧

条目	说明
引入参数对象	特定的一组参数总是一起被传递，将其作为一个整体
勿用参数控制逻辑	通常可以再拆分函数

这部分来源于：Refactoring Cheat Sheet，经典《重构》。

注：仅仅举例说明三种类型的规范，后面我将整理一片尽量完整规范文章，可以当做checklist直接使用的那种。

4、可维护性

条目	说明
易改	不破坏原有逻辑，不引入新的风险即可修复问题
易拓展	对于新的功能点通过可插拔的方式添加到原有代码中

可维护性它不是个好东西，因为说起来容易做起来难；但它又是个好东西，做好了它人人都夸你是个帅小伙。后续文章关于面向对象、设计原则、设计模式等等...，均是围绕这个来的。

5、可复用性

条目	说明
抽象	在重复中寻找规律，是不是的就“抽”一下

我们通常讲到抽象，就会简单的理解为将某个函数包装一下，但本质上我们“抽”一下，终究是为了去重。我们看下抽象的定义，抽象：从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。抽共性而去其杂，是不是很符合可复用性。

当然，这里的抽象不要简单理解为抽象函数，可以上升到函数、模块、组件......

6、可测试性

条目	说明
写单测	侧面印证代码复不复杂

实践是检验真理的唯一标准，首先你得实践，我想大多数公司都一样，产品火急火燎，研发匆匆忙忙，单测有时间则写，没时间则无。但如果我们想深入研究一下怎么写好代码，我建议可以多关注一下单测。如果你的函数需要写七八个单测还覆盖不全场景，那就需要考虑再“抽”一下了。正常一般3~5个就应该能够覆盖住。

7、后记

好好好，今天就这么多，主要是展开好代码的特性，加固一下我们印象。

在后续的文章中，我们再依次介绍这些特性该通过什么技巧去实现。