塑造高质量代码

• 可读性
• 可维护性
• 可变更性

• 良好的命名
• 良好的代码风格
• 良好的软件设计

首先我们认识一下，整洁的代码 和 高质量代码 是有着密切的关系，也可以说是，想写出高质量代码，代码就需要整洁性，可读性。下面给大家介绍一些编写代码的基本原则和规范。

命名

有意义的命名

1. 变量名，常量名——名词或名词短语，比如 变量名 d 就没有 remainingTimeInDay 命名具体，更有含义。
2. 函数名，方法名——动词或者动词短语，(一般首个单词为动词)，另外命名要具体，空泛的命名没有意义。(processData()就不是一个好的命名)，函数的命名要体现做什么，而不是怎么做，比如：validateUserCredentials()。
3. 类名——名词或名词短语

命名保持一致性

1. 使用对仗词，如下例子。
2. 后置限定词（举例：Total、Sum、Average、Max、Min......)
3. 统一业务语言（使用命名空间）

对仗词举例

first/last
min/max
add/remove
increment/decrement
open/close
begin/end
insert/delete
show/hide
create/destroy
lock/unlock
source/target

推荐的命名工具

规范

命名规范

注释规范

好注释

1. 提供代码背后的意图和目的，帮助阐释代码的含义
2. 用于警告其他程序员会出现某种后果的注释
3. TODO注释，由于某些原因目前还没做的工作

坏注释

1. 过时的注释不要有，会误导后人
2. 不需要给字面含义明确的代码，添加注释。

规范补充

1. 合理使用中间变量，增加可读性
2. 使用设计模式语言，比如vue中的观察者模式和发布订阅模式Observer，subscribe
3. 一个简单的原则就是将概念相关的代码放在一起：相关性越强，彼此之间的距离应该越短。正确地使用空行，可以增加代码可读性。
4. 使用常量替代魔术数字
5. 防止破窗效应 —— 犯罪心理学中一个著名的理论。不要第一个写出“坏味道”的代码

合理使用中间变量

正确使用空行，增加代码可读性

正确使用常量

函数

函数参数

1. 最理想的参数数量是零（零参数函数），其次是一（单参数函数），再次是二（双参数函数），应尽量避免三（三参数函数）。有足够特殊的理由才能用三个以上参数（多参数函数）
2. 如果函数看来需要两个、三个或三个以上参数，可以使用对象代替

函数原则

SOLID原则

• Single Responsibility Principle（SRP）：单一职责原则。
• Open Close Principle（OCP）：开闭原则。
• Liskov Substitution Principle（LSP）：里氏替换原则。
• Interface Segregation Principle（ISP）：接口隔离原则。
• Dependency Inversion Principle（DIP）：依赖倒置原则。

单一职责原则(SRP)

SRP要求每个软件模块职责要单一，衡量标准是模块是否只有一个被修改的原因。职责越单一，被修改的原因就越少，模块的内聚性（Cohesion）就越高，被复用的可能性就越大，也更容易被理解。

开闭原则(OCP)

软件实体应该对扩展开放，对修改关闭。我们可以不改变现有功能，而是以扩展的方式实现新需求。

在面向对象设计中，我们通常通过继承和多态来实现OCP，即封装不变部分。对于需要变化的部分，通过接口继承实现的方式来实现“开放”。

实际上，很多的设计模式都以达到OCP目标为目的。例如，装饰者模式，可以在不改变被装饰对象的情况下，通过包装（Wrap）一个新类来扩展功能；策略模式，通过制定一个策略接口，让不同的策略实现成为可能；适配器模式，在不改变原有类的基础上，让其适配（Adapt）新的功能；观察者模式，可以灵活地添加或删除观察者（Listener）来扩展系统的功能。

里氏替换原则(LSP)

程序中的父类型都应该可以正确地被子类型替换。

在父子类中，子类可以覆盖父类的函数

接口隔离原则(ISP)

多个特定客户端接口要好于一个宽泛用途的接口。接口隔离原则认为不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口要好。

满足单一职责原则，让一个接口的职责尽量单一

依赖倒置原则(DIP)

模块之间交互应该依赖抽象，而非实现。DIP要求高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象。

依赖倒置，让原来紧耦合的依赖关系得以解耦，这样依赖方和被依赖方都有更高的灵活度。（两个模块之间，依赖另个模块的某个接口，不用了解它内部的实现）

DRY

DRY是Don’t Repeat Yourself的缩写，DRY原则特指在程序设计和计算中避免重复代码，降低代码的灵活性和简洁性。

许多原则与实践规则都是为控制与消除重复而创建。

三次原则(Rule of Three)

“三次原则”，是指当某个功能第三次出现时，就有必要进行“抽象化”了。

KISS原则

KISS（Keep It Simple and Stupid），思想类似于SRP。 真正的简单，不是不思考，而是先发散、再收敛。在纷繁复杂中，合理拆分成简单的子问题。

抽象层次一致性(SLAP)

函数中的语句满足抽象层次一致性（Single Level of Abstration Principle，SLAP），不同抽象层次的内容放在一起会给人凌乱、逻辑不协调的感觉。

函数使用总结

1. 封装一件事。
2. 封装判断，在多个条件判断的情况下
3. 出现两次、三次及三次以上就需要提取函数。
4. 使用组合函数模式。当函数过大过长是典型的代码“坏味道”，意味着这个函数可能承载着过多的职责，我们有必要“分治”一下，将大函数分解成多个短小、易读、易维护的小函数。
5. 分离功能代码和业务代码。千万不要在业务处理内部到处使用try/catch打印错误日志，这样会使功能代码和业务代码缠绕在一起，让代码显得很凌乱，并且影响代码的可读性。函数应该只做一件事，错误处理也应当是一件事。

我们提炼的函数尽量是纯函数，无副作用，不被外在因素随意修改。在函数式编程中，高阶函数起到了主宰的地位，可以带来很多灵活性，便利性。

纯函数

对给定的输入参数，返回相同的输出值。

高阶函数

输入参数是函数，并且/或者，输出值是函数

提高代码质量

1. 遵循规范和原则
2. 二次重构优化
3. 以测试驱动开发

优雅的代码很少是一次成形的，大部分情况下要经过两次创造，第一遍实现功能，第二遍重构优化。优化工作本应该是我们编码工作的一部分，拆成两步，主要对编码效率上的考量。

最后希望我们都能具备工匠精神，写出高质量的代码

参考

相关书籍

1. 代码精进之路
2. Clean Code. 代码整洁之道
3. 重构 改善既有代码的设计