一 背景
代码质量是每一个从事软件开发的人员都不得不重视的一件事情，那么代码质量如何评判？什么样的代码才算是质量高的？怎样提高代码质量？每个人都会有不同的见解和开发，但经常说的都比较笼统不够清晰。
对于开发人员来说，能够清晰的辨别出代码质量，说清楚代码好的原因，烂的原因，是一个非常重要的能力。这也是我们写出好代码的前提。毕竟，如果我们连什么是好代码、什么是烂代码，都分辨不清，又谈何写出好代码呢？
然而评判代码质量的维度太多，每个人看法都不一致，那么我们能否可以抽取出一些共性的评判标准，用来评判代码质量呢？
二 评判维度
目前我们常用的用来评判代码质量的维度比较多，以下常听到的代码质量评判维度：
灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可读性（readability）、可理解性（understandability）、易修改性（changeability）、可复用（reusability）、可测试性（testability）、模块化（modularity）、高内聚低耦合（high cohesion loose coupling）、
高效（high effciency）、高性能（high performance）、安全性（security）、兼容性（compatibility）、易用性（usability）、整洁（clean）、清晰（clarity）、简单（simple）、直接（straightforward）、少即是多（less code is more）、文档详尽（well-documented）、分层清晰（well-layered）、正确性（correctness、bug free）、健壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性（scalability）、稳定性（stability）、优雅（elegant）等等。
但实际中我们并不需要用到这么多维度去评价代码，而且有不少维度也都是相互交叉的，下面我针对代码层面的一些判断标准，抽取其中一些比较常用有代表性的维度来做下介绍：
2.1 可读性（readability）
Martin Fowler 曾经说过：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
翻译成中文就是：“任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。”
我认为代码可读性是评判代码质量的第一标准也是最重要的标准，如果你的代码写的可读性极差，难以理解，那还有继续评判下去的必要吗？可读性极差的代码，也一定是难以维护的。
一般考察代码的可读性，我们需要看代码是否符合公司编码规范、命名是否达意、代码复杂度是否过高，注释是否详尽、方法或类是否过长、类和模块的划分是否清晰等等。
这里需要强调下，可读性的代码是包含注释在内的代码，如果有的代码逻辑的确是过于复杂，或者使用了比较复杂的算法，但加上了比较清晰的注释进行说明，那么整体代码的可读性其实并不差。
日常开发中，校验代码可读性一个很好的方法就是找同事看下你的代码，是否能够理解，或者你过一段时间再看下你的代码，你是否还能清晰理解。如果都不能理解，那可读性肯定是比较差的。
2.2 健壮性（robustness）
健壮性一般是指系统在规范要求以外的输入情况的处理能力，这里引申一下，其实鲁棒性就是健壮性，健壮性英文是robustness，直接音译就是鲁棒性。健壮性也是代码质量的一个非常重要标准，一个系统代码即使写的非常优雅，但是遇到一些非规范以外的输入就直接挂掉了，那这
个系统的代码质量也是极差的。
健壮性的评判标准比较简单，一般就是测试下规范意外的输入情况处理能力，但实际开发中还需要考虑其他各种异常情况，比如网络异常，依赖的接口异常，数据库挂掉，有脏数据等等各种异常，代码开发中都需要做好对应的处理。
健壮性和可靠性并不完全相同，健壮性更多的是指代码层面对各异常的处理能力，可靠性不仅包含代码层面的异常处理能力，还包括网络层面，服务器层面等等非代码维度的可靠性。
2.3 可维护性（maintainability）
代码维护一般就是需要修改原有代码或在原代码基础上添加新的逻辑。易维护的代码，可以在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。相反不易维护的代码，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间
才能完成。
所以判断一个代码可维护性的一个方法就是看在原代码基础上修改或者添加功能，是否可以容易修改且改动风险很低， 如果可以做到，那就说明这部分代码的可维护性就比较高，相反则这部分代码可维护性就比较低。
2.4 可复用性（reusability）
可复用就是尽量减少重复代码的编写，复用已有的代码。可复用性也是一个非常重要的代码评价标准，是很多设计原则、思想、模式等所要达到的最终效果。
日常开发时就需要考虑到现有代码，未来是否可以提供给其他业务使用，如果想做到可复用，那么代码就需要减少代码耦合，满足单一职责，尽量做到通用代码下沉等方式。如果代码职责不清晰，耦合严重，那可复用性肯定是极差的。可复用性差的代码，会带来很多重复代码，
增加开发成本。
但这里也需要注意一点，如果当下没有复用的需求，并且开发可复用代码的成本比较高，那我们就不需要为了复用而复用。可以在之后开发新的功能的时候，发现可以复用之前写的这段代码，那我们就重构这段代码，让其变得更加可复用。
2.5 可扩展性（extensibility）
可扩展性，是指我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。这就要求代码需要预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上，而不需要因为要添加一个功能而大动干戈，改动大量的原始代码。尽量把代码改动量和风险降
到最低。
可扩展性和可维护性有些相同，不过可扩展性更多的是强调在原代码基础上添加新的功能的能力。扩展性好的代码，往往更容易添加新的功能，方便业务快速开发。
2.6 简单（simple）
简单，就是保持代码简单，其中有个KISS 原则：“Keep It Simple，Stupid”。这个原则就是，尽量保持代码简单。代码简单、逻辑清晰，那可读性和可维护性就会比较高。我们在编写代码的时候，也应该把简单、清晰放到首位。
这里需要注意，简单并不是简洁，我认为这两个不是一个概念，比如说如果代码中直接使用位运算会非常简洁，但这却不简单，会增加代码的复杂度和理解难度。另外引入新技术时也需要慎重，最好使用同事都比较了解的技术，如果需要引入同事不清楚的技术，最好提前做好一些
介绍或者培训工作，不然也会导致代码变得不简单，增加理解难度和维护成本。
思从深而行从简，代码想要保持简单并不是一件容易的事情，复杂的业务逻辑，能够以比较简单的代码写出来，也是需要很多的思考和较强的代码功底。
2.7 可测试性（testability）
代码可测试性是指编写单元测试的难易程度，代码如果可测试性好，也就很容易编写相应的单元测试来保证代码质量，相反代码的可测试性差，比较难写单元测试，难以做到完善的自测，自然无法较为准确的保证代码质量。
三 怎么提高代码质量？
提高代码质量的方式有很多，每个人都有些自己的心得 ，我认为最基本的方法有以下这些：
3.1 代码规范
提升部门代码质量最基础也是最重要的一步就是制定代码规范，这里的规范主要有以下两方面主要作用：
一方面主要作用是部门内部统一代码风格，不然代码中各种风格，看着就很乱了，也增加理解难度。
另一方面主要的作用是保证代码质量的底线，规范中会加入很多代码编写时的一些严格限制和建议，比如类和方法如何命名，类或方法代码行数不可超过多少，不可大量嵌套条件表达式等等。无论代码水平如何，坚持按照规范去开发，至少可以保证代码质量的不会太差。
另外代码规范制定好之后，并不能直接带来明显的效果，关键是要落实，需要有人去监督审查，确保大家的代码都是按照规范去编写，不然执行不严，落实不下去，规范也带来不了多大作用。
3.2 代码设计
规范有了之后，也只能做到代码质量的兜底，如果想提高代码质量，还是需要普及些基本的代码设计知识 ，比如常用的设计原则及设计模式，重构技巧，领域驱动设计设计等等。了解代码应该怎么设计，针对些需要进行设计的代码做些基本的设计，才可以进一步
保证代码质量的提高。
3.3 代码review
代码编写完以后，至少需要经过其他至少一个同事的代码review，这点很重要，一般当局者迷，旁观者清，换一个人往往会有不同的思路，能够发现代码中的自己容易忽略问题，如果review的同事经验比较丰富，代码设计和规范比较了解，那带来的帮助会更大。
而且我认为review必须要细，细到每一行，每个变量名称，这样双方才能都得到成长。但这样会带来工作量的提升，所以如何平衡也是需要值得考虑的事情。
3.4 持续重构
任何代码经过不断地改变也都会慢慢腐烂掉，所以想要一直保持高质量的代码，必须要坚持不断地进行重构，从而使代码质量一直保持在较高水平。这点其实也很重要，但重构的成本往往也不小，小重构代价会相对较小，但经常会有很多代码小重构已经不能解决
问题，但大重构又会带来很多风险，所以这也是一个需要把握平衡的事情。
3.5 自我要求
其实想要提高代码质量，最重要的是自己要有高标准的要求，其他的都是次要的，对自己有了高标准要求，自然会学习各种知识，在日常开发中去提高代码质量。
四 总结
本文介绍了代码质量评判的一些常见方式，最后简单介绍了一些提高代码质量的方法，简要说明了下思路，并未深入写，但其实每一个都可以总结出几篇文章。
代码质量是一个永久的话题，也是经常会被提到的话题，但工作中常常需要在代码质量和工作进度之间做取舍，我认为过度注重工作进度而放弃了代码质量是难以长久的，长久之道还是需要争取到额外的时间去更好的设计代码或者不断的进行重构来提高代码质量。
