如何评判代码的好与坏?

in Design Pattern with 0 comment

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

  1. 可维护性(maintainability)
    落实到编码开发,所谓的“维护”无非就是修改bug、修改老的代码、添加新的代码之类的工作。
    所谓“代码易维护”就是指在不破坏原有代码设计、不引入新的bug的情况下能够快速的修改或添加代码。
    所谓“代码不易维护”就是指修改或添加代码需要冒极大的引入新bug的风险或者花费很长时间才能完成。
    我们知道对于一个项目来说维护时间远远大于开发时间。工程师的大部分时间可能都在花在修改bug,修改老的逻辑或功能,添加新的逻辑或功能一直的工作上,所以代码的可维护性显得格外重要。
    维护、易维护、不易维护这三个概念理解不难。不过对于实际开发来讲,更重要的是要搞清楚如何判断代码可维护性的好坏。
  2. 可读性(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是一个很好的测试手段,如果你的同事可以轻松读懂你的代码,那说明你的代码可读性很好;如果同事在读你的代码时提出很多疑问,那就说明你的代码可读性有待提高了。
  3. 可扩展性(extensibility)
    代码的可扩展性标识,我们在不修改或少量修改的情况下,通过扩展的方式来添加新的功能代码。说直白点就是预留了一些功能扩展点,你可以把新的功能代码直接插到功能扩展点上,而不需要为了添加一个功能大动干戈,改动大量原始代码。
  4. 灵活性(flexibility)
    如果一段代码易扩展、易复用或易用,我们都可以称这段代码写的比较灵活。灵活这个词意义广泛,很多情况下都可使用。
  5. 简洁性(simplicity)
    KISS原则:"Keep It Simple,Stupid." “保持简单,笨蛋。”
    代码简单,逻辑清晰。同时也以为着易读,易维护。
  6. 可复用性(reusability)
    计量减少重复的代码,复用已有的代码。
Responses