一. 如何评价代码质量的高低

代码高低的评价需要从多个维度去分析, 最常用的评价标准如下:

可维护性
可读性
可扩展性
灵活性
简洁性
可复用性
可测试性

1.1 可维护性(maintainability)

首先我们得了解什么叫维护, 什么代码具备可维护性?

维护说白了就是修bug, 在老功能上改一改, 添加一些新功能等, 那么可维护就很好理解了, 它其实就是在我们修复bug, 修改老功能, 添加新功能的时候能够轻松的完成, 我们就可以主观的认为这段代码易维护, 可维护性好.

虽说上面有很强的个人主观性, 但是我们需要明白: 代码质量的评价本来就有很强的主观性.

1.2 可读性(readability)

软件设计大师Martin Fowler说过: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand", 翻译过来就是:任何傻瓜都会编写计算机能理解的代码, 好的程序员能够编写人能够理解的代码.

总结: 代码是写给人看的, 不是写给计算机看的.

其实代码的可读性会很大程度影响代码的可维护性, 因为不管在修bug, 修改or添加功能, 我们首先肯定得需要读懂代码, 才能去维护代码. 如果代码都读不懂, 何谈去维护代码.

可读性说白了就是看看代码是否符合编码规范, 命名是否达意, 注释是否详尽, 函数是否长短合适, 模块划分是否清晰, 是否符合高内聚低耦合等.

如果你的同事能够很轻松的读懂你的代码, 说明你的代码可读性很好.

1.3 可扩展性(extensibility)

扩展性说白了就是我们的代码是否足以应对未来需求升级变化的能力.跟可读性一样, 代码的扩展性高低也决定了代码是否易维护.

面向对象设计中有一个非常重要的原则, 叫做:OCP原则(Open-Closed Principle). 翻译过来就是:对修改关闭, 对扩展开放

1.4 灵活性(flexibility)

代码的灵活性有如下几点:

当我们新增新的功能代码时, 原有的代码已经预留了扩展点, 比如只需要加响应的策略即可, 也不侵入原有的代码, 只是在新生成的策略上写对应的逻辑即可, 那么我们可以说代码易扩展, 代码好灵活.
当我们实现功能的时候, 发现原有的代码已经抽象出了好多易复用的模块, 类, 方法, 这时候我们也可以说代码写的很灵活.
当我们写的接口可以应对各种使用场景, 满足不同的需求, 我们可以说接口易用之外, 也可以说代码写的很灵活

总结: 如果一段代码易扩展, 易复用, 易用, 那么我们就可以称这段代码灵活性好.

1.5 简洁性(simplicity)

KISS原则(Keep It Simple Stupid)是非常著名的设计原则, 翻译就来就是:保持简单.真正的高手可以云淡风轻地用最简单的方法解决最复杂的问题.

1.6 可复用性(reusability)

复用性说白了就是减少重复代码编写, 复用已有的代码.

比如:

面向对象特性中的继承, 多态存在的目的之一, 就是为了提高代码的可复用性;
设计原则的单一职责原则也是跟代码复用性相关;
当讲到重构技巧时, 解耦, 高内聚, 模块化都能提高代码的复用性;

代码的可复用性跟DRY(Dont Repeat Yourself)设计原则关系紧密, 翻译过来就是:不要重复自己, 说白了就是不要写重复的代码, 写可复用的代码.

1.7 可测试性(testability)

代码可测试性的好坏, 能侧面的反映出代码质量的好坏.代码质量差, 比较难写单元测试, 那基本上就说明代码设计的有问题.

二. 如何才能写出高质量的代码

(1)需写出:易维护, 易读, 易扩展, 灵活, 简洁, 可复用, 可测试的代码

(2)需掌握一些更加细化, 更加能落地的编程方法论, 主要包含了:面向对象设计思想, 设计原则, 设计模式, 编码规范, 重构技巧等.

三. 聊一聊你心目中的好代码是什么样子

总结专栏评论中高质量回答:

当你读我的代码时, 我已经离职了, 但你依然能够清楚的明白我要传递的信息;
当程序出错时, 一方面汇报的错误信息能够帮你找出错误在哪; 另一方面, 能准确的告诉你错在哪了;
当你需要造轮子的时候, 我的代码能够作为现成的轮毂, 你只需要组装一下即可;

设计模式之美-学习导读(2)