软件编码原则

---

原文链接：http://webpro.github.io/programming-principles

---

    每个程序开发人员都会受益于对编程的原则和模式的理解。    为了给自己提供一个参考，我把这个概述写在这里。通过设计，讨论，或者回顾复习，它可能会对你有所帮助。    要注意的是，它距离完成还有很长的距离，并且你也会经常需要在冲突的原则中做出取舍。

这一系列的灵感来之于 The Principles of Good Programming .我认为这更接近，而不是全部符合，我会自己加入一些相关的东西。
此外，我需要更多的原因，细节，和其他的资源的连接。如果你有任何促进的反馈或者建议，请告诉我。

内容

---

属性

• KISS (Keep It Simple Stupid)
• YAGNI
• Do The Simplest Thing That Could Possibly Work
• Keep Things DRY
• Code For The Maintainer
• Avoid Premature Optimization
  

  ---

模块/类作用

• Minimise Coupling
• Law of Demeter
• Composition Over Inheritance
• Orthogonality
  

  ---

模块/类

KISS

大道至简。大部分的系统，简单的总是比复杂的工作的更好。

为什么

• 更少的代码可以节省书写的时间，拥有更少的BUG，并且易修改
• 大道至简，至繁归于至简
• 不是当没有东西可以添加的时候，而是在没有可以带走的东西的时候达到完美。

资源

• KISS 原则
• Keep It Simple Stupid (KISS)

YAGNI

用时实现。YAGNI就是："you aren't gonna need it"的简写：需要的时候再实现它（现在不需要它）

为什么

• 任何只是在明天需要用到的工作特征，意味着它就是去了当前迭代需要的工作特征的作用
• 这会导致代码的臃肿；软件会变得庞大和更加复杂

怎么做

• 总是在你确切需要它们的时候实现它们，而不是你预见要用到它们的时候去实现。

资源

• You Arent Gonna Need It
• You’re NOT gonna need it!
• You ain’t gonna need it

Do The Simplest Thing That Could Possibly Work

用最简单的方式实现需要的功能

为什么

• 如果我们只是关注问题的本身到底是什么，那么真正的过程将会最大化的解决问题。

怎么做

-问一下自己：可以解决这个功能的最简单的方法是什么？

资源

• Do The Simplest Thing That Could Possibly Work

Keep things DRY

在一个系统中每个知识点都必须只有一个唯一的，清楚的，权威的代表

一个程序中每个重要的功能块应该只在源文件中的一个地方去实现。
相似功能被不同的代码块声明的地方，一般可以通过抽象出不同的部分把它们组合到一个文件中。

为什么

• 重复代码（有意或者无意）都会导致维护困难，不利于分离，并且逻辑矛盾混乱
• 对系统中的任何元素修改，另一个逻辑不相关的元素不需要改变
• 此外，逻辑相关的元素，所有的改变要可预见和一致，并且保持同步

怎么做

• 把业务逻辑，长表达式，比如状态，数学公司，元数据等等，只放在一个地方
• 识别系统中用到的每块知识的唯一，清楚的源文件，然后使用这个源文件来产生相应的实例（代码，文档，测试，等等）
• 应用 Rule of three.

资源

• Dont Repeat Yourself

相关

• Abstraction principle
• Once And Only Once is a subset of DRY (also referred to as the goal of refactoring).
• Single Source of Truth
• A violation of DRY is WET (Write Everything Twice)

Code For The Maintainer

易维护

为什么

• 维护是任何工程最昂贵的阶段

怎么做

• 想象自己是一个维护者
• 编码的时候总是想象如果维护你的代码的那个人是个暴力倾向的精神病患者，并且知道你的住处
• 用这种方式去编码和注释，不论什么档次的人拿起你的代码，会乐于阅读并且学习它。
• 不要让别人去思考
• 使用最少惊讶的原则（一看就明白）

资源

• Code For The Maintainer
• The Noble Art of Maintenance Programming

Avoid Premature Optimization

避免过早的优化

Donald Knuth名言：
程序猿浪废了大部分的时间用来思考，或者担心，程序的非关键部分的速度，并且这会严重影响到考虑测试和维护时的效率。
我们应该忘了小的效果，对97%的时间：都浪费在了过早的优化上面。然而我们不应该放弃那关键的3%。

要理解什么才是关键部分，而不是过早优化。

为什么

• 对于瓶颈所在未知
• 在优化后，可能不利于阅读和维护

怎么做

• Make It Work Make It Right Make It Fast（可以工作，正常运转，快速就好）
• 需要的时候才进行优化，并且只有在你发现瓶颈了后再优化

资源

• Program optimization
• Premature Optimization

Minimise Coupling

最小化耦合。

模块或者组件间的耦合就是他们之间的独立性；低耦合最好。
换句话说，耦合就是A代码修改后，B代码出错的可能性。

为什么

• 一个模块中的代码修改之后，通常会影响其他的模块
• 组装的模块间可能需要更多的工作或者时间来改变，因为依赖模块改变了。
• 一个特别的模块可能会不容易复用或者测试，因为必须包含的依赖的模块改变
• 开发者会畏惧改变代码，因为他们不清楚这会有什么影响。

怎么做

• 消除，最小化，和降低需要关联的复杂度
• 通过隐藏实现细节，耦合度就降低了
• 应用迪米特法则

资源

• Coupling
• Coupling And Cohesion

Law of Demeter

迪米特法则

不要和陌生人说话

为什么

• 它通常会导致紧耦合
• 它可能会透漏更多的实现细节

怎么做

一个对象的方法应该只是调用：
- 对象本身
- 方法本身的参数
- 方法中创建的对象
- 对象的任何直接属性

资源

• Law of Demeter
• The Law of Demeter Is Not A Dot Counting Exercise

Composition Over Inheritance

使用继承

为什么

• 类之间的耦合更少
• 使用继承，子类可以容易的实现需要，并且打破LSP

怎么做

• 测试LSP（可替代）来决定什么时候继承
• 组合的关系是“有一个”或者“使用一个”，继承是“是一个”

资源

• Favor Composition Over Inheritance

Orthogonality

正交的基本概念就是概念不相关的东西不应该在系统有关联

资源：Be Orthogonal

与简单相似：设计的越是正交，表达式就越少。学习，阅读，编码一种编程语言就越容易。
正交的特征意味着上下文的独立性；关键的参数具有对称和一致性。

资源：Orthogonality

Maximise Cohesion

单个模块或组件的聚合就是它形成一个有意义单元的职责程度；越高的聚合越好。

为什么

• 增加了理解模块的难度
• 增加了维护系统的难度，因为逻辑域上的改变影响多个模块，并且一个模块的需求变化会导致其他模块的变化
• 增加了复用模块的难度，因为大多数的应用将不再需要模块提供的操作的随机组合

怎么做

• 相关的功能集群共享一个唯一的职责

资源

• Cohesion
• Coupling And Cohesion

Liskov Substitution Principle

里氏替换原则就是对于对象行为的全部预期：
程序中的对象应该是可以用他们的子类型实例替换的，而不会影响程序的正常。

资源

• Liskov substitution principle
• The Liskov Substitution Principle

Open/Closed Principle

软件实体应该对扩展开放，对修改关闭。即在不改变源码的情况下扩展其行为功能。

为什么

• 对已有代码的最小化改变提高可维护性和健壮性

怎么做

• 书写可扩展的类（而不是可修改的）
• 只是显示需要修改的可移动部分，其他的隐藏

资源

• Open Closed Principle
• SOLID JavaScript: The Open/Closed Principle

Single Responsibility Principle

单一职责原则，一个类应该只有一个可以改变的原因。
详细：每个类应该有一个单一的职责，并且这个职责应该被这个类完全封装。
职责可以用来定义为一个可以改变的原因，因此一个类或模块应该拥有一个，并且只有一个，改变的因素。

为什么

• 维护性：改变应该只是在一个模块或类中需要

怎么做

• 应用卷曲原则

资源

• Single responsibility principle

Hide Implementation Details

隐藏实现的细节。一个软件模块通过提供接口来隐藏实现细节，并且没有任何的无关信息

为什么

• 当实现改变时，使用接口的客户端不需要改变

怎么做

• 最小化对于类和成员的访问
• 不要成员数据设为public
• 避免在类的接口中实现私有的方法
• 隐藏更多的实现细节来降低耦合性

资源

• Information hiding

Curly’s Law

克里法则就是关于为任何的特定的代码选择一个单一的，清楚定义的目标：就是做一件事情。单一原则

• Curly’s Law: Do One Thing
• The Rule of One or Curly’s Law