实际上对于代码的好坏我们是无法客观的量化的，对一段代码的质量评价，常常有很强的主观性。
比如，怎么样的代码可读性才算好？每个人的评判标注都不太一样，这就好比我们去评价一本小说写的精彩不精彩，本事就是一个很难量化、非常主观的一件事情，所以这篇文章全是胡扯。
以下是描述代码质量高低经常会用到的词汇
灵活性（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）、好（good）、坏（bad）……
下面我会挑几个常用的，重点的简单描述
- 可维护性（maintainability）
落实到编码开发，所谓的“维护”无非就是修改bug、修改老的代码、添加新的代码之类的工作。
所谓“代码易维护”就是指在不破坏原有代码设计、不引入新的bug的情况下能够快速的修改或添加代码。
所谓“代码不易维护”就是指修改或添加代码需要冒极大的引入新bug的风险或者花费很长时间才能完成。
我们知道对于一个项目来说维护时间远远大于开发时间。工程师的大部分时间可能都在花在修改bug，修改老的逻辑或功能，添加新的逻辑或功能一直的工作上，所以代码的可维护性显得格外重要。
维护、易维护、不易维护这三个概念理解不难。不过对于实际开发来讲，更重要的是要搞清楚如何判断代码可维护性的好坏。 - 可读性（readability）
软件设计大师Martin Fowler曾经说过："Any fool can write code that a computer can understand.Good programmer write code that humans can understand." “任何傻瓜都会编写计算机可以理解的代码。好的程序员能够编写人类可以理解的代码。”
我们在编写代码的同时要时刻考虑代码是否易读、易理解。代码的可读性会在很大程度上影响代码的可维护性。毕竟，不管是修改bug、修改或新增功能我们首先要做的就是读懂代码，代码读不懂，就很有可能会考虑不周，从而引入新的bug。
如何评判代码的可读性呢？
我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短适合、模块划分是否清晰、是否符合高内聚低耦合等等。
实际上我们很难给出一个覆盖所有评判指标的列表，这也是我们无法量化可读性的原因。
code review是一个很好的测试手段，如果你的同事可以轻松读懂你的代码，那说明你的代码可读性很好；如果同事在读你的代码时提出很多疑问，那就说明你的代码可读性有待提高了。 - 可扩展性（extensibility）
代码的可扩展性标识，我们在不修改或少量修改的情况下，通过扩展的方式来添加新的功能代码。说直白点就是预留了一些功能扩展点，你可以把新的功能代码直接插到功能扩展点上，而不需要为了添加一个功能大动干戈，改动大量原始代码。 - 灵活性（flexibility）
如果一段代码易扩展、易复用或易用，我们都可以称这段代码写的比较灵活。灵活这个词意义广泛，很多情况下都可使用。 - 简洁性（simplicity）
KISS原则："Keep It Simple,Stupid." “保持简单，笨蛋。”
代码简单，逻辑清晰。同时也以为着易读，易维护。 - 可复用性（reusability）
计量减少重复的代码，复用已有的代码。
本文由 kaishin 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Mar 20, 2020 at 10:54 am