关于代码可读性

最近一直在思考的一个问题是,如何衡量一段代码是可读和可维护的?

经常能听见别人抱怨“祖传代码”多么烂,但是自己重写又能有质的改进吗?抱怨本身不能解决问题,如果仅仅是听浏览抱怨的层面上,却没有实质性的建议或改善,还是 shut up 吧。

最近接了一个的需求,需要新建一个广告创建流程,因为特别特别多的逻辑都放在 mixin 里,同时不了解以往逻辑,也不敢动任何代码,只是简单的把 mixin 引入,然后全靠断点往里面加 if-else 逻辑。整个过程一开始看起来就是一个黑盒,这种开发方式异常难受。

不过后来想明白了一件事情,没想到比 mixin 复用逻辑更好的方式,之前的”负面情绪“大多来自于对整个业务流程的不熟悉导致。唯一值得商榷的一点就是 mixin 职能的划分,合适的逻辑应该出现在合适的 mixin 里,避免乱入。

关于代码可读性,一般都会提到指定代码规范,比如各种 standard/recommend rule,可以通过一些工具手段去约束代码的风格,以及进行一些静态检查。但这还不够,还有一个设计问题

这里涉及到一个是否设计过度的问题,还是那句话,屁股决定脑袋,设计者很可能沉迷于自己的设计当中,乱套用模式也不一定是最优解,不能因为套用了一个模式就一定是最好的。

我在 Medium 看到一篇文章 What Is Readable Code?,作者提出了一个观点:可读性代码能够被安全地修改(Readable code should be easy to edit safely),并列举了三个例子用于判断:

  • 当同事希望添加新功能时,他们能很快找到并在正确的地方添加,同时不会因此引入 bug。
  • 当同事希望修复一个 bug 时,他们能很快定位 bug 源码位置并修复它,同时不会引入新的 bug。
  • 当同事希望验证一个边界条件时,他们能很快定位找到代码,并且能够跟踪逻辑来模拟他们所期望的行为。

这里有一个可读性代码的明显收益,就是很快定位代码位置并且测试代码并且不会引入额外 bug。在编码过程中如果能从这几个方面出发思考,造福自己的同时也是方便别人。

Table of Contents