✏️写作：个人博客，InfoQ，掘金，知乎，CSDN

📧公众号：进击的Matrix

🚫特别声明：原创不易，未经授权不得转载或抄袭，如需转载可联系小编授权。

七个设计原则

是什么：代码有效性审查的观点

怎样做才能在开发时避免代码中存在故障隐患

七个设计原理是我们设计代码结构时应考虑的核心观点，目的是避免代码中存在故障隐患。这些设计原理源于对实际软件开发现场的分析，是提高代码质量的经验结晶。同时七个设计原理是代码审查的判断标准。

这七个设计原理如下所示：

• 简单性原理

• 同构原理

• 对称原理

• 层次原理

• 线性原理（透明原理）

• 清晰原理

• 安全原理

为什么：代码价值观不遗漏且不动摇

代码审查是保证软件质量的有效方法。不过，审查如果没有一定的价值观或观点作为基础，指出的意见就不会有针对性。

在审查者不同或者具体情况不同时，就会出现观点遗漏、意见前后不一等情况，审查本身的质量都难以保证证。因此，我们需要七个设计原理这种固定的判断标准。

怎么做：将七个设计原理应用于代码的编写

将七个设计原理视为代码共同的价值观，用作代码审查的判断标准。七个设计原理也是我们编写代码时应该考虑的内容。

简单性原理

Simplicity Principle

是什么: 追求简单

简单性原理就是追求简单，就是自始至终都以最简单的逻辑编写代码，让编程初学者一眼就能看懂。

因此，在编程时我们要重视的是局部的完整性，而不是复杂的整体关联性。

为什么：bug 喜欢出现在复杂的地方

怎么做：编写自然的代码

努力写出自然的代码，放下高超的技巧，坚持用简单的逻辑编写代码。

既然故障集中在代码复杂的区域，那我们只要让代码简单到让故障无处可藏即可。不要满目地让代码复杂化，用臃肿化，要保证代码简洁。

同构原理

Isomorphism Principle

同构原理就是力求规范。

同等对待相同的东西，坚持不搞特殊，同等对待。举例来说是：同一个模块管理的数值全部采用同一单位、公有函数的参数个数统一等等。

为什么：不同的东西会更显眼

相同的东西用相同的形式表现能够使不同的东西更加突出，不同的东西往往容易产生 bug。

遵循同构原理能让我们更容易嗅出代码的异样，从而找出问题所在。

怎么做：编写符合规范的代码

我们要让代码符合一定的规范，抑制程序员的自我表现欲望。

程序员小小的自我满足远不及代码质量重要，所以在编写代码时务必要克制自己的表现欲，以规范为先。

对称原理

Symmetry Principle

对称原理就是讲究形式上的对称，也就是说，我们在思考一个处理时，也要想到与之成对的处理，比如有给标志位置 1 的处理，就要给有标志位置 0 的处理。

为什么：帮助读代码的人推测后面的代码

具有对称性的代码能够帮助读代码的人推测后面的代码。提高其理解代码的速度。同时，对称性会给代码带来美感，这同样有助于他人理解代码。

同样，设计代码时将对称性纳入考虑的范围能防止我们在思考问题时出现遗漏。如果说代码的条件分支是故障的温床，那么对称性就是思考的框架，能有效阻止条件遗漏。

怎么做：编写有对称性的代码

在出现“条件”的时候，我们要注意它的“反条件”。每个控制条件都存在与之成对的反条件（与指示条件相反的条件）。要注意条件与反条件的统一。保证控制条件具有统一性。

我们还要考虑到例外情况并极力避免其发生，例外情况的特殊性会破坏对称性，成为故障的温床。特殊情况过多意味着需求没有得到整理。此时应重新审视需求，尽量从代码中剔除例外情况。

命名也要讲究对称性，命名时建议使用 set/get、start/stop、begin/end 和 push/pop 等成对的词语。

层次原理

Hierarchy Principle

层次原理就是在结构上讲究层次。注意事物的主从关系、前后关系和本末关系等层次关系，整理事物关联性。

不同层次各司其职，同种处理不跨越多个层次，这一点非常重要：比如执行了获取资源的处理，那么释放资源的处理就要在相同的层次进行。比如互斥控制的标志位置 1 和位置 0 的处理要在同一层次进行。

为什么：层次结构有助于提高代码的可读性

有明确层次结构的代码能帮助读代码的人抽象理解代码的整体结构。

读代码的人可以根据自身需要阅读下一层次的代码，掌握更加详细的信息。

怎么做：编写有抽象层次结构的代码

在编写代码时设计各部分的抽象程度，构建层次结构。保证同一个层次中的所有代码抽象程度相同，另外、高层次的代码要通过外部视角描述低层次的代码。这样做能让调用低层次代码的高层次代码更加简单易懂。

线性原理

Linearity Principle（透明原理）

处理流程尽量走直线线性原理就是让处理流程尽量走直线。

一个功能如果可以通过多个功能的线性结合来实现，那它的结构就会非常简单。反之，用条件分支控制代码，毫无章法地增加状态等行为会让代码变得难以理解，因此我们要避免出现这些行为，提高代码的可读性。

为什么：直线处理可提高代码的可读性

复杂的处理流程是故障的温床，如果能让处理由高层次流向低层次，一气呵成，代码的可读性就会大幅提高。与此同时，可维护性也将提高，添加功能等改良工作将会变得更加容易。

一般来说，自上而下的处理流程简单明快，易于理解。我们应避开复杂反复的处理流程。

怎么做：尽量不在代码中使用条件分支

尽量减少条件分支的数量，编写能让代码阅读者线性地看完整个处理的代码。为此，我们需要把一些特殊的处理拿到主处理之外，保证处理的统一性，注意处理的流程，记得时不时俯瞰代码整体，检查代码是否存在过于复杂的部分。

清晰原理

Clartiy Principle

清晰原理就是注意逻辑的清晰性。

逻辑具有清晰性就代表逻辑能清楚证明自身的正确性。也就是说，我们编写的代码要让人一眼就能判断出没有问题。任何不明确的部分都要附有说明。

为什么：消除不确定性

代码免不了被人一遍又一遍的阅读。所以代码必须保持较高的可读性。编写代码时如果追求较高的可读性，我们就不会采取取巧的方式编写代码，编写出的代码会非常自然。消除代码的不确定性是对自己的作品负责，这么做也可以为后续负责维护的人提供方便。

怎么做：编写逻辑清晰的代码

要编写逻辑清晰的代码。因此应选用直观易懂的逻辑，另外应使用任何人都能立刻理解且不存在歧义的术语。要特别注意变量名等一定不能没有意义。

扩展一：重复使用代码的风险

如清晰原理所主张的那样，代码必须能让人一眼看出其结构，顺利理解其内容，并且没有歧义。重复使用代码是件好事，但也存在风险，在使用某段代码之前，一定要仔细确认其运行条件和上下文。

扩展二：修复代码故障的风险

相较于重复使用，在修复现有代码的故障时，我们更需要去深入理解代码。修复必须建立在充分理解代码的基础之上，否则考虑的情况就会不全面，导致代码退化。“代码能运行就好”的思想并不适用于修复现有代码的故障。我们应充分理解代码，充分理解故障类型，进而提出假设，然后在次基础上修复故障，进而全面测试，从而保证代码的质量。

安全原理

Safty Principle

安全原理及时注意安全性，采用相对安全的方法来对具有不确定性的、模糊的部分进行设计和编程。具体说就是在编写代码时刻意将不可能的条件考虑进去。例如：1、即便某个 if 语句一定成立，我们也要考虑 else 语句的情况；2、即便某个 case 语句一定成立，我们也要考虑 default 语句的情况；3、即便某个变量不可能为空，我们也要检查该变量是否为 NULL。

为什么：防止故障发展成重大事故

硬件提供的服务必须保证安全，软件也一样，设计软件时也需要考虑各种情况，保证软件在各种情况下都能安全运行，这一做法在持续运营服务和防止数据损坏等方面有着积极的意义。

怎么做：编写安全的代码

选择相对安全的方法对具有不确定的部分进行设计，列出所有可能得运行情况，确保软件在每种情况下都能安全运行。理解需求和功能，将各种情况正确分解到代码中，这样能有效提高软件安全运行的概率。