当人们在说好代码的时候，是在说什么？什么是好代码？

作为一位技术人，相信很多人立志要写出好代码来，希望自己写出来的代码为后来者称道。

在工作中，常常会听到一些人吐槽前任遗留下的代码，代码逻辑差，可读性不高，简直如“屎山一样”，所谓写代码易，改代码难。

对于什么是“好代码”？很多人难以表述清楚，看到一段写的好的代码，搬到自己的程序里，却显得那么突兀。

一些人明白什么是好代码，却因为工作节奏快，时间短，没时间去设计。

也有人说功能实现，安全上线即是烧高香了，哪里还有精力去写“好代码”呢？

这里，就出现几个问题：什么是好代码？好代码意味着什么？如何才能写出好代码？

如果觉得本文对您有帮助，麻烦转发给朋友，好东西，要分享！

什么是好代码

本节我们从代码的内外两个方面分析什么是好代码。不足之处，还望海涵，如果您有高见，不妨移步评论区讨论。

外部特性

好代码应该具备满足需求、避免BUG、易理解、易复用、易迭代的特征。

满足需求是代码的第一要义，如果不能满足需求，代码便没有任何意义。但是写出满足需求的代码却并不是一件简单的事情。这是因为软件本身解决问题的复杂性和人类沟通的复杂性导致的。因此要从结构化探索、高效沟通、强调设计目标和演进化设计等方面理解需求。

避免BUG而不是消除BUG，BUG总是不可避免的，但这不意味着不能降低BUG带来的损失。对待BUG要采取正确的态度：专业严谨。在编写代码的时候，要将写出高质量代码为第一优先级。审慎对待自己的代码。

BUG不可怕，可怕的是不能尽早发现BUG。要建立反馈机制快速发现代码：如系统测试、自动化测试等机制尽早发现BUG，并及时修复。BUG发现越早，修复的成本越低，影响面越小，BUG发现越晚，定位越困难，影响面越宽，修复成本越高。

Harold Abelson（《计算机程序的构造和解释》作者）说过计算机程序首先是用来给人读的，只是顺便用于机器执行。由于代码的天性（代码天然充斥着各种细节），写出易于理解的代码并不是一件易事，写出让他人易于理解的代码更非易事。高质量的代码一定是注重隐藏细节的。

降低代码的复杂性是提升代码易理解的关键。而降低代码的复杂性离不开良好的命名、一致的业务概念、更好的设计结构、减少重复和测试描述等等。

复用是人类文明发展的重要推动力。在一些框架级层面上已经实现了复用，比如Spring、Kubernetes等。但是对于业务代码来说，很难复用。可是不得不承认，设计的不合理、过度的依赖也是阻碍复用的关键。要提高代码的复用，应该从选择合适的复用粒度、清晰的设计职责方面考虑。

需求并不是一成不变的，因此好的代码要易于修改。不良的代码设计，经过多次修改之后就变的一团乱麻。这就是所说的代码腐化。良好的设计、自动化测试和简单之上的设计理念是实现代码易迭代的关键。

内部特性

代码除了要满足外部特性的同时，还需要具备统一的编码风格、有意义的命名、保持简单、不要重复、高内聚低耦合、没有多余设计、具备自动化测试等特性。

统一的编码风格可以说是代码的基础要求，没有人希望这段代码是一种布局，另一段代码又是一种布局。而且，软件开发都是以团队开发为单位的，不同的编码风格也导致了对其可理解性、可维护性产生很大的负担。

应该从编码规范来约束代码风格。编程风格文档化是基础要求，如阿里发布的Java编程规范，不仅在公司内部具有很重要的影响，也影响了很多中小公司。编程规范并不是一成不变的，随着时间的推移，也积累的新的经验和教训，需要同步更新。

通过代码评审统一编程风格，同时，也可以使用相关插件实现编程风格的统一，一些工具Alibaba Java Coding Guidelines、CheckStyle、SonarLint也能减少代码评审的工作量，提高代码评审的效率。

有意义的命名能反应领域模型的概念，像一段充斥着i，j，k的代码除非完整的将代码读下来，不然很难理解其功能，甚至读下来也不一定能理解。什么是好的命名，好的命名一定是反应了业务的概念。比如一个名为PascalTriangle的结构体，很容易就能明白肯定是杨辉三角形的相关功能和实现。

命名要从业务视角而不是开发视角，比如consumer的结构体有两个方法setAddress和changeAddress，前者是开发视角，后者是业务视角，

保持简单不仅能使的代码易于理解，更易于迭代。这要求代码元素要短、表达要清晰和抽象在同一层面上、方法的复杂度要低。简短是认知层面的简单，而不是一味追求代码的简短。

没有人喜欢看长代码，如果一个方法，一屏还没显示完，通常意味着太长了，这也是一个设计不良的信号。在编写代码的时候，要做到代码的抽象，

高内聚、低耦合是提升代码可读性、可迭代、易复用的关键。**高内聚是模块化的最高指导原则，低耦合是模块间协作的最高指导原则。**高内聚要求将紧密相关的东西放在一起，低耦合要求我们管理好依赖。

重复是一种特殊的耦合，相信没人喜欢重复代码。重复的代码增加了理解的心智负担和围堵难度。造成重复的原因各种各样，如时间紧张，将一段功能类似的代码拷贝过来，修改少部分代码。重复代码包含完全重复的代码、模式重复的代码、功能相同但实现不同的代码。这需要关注设计点分离。

少即是多，代码并不是越多越好。代码是有维护成本和理解成本的。多余的代码通常是刻板遵循设计模式、为未来预留扩展、曾有用后来没用舍不得删除。

设计模式或者设计规范本身是为了解决某种问题的，需要考虑投资回报。如果发现回报不合理，就要删除或者更换设计模式。没用的代码就删除了吧，也不要舍不得或者注释掉，如果这些代码将来用到了，一些版本管理工具，如git能很快的找回。代码应该具备可扩展性。但这指导我们要写出适应性高的代码，而不是预留扩展。

现在对于自动化测试要求越来越高。自动化测试能够保障功能正确，其次，通过测试代码可以很快了解代码实现的功能，如笔者，就喜欢从测试代码看起。良好的测试代码是最好的文档。

理解了什么是好代码，并不意味着就能立马写出好的代码。在实际工作中，要有好代码的意识，并养成良好的编程习惯。罗马不是一天建成的，同样，好的代码也不是一天就能写出来的，这需要持之以恒的坚持下去。

碍于时间和精力，本文对好代码特性并没有展开讲述，这些特性名字本身并不难理解。如果给您带来困惑，笔者感到惶恐，笔者后续会展开描述，欢迎关注及时获得后续文章。

如果觉得本文有用，欢迎分享给他人，传递知识，我们一直在路上。