当提到代码质量，我们可能会想到:代码风格，命名，内聚，耦合，重复代码率，圈复杂度等等。当提到代码优化，我们可能会想到代码风格规范，高内聚，低耦合，单一职责，开放封闭原则，约定优于配置，单元测试等等。

给你一段代码，你能简要扼要的说出当前代码的质量情况，并提出优化的方向吗?

如果觉得这很难，可以参考 3Rs 软件架构。

3rs.png

3Rs 软件架构对代码质量做了分层，给优化代码提供了方向：可读性 => 可重用性 => 可重构。下面我们来具体了解下每层代码的特点及优化方法。

第 4 个阶段: 很难维护的代码

这阶段的代码很难维护，俗称shi代码。这阶段的代码，读起来和改起来都很难。

这阶段的代码读起来难。例如：

  • 代码风格不一致。缩进，空格不一致。
  • 谜一样的命名。
  • 很长很长的函数。
  • 分支很多，嵌套很深的条件语句。

这阶段的代码改起来也难。例如：

  • 大量重复代码，导致一处有问题，要改多处。
  • 高耦合的代码导致，改一个模块，会改对应的很多关联模块。
  • 关联很紧密的代码，但离的很远。改起来好累。

第 3 个阶段： 可读的代码(Readability)

这阶段的代码可读性好。可读性好换个说法就是读起来不费脑子。它有以下的特征：

  • 一致的代码风格。空格，缩进，命名风格(驼峰，中划线等)等在整个项目里是一致的。
  • 合理的命名。“看其名而知其意”。
  • 必要的注释。代码本身无法清晰地阐述作者的意图时，要写注释。
  • 没有代码行数很多(超过1千行)的功能：文件，组件，函数等。
  • 函数的参数数量不超过4个。
  • 没有圈复杂度很高的代码。圈复杂度高往往意味着分支多或嵌套深。

如何达到

要达到这个阶段相对比较容易。

代码检查工具能保证代码风格的统一。代码检查工具也能检查：函数的参数个数，圈复杂度等。工具有: ESLint，CSS Lint等。代码改动后，必须通过工具检查通过后，才允许提交。用代码格式化工具，可以自动修复有代码风格问题的代码。工具有 Prettier 等。

这阶段最难的就是命名了。好的命名是“看其名而知其意”，是直白的，有意义的。推荐使用故宫命名法。了解更多命名的技巧见这里。

第 2 个阶段: 可重用的代码(Reusability)

这阶段的代码是可重用的代码。这个阶段代码的特点：

  • 单一职责。每个模块都只有一个职责。
  • 不必要的重复代码很少。重复代码会导致一处有问题，要改多处。但如果过度追求没有重复，也会导致可读性差，不灵活的问题。
  • 模块间是低耦合，高内聚的。

如何达到

要达到这个阶段需要在做代码设计的时候，设计好模块之间的边界和 API，做到职责清晰，高内聚，低耦合。达到这个阶段的建议：

  • 多写代码。对之前写的代码做复盘。
  • 多读优秀代码，学习借鉴好的地方。
  • 学习设计原则，设计模式。
  • 学习一些具体的技术：函数式编程，响应式编程，面向领域编程等等。

第 1 个阶段: 可重构的代码(Refactorability)

这阶段的代码是可重构的。这意味着，当你重构某块代码(不修改对外的API)，不改其他代码，其他代码仍能正常工作。这个阶段的代码一定是低耦合的。模块之间的连接就像乐高。

如何达到

要达到这个阶段需要：

  1. 隔离副作用。
  2. 测试。
  3. 静态类型。

下面具体来说。

隔离副作用

副作用指修改模块外的数据。例如：修改全局变量，修改 DOM等。

在模块代码中，混入副作用代码会导致如下的问题：

  1. 副作用让代码变得难以测试。当模块依赖的外部数据发生变化后，模块的返回值可能会变化。这让模块的返回变得不稳定。
  2. 副作用会导致模块间的耦合。如果多个模块都依赖某个外部数据，那这几个外部模块之间是耦合的。多个模块改都可以改外部数据，数据流很混乱。
  3. 副作用让我们的系统变得不可预测。如果一个模块改了外部数据，可能会影响整个系统。

如何隔离副作用？答案是在统一的地方管理应用的全局数据。比如用 Redux 或 Vuex。

测试

这边的测试指的是白盒测试。测试可以保证代码的改动不会影响测试覆盖部分的功能。

对前端来说，需要写单元测试，端到端测试。每次提交代码，所有测试都需要跑过。

静态类型

使用静态类型可以规避很多低级的语法和逻辑错误，比如参数少传了。目前前端静态类型主流是用 TypeScript。