代码质量评价的两个维度：抽象定义为何缺乏操作性

Bjarne Stroustrup、Grady Booch、Michael Feathers这些业界公认的权威人物，都给出过关于”什么是好代码”的定义（逻辑清晰/依赖最少/整洁简单/像写得很好的散文/没有明显需要改善的地方），这些描述听起来都很有道理，但真正拿来评判具体代码时却很难操作——尤其对新人而言，”简单、直接的代码”或者”没有明显需要改善的地方”这类描述本身就需要判断力才能理解，而这恰恰是新人还不具备的能力，这就构成了一个循环困境。这个困境背后有一层更本质的原因：代码质量的评价在某种意义上类似文学作品的评价——一部小说的质量高低，最终来自读者的主观感受汇聚成的相对客观评价，而不是依靠字数或者使用了哪些修辞手法这类看似客观、实际没有太大意义的量化指标。但代码和小说有一个关键的不同：代码实际存在两个”读者”——计算机和程序员，即使所有程序员都看不懂一段代码，它依然可以被计算机正确理解并执行。这意味着评价代码质量必须同时从两个维度分析：主观的、被人类理解的部分（可读性、可维护性），以及客观的、代码在计算机里实际运行的状况（性能、正确性、健壮性）。正因为存在主观部分，同一段代码对不同水平的评价者会得出不同结论，这也是很多新人面对的核心困境：他们没有一个可以执行、可以对照的具体评价标准，写出来的代码质量因此很难真正提高——仅仅告诉新人”要写简单优雅的代码”这类原则性建议，对实际提升代码质量的指导作用非常有限，真正有用的是把这些抽象原则转化成一系列具体、可操作的检验动作。