实际上对于代码的好坏我们是无法客观的量化的,对一段代码的质量评价,常常有很强的主观性。
比如,怎么样的代码可读性才算好?每个人的评判标注都不太一样,这就好比我们去评价一本小说写的精彩不精彩,本事就是一个很难量化、非常主观的一件事情,所以这篇文章全是胡扯。
以下是描述代码质量高低经常会用到的词汇
灵活性(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