概述

美国童子军有一条简略的军规：让营地比你来时更洁净。当梳理代码时，坚守此军规：每次 review 代码，让代码比你发现它时更整齐。

一位大神说过：“衡量代码质量的仅有有效规范：WTF/min”，并配了一个形象的图：

经过他人在 review 代码进程中，每分钟 “爆粗” 的次数来衡量这个代码好的程度。

代码整齐的必要性

好的代码便是为了更夸姣的日子！ Clean Code == Good Code == Good Life！

为了把自己和他人从 糟糕的代码保护工作 中摆脱出来，必由之路 便是 整齐的代码。于个人来说，代码是否整齐影响心情；于公司来说，代码是否整齐，影响经营生存（因为代码写的烂而倒闭的公司还少吗？）。

一念天堂，一念地狱。

坏滋味的代码

开端阅览之前，咱们能够快速考虑一下，咱们脑海里的 好代码 和 坏代码 都是怎么样的“形容”呢？

假如看到这一段代码，如何点评呢？

if (a && d || b && c && !d || (!a || !b) && c) {
    doSomething() 
} else {
    doSomethingElse()
}

上面这段代码，虽然是特意为举例而写的，要是实在遇到这种代码，想必咱们都 “一言难尽” 吧！咱们多多少少都有一些 坏滋味的代码 的 “印象”，坏滋味的代码总有一些共性：

那坏滋味的代码是怎样形成的呢？

• 上一个写这段代码的程序员经验、水平缺乏，或写代码时不行用心；
• 事务方提出的奇葩需求导致写了很多 hack 代码；
• 某一个模块事务太杂乱，需求改动的次数太多，经手的程序员太多。

当代码的坏滋味现已 “弥漫” 处处都是了，这时咱们应该了解一下 重构。接下来，经过了解 圈杂乱度 去衡量咱们写的代码。

圈杂乱度

圈杂乱度 能够用来衡量一个模块 断定结构 的 杂乱程度，数量上体现为 独立现行途径条数，也可了解为掩盖 一切履行途径 运用的 最少测试用例数。

圈杂乱度（Cyclomatic complexity，简写CC）也称为 条件杂乱度，是一种 代码杂乱度 的 衡量规范。由托马斯J麦凯布（Thomas J. McCabe, Sr.）于1976年提出，用来表明程序的杂乱度。

1. 断定办法

圈杂乱度能够经进程序操控流图核算，公式为：

V(G) = e + 2 – n

• e : 操控流图中边的数量
• n : 操控流图中节点的数量

有一个简略的核算办法：圈杂乱度 实际上便是等于 断定节点的数量 再加上 1。

2. 衡量规范

代码杂乱度低，代码不必定好，但代码杂乱度高，代码必定欠好。

圈杂乱度	代码状况	可测性	保护本钱
1 – 10	清晰、结构化	高	低
10 – 20	杂乱	中	中
20 – 30	十分杂乱	低	高
>30	不行读	不行测	十分高

3. 下降代码的圈杂乱度

3.1. 笼统装备

经过 笼统装备 将杂乱的逻辑判别进行简化。

• 优化前

if (type === '扫描') {
    scan(args) 
} else if (type === '删去') { 
    delete(args) 
} else if (type === '设置') { 
    set(args) 
} else { 
    other(args)
}

• 优化后

const ACTION_TYPE = {
    '扫描': scan, 
    '删去': delete,' 
    '设置': set 
} 
ACTION_TYPE[type](args)

3.2. 办法拆分

将代码中的逻辑 拆分 成独自的办法，有利于下降代码杂乱度和下降保护本钱。当一个函数的代码很长，读起来很费力的时分，就应该考虑能否提炼成 多个函数。

• 优化前

function example(val) {
    if (val > MAX_VAL) {
        val = MAX_VAL
    }
    for (let i = 0; i < val; i++) {
        doSomething(i)
    }
}

• 优化后

function setMaxVal(val) {
    return val > MAX_VAL ? MAX_VAL : val
}
function getCircleArea(val) {
    for (let i = 0; i < val; i++) {
        doSomething(i)
    }
}
function example(val) {
    return getCircleArea(setMaxVal(val))
}

3.3. 简略条件分支优先处理

关于杂乱的条件判别进行优化，尽量确保 简略条件分支优先处理，这样能够 削减嵌套、确保 程序结构清晰。

• 优化前

function checkAuth(user){
    if (user.auth) {
        if (user.name === 'admin') {
            doSomethingByAdmin(user)
        } else if (user.name === 'root') {
            doSomethingByRoot(user)
        }
    }
}

• 优化后

function checkAuth(user){
    if (!user.auth) {
        return
    }
    if (user.name === 'admin') {
        doSomethingByAdmin(user)
    } else if (user.name === 'root') {
        doSomethingByRoot(user)
    }
}

3.4. 兼并条件简化条件判别

• 优化前

if (fruit === 'apple') {
    return true
} else if (fruit === 'cherry') {
    return true
} else if (fruit === 'peach') {
    return true
} else {
    return true
}

• 优化后

const redFruits = ['apple', 'cherry', 'peach']
if (redFruits.includes(fruit) {
    return true
}

3.5. 提取条件简化条件判别

对 晦涩难懂 的条件进行 提取并语义化。

• 优化前

if ((age < 20 && gender === '女') || (age > 60 && gender === '男')) {
    doSomething()
} else {
    doSomethingElse()
}

• 优化后

function isYoungGirl(age, gender) {
    return age < 20 && gender === '女'
}
function isOldMan(age, gender) {
    return age > 60 && gender === '男'
}
if (isYoungGirl(age, gender) || isOldMan(age, gender)) {
    doSomething()
} else {
    doSomethingElse()
}

重构

重构一词有名词和动词上的了解。

• 名词：

对软件内部结构的一种调整，意图是在不改动软件可调查行为的前提下，进步其可了解性，下降其修正本钱。

• 动词：

运用一系列重构手法，在不改动软件可调查行为的前提下，调整其结构。

1. 为何重构

假如遇到以下的状况，或许就要考虑是否需求重构了:

• 重复的代码太多
• 代码的结构紊乱
• 程序没有拓宽性
• 目标结构强耦合
• 部分模块功用低

为何重构，不外乎以下几点：

• 重构改进软件规划
• 重构使软件更简略了解
• 重构协助找到BUG
• 重构进步编程速度

重构的类型

• 对现有项目进行代码等级的重构；
• 对现有的事务进行软件架构的升级和体系的升级。

本文评论的内容只触及第一点，仅限代码等级的重构。

2. 重构时机

第一次做某件事时只管去做；第2次做相似的事会发生反感，但无论如何仍是能够去做；第三次再做相似的事，你就应该重构。

• 添加功用：当添加新功用时，假如发现某段代码改起来特别困难，拓宽功用特别不灵敏，就要重构这部分代码使添加新特性和功用变得更简略；

• 修补过错：在你改 BUG 或查找定位问题时，发现自己曾经写的代码或许他人的代码规划上有缺陷（如扩展性不灵敏），或健壮性考虑得不行周全（如漏掉一些该处理的反常），导致程序频频呈现问题，那么此时便是一个比较好的重构时机；

• 代码检视：团队进行 Code Review 的时分，也是一个进行重构的适宜时机。

代码整齐之道

代码应当 易于了解，代码的写法应当使他人了解它所需的时刻最小化。

代码风格

关键思维：共同的风格比 “正确” 的风格更重要。

准则：

• 运用共同的 代码布局 和 命名
• 让相似的代码看上去 相似
• 把相关的代码行 分组，形成 代码块

注释

注释的意图是尽量协助读者了解到和作者相同多的信息。因而注释应当有很高的 信息/空间率。

1. 好注释

• 特殊符号注释：如 TODO、FIXME 等有特殊含义的符号
• 文件注释：部分规约会约好在文件头部书写固定格局的注释，如注明作者、协议等信息
• 文档类注释：部分规约会约好 API、类、函数等运用文档类注释
• 遵从一致的风格规范，如必定的空格、空行，以确保注释本身的可读性

2. 坏注释

• 喃喃自语，自己感觉要加注释的当地就写上注释
• 剩余的注释：本身代码现已能表达意思就不要加注释
• 误导性注释（随着代码的迭代，注释总有一天会由于过于陈旧而导致发生误导）
• 日志式注释：日志本身能够体现出详细语意，不需求剩余的注释
• 能用函数或许变量称号表达语意的就不要用注释
• 注释掉的代码应该删去，防止误导和混淆

有含义的命名

杰出的命名是一种以 低价值 取得代码 高可读性 的途径。

1. 选择专业名词

单词	更多选择
send	deliver, despatch, announce, distribute, route
find	search, extract, locate, recover
start	launch, create, begin, open
make	create, set up, build, generate, compose, add, new

2. 防止像tmp和retval这样泛泛的姓名

• retval 这个姓名没有包括明确的信息
• tmp 只应用于短期存在且暂时性为其首要存在要素的变量

3. 用详细的姓名代替笼统的姓名

在给变量、函数或许其他元素命名时，要把它描绘得更详细，而不是让人不明所以。

• 反例：

class DtaRcrd102 {
  private genymdhms: Date; // 你能读出这个变量名么？ 
  private modymdhms: Date;
  private pszqint = '102';
}
class DtaRcrd102 {
  private genymdhms: Date; // 你能读出这个变量名么？ 
  private modymdhms: Date;
  private pszqint = '102';
}

• 正例

class Customer {
  private generationTimestamp: Date;
  private modificationTimestamp: Date;
  private recordId = '102';
}
class Customer {
  private generationTimestamp: Date;
  private modificationTimestamp: Date;
  private recordId = '102';
}

4. 为姓名顺便更多信息

假如关于一个 变量 有什么重要的含义需求让读者知道，那么是值得把额外的 “词” 添加到姓名中。

5. 姓名的长度

• 在小的效果域里能够运用短的姓名
• 为效果域大的姓名采用更长的姓名
• 丢掉没用的词

6. 不会被误解的姓名

• 用 min 和 max 来表明极限
• 用 first 和 last 来表明包括的规模
• 用 begin 和 end 来表明扫除规模
• 给布尔值命名：is、has、can、should

7. 语义相反的词汇要成对呈现

正	反
add	remove
create	destory
insert	delete
get	set
increment	decrement
show	hide
start	stop

8. 其他命名小主张

• 核算限定符作为前缀或后缀（Avg、Sum、Total、Min、Max）
• 变量名要能精确地表明事物的含义
• 用动名词命名函数名
• 变量名的缩写，尽量防止不常见的缩写

简化条件表达式

1. 分化条件表达式

有一个杂乱的条件（if-elseif-else）句子，从 if、elseif、else 三个阶段平分别提炼出 独立函数。依据每个小块代码的用处，为分化而得到的 新函数 命名。关于 条件逻辑，能够 杰出条件逻辑，更清楚地表明每个分支的效果和原因。

2. 兼并条件表达式

将这些一系列 相关联 的条件表达式 兼并 为一个，并将这个条件表达式提炼成为一个 独立的办法。

• 确认这些条件句子都没有副效果；
• 运用适当的逻辑操作符，将一系列相关条件表达式兼并为一个；
• 对兼并后的条件表达式施行进行办法抽取。

3. 兼并重复的条件片段

在条件表达式的每个分支上有着一段 重复的代码，将这段重复代码搬移到条件表达式之外。

4. 以卫句子替代嵌套条件表达式

函数中的条件逻辑使人难以看清正常的履行途径。运用 卫句子 体现一切特殊状况。

假如某个条件极端稀有，就应该独自查看该条件，并在该条件为真时马上从函数中回来。这样的独自查看常常被称为 “卫句子”（guard clauses）。

常常能够将 条件表达式回转，从而实以 卫句子 替代 嵌套条件表达式，写成愈加 “线性” 的代码来防止 深嵌套。

变量与可读性

1. 内联暂时变量

假如有一个暂时变量，只是被简略表达式 赋值一次，而将一切对该变量的引证动作，替换为对它赋值的那个表达式本身。

2. 以查询替代暂时变量

以一个暂时变量保存某一表达式的运算成果，将这个表达式提炼到一个独立函数中。将这个暂时变量的一切引证点替换为对新函数的调用。此后，新函数就可被其他函数运用。

3. 总结变量

接上条，假如该表达式比较杂乱，主张经过一个总结变量名来代替一大块代码，这个姓名会更简略办理和考虑。

4. 引进解说性变量

将杂乱表达式（或其中一部分）的成果放进一个 暂时变量，以此 变量称号 来解说表达式用处。

在条件逻辑中，引进解说性变量特别有价值：能够将每个 条件子句 提炼出来，以一个杰出命名的 暂时变量 来解说对应条件子句的 含义。运用这项重构的另一种状况是，在较长算法中，能够运用 暂时变量 来解说每一步运算的含义。

长处：

• 把巨大的表达式拆分成小段
• 经过用简略的姓名描绘子表达式来让代码文档化
• 协助读者识别代码中的首要概念

5. 分化暂时变量

程序有某个 暂时变量 被赋值 超越一次，它既不是循环变量，也不是用于搜集核算成果。针对每次赋值，创造一个独立、对应的暂时变量。

暂时变量有各种不同用处：

• 循环变量
• 成果搜集变量（经过整个函数的运算，将构成的某个值搜集起来）

假如暂时变量承当多个责任，它就应该被替换（分化）为 多个暂时变量，每个变量只承当一个责任。

6. 以字面常量替代 Magic Number

有一个字面值，带有特别含义。创造一个 常量，依据其含义为它 命名，并将上述的字面数值替换为这个常量。

7. 削减操控流变量

let done = false;
while (condition && !done) {
    if (matchCondtion()) {
        done = true;
        continue;
    }
}

像 done 这样的变量，称为 “操控流变量”。它们仅有的意图便是操控程序的履行，没有包括任何程序的数据。操控流变量通常能够经过更好地运用 结构化编程而消除。

while (condition) {
    if (matchCondtion()) {
        break;
    }
}

假如有 多个嵌套循环，一个简略的 break 不行用，通常解决方案包括把代码挪到一个 新函数。

重新安排函数

一个函数尽量只做一件事情，这是程序 高内聚，低耦合 的基石。

1. 提炼函数

当一个过长的函数或许一段需求注释才能让人了解用处的代码，能够将这段代码放进一个 独立函数。

• 函数的粒度小，被 复用 的时机就很大；
• 函数的粒度小，覆写 也会更简略些。

一个函数过长才适宜？长度 不是问题，关键在于 函数称号 和 函数本体 之间的 语义间隔。

2. 代码块与缩进

函数的缩进层级不应该多于 一层 或 两层，关于 超越两层 的代码能够依据 重载 或函数的 详细语意 抽取的的函数。

3. 函数无副效果

每个函数应该只做 一件事，假如一个函数一同做了多件事，比如：

• 在 查询数据 的进程中对数据进行 修正，或许调用 第三方接口，那么这个函数是具有 二义性的。

• 一个函数用于校验数据或许反常，可是在校验进程没有一致 校验规范，存在一同 抛出反常 和 回来正常成果 的状况。那这个函数是不朴实的，也是有夹带现象。

第一种状况能够考虑把函数进行拆分，拆分为 读数据函数 和 写数据函数；第二种状况应该将 校验逻辑 和 获取值 的逻辑抽离为两个函数，校验函数 前置于 获取值函数。一同确保校验函数尽量轻量级。

4. 函数参数优化

函数参数格局尽量防止超越 3 个。参数过多（类型附近）会导致代码 容错性下降，导致参数个数次序传错等问题。假如函数的参数太多，能够考虑将参数进行 分组 和 归类，封装成 独自的目标。

5. 从函数中提早回来

能够经过马上处理 “特殊状况”，能够经过 卫句子 处理，从函数中 提早回来。

6. 重复代码抽取公共函数

应该防止朴实的 copy-paste，将程序中的 重复代码 抽取成公共的函数，这样的长处是防止 修正、删去 代码时呈现忘记或误判。

• 两个办法的 共性 提取到新办法中，新办法分化到别的的类里，从而进步其可见性
• 模板办法形式是消除重复的通用技巧

7. 拆分杂乱的函数

假如有很难读的代码，测验把它所做的 一切使命列出来。其中 一些使命 能够很简略地变成 独自的函数（或类）。其他的能够简略地成为一个函数中的逻辑 “阶段”。

• 查看函数的 命名 是否 名副其实，梳理函数的思路，试图将 顶层函数 拆分成 多个子使命
• 将和使命相关的 代码段、变量生命 进行 聚类归拢，依据依靠调整 代码次序
• 将 各个子使命 抽取成 独自的函数，削减 顶层函数 的杂乱性
• 关于 逻辑依然杂乱 的 子使命，能够进一步细化，并运用以上准则（结合重载）继续剥离抽取
• 关于 代码杂乱性 和 内聚性 本身比较高，代码或许 复用 的代码，抽取成独自的 类文件
• 关于独自抽取 类文件 或许 办法 后依然杂乱的代码，能够考虑引进 规划形式 进行 横向扩展 或 曲线救国。

整齐共同的格局

1. 笔直格局

• 文件长度：短文件 比 长文件 更易于了解，单个文件平均 200 行，最多不超越 300 行
• 分隔：封包声明、导入声明、每个函数之间，能够运用 空白行 标识着新的 独立概念
• 归拢：紧密相关 的代码应该互相归拢
• 变量声明：变量 应尽或许接近其 运用位置。
• 成员变量：应该放在类的顶部声明，不要四处放置
• 假如某个函数调用了别的一个，就应该把它们放在一同，调用者尽或许放在被调用者之上

2. 水平格局

• 一行代码不必死守 80 字符的上限，偶尔抵达 100 字符不超越 120 字符即可
• 区隔与接近：空格强调左右两头的分割，赋值运算符 两头加空格，函数名 与 左圆括号 之间不加空格
• 不必水平对齐：例如声明一堆成员变量时，各行不必每一个单词都对齐
• 短小的 if、while 句子里最好也不要违背 缩进规则，不要这样 if (xx == yy) z = 1;

目标和数据结构

1. 数据笼统

类的长处是 躲藏细节，所以尽量不要在规范的 数据目标 的 getter() 和 setter() 等函数内部进行 自界说扩展。

2. 数据、目标的反对称性

• 面向数据安排的代码：长处是不改动 现有数据结构 前提下添加 新的函数
• 面向目标的代码：长处是不改动 既有函数 的前提下添加 新的类（多态）

3. Demeter规律（最少常识准则）

• 模块不应该了解它 所操作目标 的 内部完成，更不应该了解 目标的目标 的内部完成
• class 的办法只应该调用类本身办法，办法创立的目标，作为参数传递的办法，类所持有的目标
• 办法不应调用由任何函数回来的目标的办法，final String outputDir = ctxt.getOptions.getScratchDir.getAbsolutePath()

注意：关于 函数式编程 和 呼应式编程，或许适用 Optional 和 builder 形式的场景，Demeter规律并不是彻底适用。除此之外的链式调用有或许会带来 空指针 等问题。

类

1. 类的结构安排

类成员界说的先后次序：公共静态常量 -> 私有静态变量 -> 私有实体变量 -> 结构办法 -> 公共函数 -> 私有函数

2. 类应该短小

• 类的长度：关于 函数 咱们核算 代码行数 衡量大小，关于类咱们运用 责任 来衡量
• 类的命名：类的称号描绘其 责任，类的命名是判别类长度的第一个手法，假如无法为某个类命以精确的称号，这个类就太长了，类名包括含糊的词汇，如 Processor、Manager、Super，就说明有 不恰当 的责任聚集状况
• 类的单一责任: 类或许模块应该有一个责任，即只要一条修正的理由
• 类的个数：体系应该由许多短小精悍的类，而不是少数巨型的类组成
• 类的成员变量：类应该只要少数的实体变量，假如一个类中每个实体变量都被每个办法所运用，则说明该类具有最大的内聚性

3. 为修正而安排

1. 类应当对扩展敞开，对修正关闭，即 敞开闭合准则
2. 在抱负体系中，经过扩展体系而非修正现有代码来添加新特性（可惜往往做不到）

4. 组合大于承继

合和承继各有好坏。这个准则的首要观点是，假如你潜意识地倾向于承继，试着想想组合是否能更好地给你的问题建模，在某些状况下能够。

什么时分应该运用承继？这取决于你面临的问题。以下场景运用承继更好:

1. 承继代表的是 “is-a” 联系，而不是 “has-a” 联系 (人 -> 动物 vs 用户 -> 用户详情)。
2. 可复用基类的代码，即有相同行为的代码 (人类能够像一切动物相同移动)。
3. 希望经过更改 基类 对 派生类 进行 大局更改 (改动一切动物在运动时的热量消耗)。

过错处理

在处理程序反常时，常常会用到 try / catch 代码块，而 try / catch 代码块丑陋不胜，运用不小心简略 搞乱代码结构，把 过错处理 与 正常流程 混为一谈。

1. 运用反常而不是回来过错码

• 假如运用 过错码，调用者有必要在函数回来时 马上处理过错，但这很简略被忘记
• 过错码 通常会导致 嵌套判别，使代码结构不谨慎

2. 先写try-catch-finally句子

• 当编写或许会抛反常的代码时，先写好 try-catch-finally 再往里堆逻辑

3. 依据事务场景界说不同的反常处理类

• 依据事务界说不同的 反常类，尽量防止直接运用 Throwable、Exception 和 RuntimeException 捕获 事务层面 的反常。

4. 特例形式，创立一个类来处理特例

• 界说一个装备或许目标来处理特殊状况，你处理了特殊状况后客户代码就不需求捕获反常了

5. 别回来null值

• 回来 null 值的当地都需求 重复的查看，只要一处没查看 null 值，应用程序就会失败
• 当想回来 null 值的时分，能够试试 抛出反常，或许回来特例形式的目标
• 能够经过 Optional.ifPresent() 和 Optional.map().orElseGet() 处理需求回来 null 的场景

6. 别传递null值

• 在办法中传递 null 值是一种很危险的做法，应该尽量防止
• 在进行字符串比较时，要防止将或许为 null 的参数放在 equals() 办法的左边
• 在办法里用 if 或 assert 过滤 null 值参数，可是仍是会呈现运行时过错

编码准则

有必要熟知前人总结的一些经典的 编码准则，以此来改进咱们既有的编码习惯，所谓 “站在伟人肩上编程”。

SOLID准则

SOLID 是面向目标规划（OOD）的五大基本准则的首字母缩写组合，由俗称“鲍勃大叔”的Robert C.Martin在《敏捷软件开发：准则、形式与实践》一书中提出来。

• S(Single Responsibility Principle)：单一责任准则，简称 SRP
• O(Open Close Principle)：敞开关闭准则，简称 OCP
• L(Liskov Substitution Principle)：里氏替换准则，简称 LSP
• I(Interface SegregationPrinciple)：接口阻隔准则，简称 ISP
• D(Dependence Inversion Principle)：依靠倒置准则，简称 DIP

1. 单一责任准则

A class should have only one reason to change.

一个类应该有且仅有 一个原因 引起它的改动。通俗来讲：一个类只担任一项功用或一类相似的功用。当然这个 “一” 并不是肯定的，应该了解为一个类只担任尽或许独立的一项功用，尽或许少的责任。

假如一个类的 功用太多，修正了其中一处很难确认对代码库中其他 依靠模块 的影响。

长处：

• 功用单一，责任清晰。
• 增强可读性，方便保护。

缺陷：

• 拆分得太详细，类的数量会急剧添加。
• 责任的衡量没有一致的规范，需求依据项目完成状况而定。

这条定律相同适用于安排函数时的编码准则。

• 反例：

class UserSettings {
  constructor(private readonly user: User) {
  }
  changeSettings(settings: UserSettings) {
    if (this.verifyCredentials()) {
      doChangeSettings()
    }
  }
  verifyCredentials() {
    doVerifyCredentials()
  }
}

• 正例：

class UserAuth {
  constructor(private readonly user: User) {
  }
  verifyCredentials() {
    doVerifyCredentials()
  }
}
class UserSettings {
  private readonly auth: UserAuth;
  constructor(private readonly user: User) {
    this.auth = new UserAuth(user);
  }
  changeSettings(settings: UserSettings) {
    if (this.auth.verifyCredentials()) {
      doChangeSettings()
    }
  }
}

2. 敞开关闭准则

Software entities （classes,modules,functions,etc.）should be open for extension, but closed for modification.

程序开发进程中（如类、模块、函数等）应该 对拓宽敞开，对修正关闭。换句话说，便是答应在不更改现有代码的状况下添加新功用。

• 反例

class AjaxAdapter extends Adapter {
  constructor() {
    super();
  }
}
class NodeAdapter extends Adapter {
  constructor() {
    super();
  }
}
class HttpRequester {
  constructor(private readonly adapter: Adapter) {
  }
  async fetch<T>(url: string): Promise<T> {
    if (this.adapter instanceof AjaxAdapter) {
      const response = await makeAjaxCall<T>(url);
      // transform response and return
    } else if (this.adapter instanceof NodeAdapter) {
      const response = await makeHttpCall<T>(url);
      // transform response and return
    }
  }
}
function makeAjaxCall<T>(url: string): Promise<T> {
  // request by ajax and return promise
}
function makeHttpCall<T>(url: string): Promise<T> {
  // request by http and return promise
}

• 正例

abstract class Adapter {
  abstract async request<T>(url: string): Promise<T>;
}
class AjaxAdapter extends Adapter {
  constructor() {
    super();
  }
  async request<T>(url: string): Promise<T>{
    // request by ajax and return promise
  }
}
class NodeAdapter extends Adapter {
  constructor() {
    super();
  }
  async request<T>(url: string): Promise<T>{
    // request by http and return promise
  }
}
class HttpRequester {
  constructor(private readonly adapter: Adapter) {
  }
  async fetch<T>(url: string): Promise<T> {
    const response = await this.adapter.request<T>(url);
    // transform response and return
  }
}

3. 里氏替换准则

Functions that use pointers to base classes must be able to use objects of derived classes without knowing it.

一切能引证 基类 的当地有必要能透明地运用其 子类 的目标。

只要 父类 能呈现的当地就能够用 子类 来替换它。反之，子类 不能替换 父类（子类拥有父类的 一切特点和行为，但 子类 拓宽了更多的功用）。

• 反例：

class Rectangle {
  constructor(
    protected width: number = 0, 
    protected height: number = 0) {
  }
  render(area: number) {
  }
  setWidth(width: number) {
    this.width = width;
  }
  setHeight(height: number) {
    this.height = height;
  }
  getArea(): number {
    return this.width * this.height;
  }
}
class Square extends Rectangle {
  setWidth(width: number) {
    this.width = width;
    this.height = width;
  }
  setHeight(height: number) {
    this.width = height;
    this.height = height;
  }
}
function renderLargeRectangles(rectangles: Rectangle[]) {
  rectangles.forEach((rectangle) => {
    rectangle.setWidth(4);
    rectangle.setHeight(5);
    const area = rectangle.getArea(); // BAD: Returns 25 for Square. Should be 20.
    rectangle.render(area);
  });
}
const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);

• 正例：

abstract class Shape {
  setColor(color: string) {
  }
  render(area: number) {
  }
  abstract getArea(): number;
}
class Rectangle extends Shape {
  constructor(private readonly width = 0, 
              private readonly height = 0) {
    super();
  }
  getArea(): number {
    return this.width * this.height;
  }
}
class Square extends Shape {
  constructor(private readonly length: number) {
    super();
  }
  getArea(): number {
    return this.length * this.length;
  }
}
function renderLargeShapes(shapes: Shape[]) {
  shapes.forEach((shape) => {
    const area = shape.getArea();
    shape.render(area);
  });
}
const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)];
renderLargeShapes(shapes);

4. 接口阻隔准则

Clients should not be forced to depend upon interfaces that they don’t use. Instead of one fat interface many small interfaces arepreferred based on groups of methods, each one serving one submodule.

客户端不应该依靠它不需求的接口。用 多个细粒度 的接口来替代由 多个办法 组成的 杂乱接口，每一个接口服务于一个子模块。

接口尽量小，可是要有限度。当发现一个接口过于 臃肿 时，就要对这个接口进行适当的 拆分。可是假如 接口过小，则会造成 接口数量过多，使 规划杂乱化。

• 反例：

interface ISmartPrinter {
  print();
  fax();
  scan();
}
class AllInOnePrinter implements ISmartPrinter {
  print() {
  }  
  fax() {
  }
  scan() {
  }
}
class EconomicPrinter implements ISmartPrinter {
  print() {
  }  
  fax() {
    throw new Error('Fax not supported.');
  }
  scan() {
    throw new Error('Scan not supported.');
  }
}

• 正例：

interface IPrinter {
  print();
}
interface IFax {
  fax();
}
interface IScanner {
  scan();
}
class AllInOnePrinter implements IPrinter, IFax, IScanner {
  print() {
  }  
  fax() {
  }
  scan() {
  }
}
class EconomicPrinter implements IPrinter {
  print() {
  }
}

5. 依靠倒置准则

High level modules should not depend on low level modules; bothshould depend on abstractions. Abstractions should not depend ondetails. Details should depend upon abstractions.

这个准则有两个关键:

1. 高层模块 不应该依靠于 低层模块，两者都应该依靠于 笼统。
2. 笼统 不依靠 完成，完成 应依靠 笼统。

把具有 相同特征 或 相似功用 的类，笼统成 接口 或 笼统类，让详细的 完成类 承继这个 笼统类（或完成对应的接口）。笼统类（接口）担任界说一致的办法，完成类担任详细功用的完成。

• 反例：

import { readFile as readFileCb } from 'fs';
import { promisify } from 'util';
const readFile = promisify(readFileCb);
type ReportData = {
}
class XmlFormatter {
  parse<T>(content: string): T {
    // Converts an XML string to an object T
  }
}
class ReportReader {
  private readonly formatter = new XmlFormatter();
  async read(path: string): Promise<ReportData> {
    const text = await readFile(path, 'UTF8');
    return this.formatter.parse<ReportData>(text);
  }
}
const reader = new ReportReader();
await report = await reader.read('report.xml');

• 正例：

import { readFile as readFileCb } from 'fs';
import { promisify } from 'util';
const readFile = promisify(readFileCb);
type ReportData = {
  // ..
}
interface Formatter {
  parse<T>(content: string): T;
}
class XmlFormatter implements Formatter {
  parse<T>(content: string): T {
    // Converts an XML string to an object T
  }
}
class JsonFormatter implements Formatter {
  parse<T>(content: string): T {
    // Converts a JSON string to an object T
  }
}
class ReportReader {
  constructor(private readonly formatter: Formatter){
  }
  async read(path: string): Promise<ReportData> {
    const text = await readFile(path, 'UTF8');
    return this.formatter.parse<ReportData>(text);
  }
}
const reader = new ReportReader(new XmlFormatter());
await report = await reader.read('report.xml');
// or if we had to read a json report:
const reader = new ReportReader(new JsonFormatter());
await report = await reader.read('report.json');

是否必定要遵从这些规划准则

• 软件规划是一个逐步优化的进程
• 不是必定要遵从这些规划准则

没有充足的时刻，或遵完成本钱太大。在受限不能遵从 五大准则 来规划时，咱们还能够遵从下面这些 更为简略、实用 的准则。

简略、实用的准则

1. LoD准则（Law of Demeter）

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Only talk to your immediate friends, don’t talk to strangers.

每一个逻辑单元应该对其他逻辑单元有最少的了解：也便是说只接近当前的目标。只和直接（接近）的朋友说话，不好陌生人说话。

这一准则又称为迪米特规律，简略地说便是：一个类对自己依靠的类知道的越少越好，这个类只需求和直接的目标进行交互，而不必在乎这个目标的内部组成结构。

例如，类A中有类B的目标，类B中有类C的目标，调用方有一个类A的目标a，这时假如要拜访C目标的特点，不要采用相似下面的写法：

a.getB().getC().getProperties()
仿制代码

而应该是：

a.getProperties()
仿制代码

2. KISS准则（Keep It Simple and Stupid）

Keep It Simple and Stupid.

保持简略和愚蠢。

• “简略”便是要让你的程序能简略、快速地被完成；
• “愚蠢”是说你的规划要简略就任何人都能了解，即简略便是美！

3. DRY准则（Don’t Repeat Yourself）

不要重复你的代码，即屡次遇到相同的问题，应该笼统出一个 通用 的办法，不要重复开发相同的功用。也便是要尽或许地进步代码的 复用率。

要遵从 DRY 准则，完成的办法十分多：

• 函数等级的封装：把一些常常运用的、重复呈现的功用封装成一个通用的函数。
• 类等级的笼统：把具有相似功用或行为的类进行笼统，笼统出一个基类，并把这几个类都有的办法说到基类去完成。
• 泛型规划：Java 中可运用泛型，以完成通用功用类对多种数据类型的支持；C++中能够运用类模板的办法，或宏界说的办法；Python 中能够运用装修器来消除冗余的代码。

DRY 准则在单人开发时比较简略遵守和完成，但在团队开发时不太简略做好，特别是关于大团队的项目，关键仍是团队内的沟通。

4. YAGNI准则（You Aren’t Gonna Need It）

You aren’t gonna need it, don’t implement something until it is necessary.

你没必要那么着急去给你的类完成过多的功用，在你需求它的时分再去完成。

• 只考虑和规划必需的功用，防止 过度规划。
• 只完成目前需求的功用，在以后需求更多功用时，能够再进行添加。
• 如无必要，勿添加杂乱性。

5. Rule Of Three准则

Rule of three 称为 “三次规律”，指的是当某个功用 第三次 呈现时，再进行 笼统化，即 事不过三，三则重构。

• 第一次完成一个功用时，就虽然斗胆去做；
• 第2次做相似的功用规划时会发生反感，可是还得去做；
• 第三次还要完成相似的功用做相同的事情时，就应该去审视是否有必要做这些重复劳动了，这个时分就应该重构你的代码了，即把重复或相似功用的代码进行笼统，封装成一个通用的模块或接口。

6. CQS准则（Command-Query Separation）

• 查询（Query）：当一个办法 回来一个值 来呼应一个问题的时分，它就具有查询的性质；
• 指令（Command）：当一个办法要 改动目标的状态 的时分，它就具有指令的性质。

严格确保办法的行为的办法是 指令 或许 查询，这样查询办法不会改动目标的状态，没有副效果；而会改动目标的状态的办法不或许有回来值。