2. 什么是诗一样优雅的好代码?

在学习如何写出诗一样优雅的好代码之前，我们首先要识别出来，什么的代码才是好代码。关于这个问题，不同的人有不同的解释，但是根据我阅读各种经典的代码优化书籍以及个人的开发经验来看，真正的好代码都有以下三个特点:

好代码的定义是什么?

1. 好代码是容易改变的代码

之前阅读的时候看到一句话令我印象深刻，“Software is soft, so it should be easy to change”。是啊，软件是软的，所以它应该天生就应该很容易被改变。

我们发明软件的初衷就是要灵活拥抱变化。其实IT行业最难的不是写代码，而是理解客户的需求，代码本身只是将客户需求转换成机器可以理解的语言，而我们程序员在其中承担的是翻译官的角色。理解需求本身是困难的，很难从最开始就完全清楚客户的需求，所以对于软件开发来说，需求的变更是很常见的事情。硬件设计从电路板印刷开始就是几乎无法修改的，任何变更都需要工厂重新生产，带来极高的成本，为了解决这个问题，所以我们发明了软件，便于我们后续可以灵活应对这种变更的需求，所以软件的本质就是要善于改变。

因此代码是否容易进行变更，是一个衡量代码好坏的重要评估标准。所以当你发现一个项目代码修改起来很困难的时候，就需要仔细审视下这个项目，看看它在设计上是否有不合理的地方，是否需要进行重构。

2. 好代码是容易阅读的代码

代码是给人看的，不是给机器看的，所以代码可读性很重要。机器阅读的是二进制字节码，编译器已经帮助我们解决了这个问题，只要代码能编译，机器就能读懂，这个我们完全不用操心，所以我们应该把重心转移到如何写出人类友好型代码。实际调查表明，我们写代码和后期维护代码的时间比例是1:10, 所以我们绝大部分时间都在阅读我们写的或者别人写的代码，所以通过写出更易读的代码，能够更显著地我们的总体效率，而不是把精力花在如何帮助我们更快写完代码上。

一些可读性差的代码可能有如下表现:

• 代码有大段注释

• • 情景: 当你发现代码中有大段的注释，需要我们阅读很多的文字才能理解时，那么这样的代码可能不是好代码。
  • 原因: 好的代码都是自解释的，不需要太多的冗余注释才解释清楚自己的实现逻辑，因为代码本身就是最好的注释。另外注释是很容易过期的，大家变更了代码不一定会记得变更注释，导致两者表达的信息不一致。
  • 建议： 当你需要写注释的时候，不妨看看能否通过合理的函数/变量命名来解决，比如说将注释的代码部分抽象成一个独立的函数，将注释变成函数名，这样子往往可以起到更好的解释作用。

• 代码需要别人解释才能读懂。

• • 情景: 当你接手了一个新项目的时候，往往同事会甩给你一堆代码项目地址，然后说"你去读吧，读懂了再来找我"，然后你会花费九牛二虎之力才能读懂这些"天书"，并中间遇到很多奇奇怪怪的代码逻辑必须找特定的同事解释才能理解。如果遇到这种情况，那么这样的代码可能不是好代码。
  • 原因: 同书面的代码注释一样，人的解释也是一种代码注释，而且是效果更差的一种注释方式。因为人可能遗忘，人可能犯错，人可能离职，如果必须依靠人才能理解，出错的概率会很高。
  • 建议: 与其让人解释，不如反思下是否代码设计有不合理之处，能否通过直接修改代码让别人第一次阅读就能看懂。这还能省却自己从尘封的记忆中挖掘出一个历史遗留问题，并花半天的时间给别人解释，让双方都痛苦，何必呢? 再不济，至少写一篇文档解释下之前这样子设计的原因，也能省却大部分麻烦，当然首推代码设计上的优化，而不是写连篇累牍的文档。

• 代码中有太多的“惊喜”

• • 情景: 这里面的“惊喜”是贬义，指的是那些违反直觉,让人觉得别扭不自然的代码设计。比如说你在接手一个新项目的时候，在深入了解项目的过程中发现很多违反你直觉的设计方案。
  • 解释: 大部分好的设计都是巧妙而自然的，让人一看就懂，而不好的设计才会让人觉得扭曲，违反直觉。这些反直觉的设计会让人产生错误的假设，一方面造成代码阅读的困扰，另外一方面也极大提高软件的维护成本。代码中的“惊喜”越多，往往意味着开发者需要更多文档来解释这些别扭设计存在的原因，有些项目甚至完全不解释，等着别人踩雷。
  • 建议: 一个好的项目应该是没有太多的“惊喜”的，因为它的一切设计都让你觉得顺其自然，让你觉得就是应该这样子设计。如果遇到一个项目里面有太多的“惊喜”，不然把这些项目的“惊喜”一个一个拿出来审视一下，看看能否换成更加自然，高效的解决方案。

• 代码阅读过程的体验不够愉快

• • 情景: 任何不愉快的代码阅读体验都可能昭示着代码质量问题的存在。比如说，你是否遇到过以下问题:

• • • 所有复杂的代码文件都塞到一个文件夹，一个文件夹就有几百个文件，几万行代码，让人光是看着就头大。
    • 某个函数有将近一千行代码，让人望而生畏，所有不同程度的细节都塞在一块儿，当你看完后半截代码，已经忘了前半截在做什么事情。
    • 当你为了排查一个bug而阅读代码的时候，你看着手头一大堆代码只能抓耳挠腮。你没有办法把问题缩小范围，因为多个模块之间有很强的耦合关系，牵一发而动全身，任何一处变更都可能造成其他模块发生不可知的影响。

• • 原因: 好的代码真的是让人阅读起来身心愉快的。当你去阅读一些优秀开源项目的代码的时候，虽然他很复杂，你并不会觉得非常晦涩难懂，反而觉得阅读起来很舒适自然，因为即使一个项目再复杂，但优秀的开发者会将不同的模块进行解耦合，当你阅读一个模块的代码的时候，不需要太过于考虑其他模块的影响，从而降低了代码阅读者的心智负担。
  • 建议: 当你阅读一个项目的代码，觉得很难懂，阅读体验很差的时候，不要光自责自己级别不够，看不懂大佬们的高深设计，反倒是可以质疑下，项目是否复杂的设计是否真的有必要，是否可以将模块进行拆分，从而降低整体维护的复杂度。同样的，当你作为一个项目的开发负责人的时候，也要力图让自己项目设计变得更加清晰简洁，真正厉害的人是可以让高深巧妙的设计也能变得非常浅显易懂，一目了然。

代码不是天书，代码是要给人维护的，所以难懂的代码不是好代码。代码的可读性也是一个软件项目能否成功很重要的指标。很多讲代码质量的书籍都有提到，代码可读性和代码质量应该是产品需求的一部分，代码质量差也应该作为一个bug处理，因为这样子的代码往往埋藏着很多复杂的逻辑和陷阱，一不小心就会爆雷。

3. 好代码是刚好够用的代码

什么是刚好够用的代码(Good-Enough Software)? 不同人有不同的理解，大家通常以为代码能跑能用就行，完全不去管软件质量。而这里的刚好够用指的是既能够满足产品的需求，同时能够将软件维护成本控制在相对较低的合理水平。

之所以这样说，是为了避免大家做过早优化。因为软件优化可以是无止境的，没有最完美的代码，只有最合适的代码。我们不是为了优化而做优化，而是为了提高长期维护的效率, 所以我们需要在代码优化投入的精力和实际产出的效果之间取得一个合理的平衡，也就是评估投入产出比(Return Of Interest)。就像是一家公司的CEO一样，他需要决定公司的资源投入到什么项目上，能够为公司产生最大的收益。我们也是自己软件项目的CEO，所以我们也有责任进行决策，我们的精力花在什么地方，才能够产生最好的效果。另外对于代码的过早优化，也会带来不必要的复杂度，甚至有可能拖慢我们的效率，所以代码优化本身需要适合而止。后面的章节也会给大家介绍如何在 代码优化 和 实际工作效率 之间 进行取舍的一些方法和技巧。

当然，就我个人经验而言，我发现大部分项目都是几乎完全不重视代码质量的，所以对于大多数人来说，多花费一些精力投入在优化代码质量本身是完全合理的。

为什么要写好的代码?

不要光听一个人怎么说，要看他是怎么做的。虽然所有人都说我们应该提升代码质量，但是很少有人这样子做。答案很简单，很多人真心觉得代码质量并不重要。并且因为国内这种赚快钱的创业氛围，很多人觉得代码写得快，远比代码写得好更有价值。

但是坏代码真的可以拖垮一家公司。很多体量比较小的公司，重视迭代速度，但是不重视代码质量。开始确实开发速度比较快，但后期随着功能复杂性提升，技术债务越积越高，导致迭代效率越来越慢，直到产品失败退出市场。而一般大公司在重视速度的同时，也会重视代码质量，这也是他们很多生产事故的血泪教训总结出来的宝贵经验，所以代码质量真的很重要。

我们写好的代码，因为这样子有好处，我们才去做。好的代码，真的能够提升研发的效率，就如同本文前部分所讲，写代码和维护代码的时间比例是 1:10，而做过性能优化的朋友肯定知道，系统整体性能需要首先从整个流程中时间占比最高环节进行优化，才能最大化提高整体的效率。对于软件开发来说，如果90%时间都在进行维护工作，我们没有理由不首先把这个环节作为效率优化的重点来看待，这才是真正提供研发效能的手段。所以那些整体喊着降本增效的老板们，不要整体追着自己的程序员让他们加快开发速度了，不妨多给他们一些时间去提升最基础的代码质量，这样子反而能起到更好的效果。

最后总结

这章节讲解了诗一样优雅的好代码的三个特点，便于我们在日常工作中准确识别什么才是好代码。同时解释了为什么我们要写好的代码，因为这样子确实能提升我们的研发效率，而不是为了优化而优化。接下来的一章节，我们就要学习如何写出诗一样优雅的好代码的技巧和方法了，不过在进入一些细节之前，我们首先讨论下，要写出好的代码，有哪些通用的原则，便于我们从宏观层面为代码质量把关。