编程原则

长久以来，不论是初出茅庐还是业界的老前辈，都依然强调着编程原则和设计原则。Bob大叔在他的《整洁架构之道》中提到，写这本书就是为了讲述这些规则，这些永恒的，不变的软件架构规则。

在学习各种编程原则的时候，看到了 Christopher Diggins 的这篇良好编程的原则，其中罗列了各种原则以及相应的链接，认为多年来这些编程原则帮助让其成为更好的程序员，且可以帮助任何开发人员来提高效率，写出更加易于维护、BUG更少的代码。

DRY-Don‘t repeat yourself - 这是编程中的一个基本原则，就是避免重复。许多编程结构仅用于此目的（例如循环，函数，类等）。一旦你开始重复自己（例如一个长表达式，一系列语句，相同的概念），就创建一个新的抽象。 http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

抽象原则 - 与DRY相关的抽象原则是“程序中的每一个重要功能都应该在源代码中的一个地方实现”。http://en.wikipedia.org/wiki/Abstraction_principle_(programming）

KISS（保持简单，愚蠢！） - 简单（并避免复杂性）应始终是一个关键的目标。简单的代码编写时间更短，错误更少，更容易修改。 http://en.wikipedia.org/wiki/KISS_principle

避免创建 YAGNI（You aren‘t going to need it） - 尝试在需要之前不添加功能。http://en.wikipedia.org/wiki/YAGNI

做最简单的事可能有用 - 在编程前问自己一个问题，“做什么最简单的事情可能有用？”这有助于我们在设计中走向简单化的道路。http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

不要让我思考 - 这是 Steve Krug 的关于web易用性的一本书的标题，它也与编程有关。关键是代码应该易于阅读和理解，只需要最少的努力。如果代码需要阅读者过多的思考才能理解，那么它可能还需要被简化。http://www.sensible.com/dmmt.html

开闭原则 - 软件的类、模块、功能等应该对扩展开放，对修改关闭。换句话说，不要编写可以修改的类，而是编写可以扩展的类。http://en.wikipedia.org/wiki/Open_Closed_Principle

为维护者编写代码 - 几乎所有值得写的代码都值得在将来维护。你必然也会维护其他人写的代码，踩别人留下的坑。有句话可以让你深刻的记住这一点，“维护你的代码的人是一个知道你住在哪里的暴力精神病患者。“ http://c2.com/cgi/wiki?CodeForTheMaintainer

最不惊讶的原则 - 最不惊讶的原则通常在用户界面方面被引用，但同样的原则适用于书面代码。代码应该尽可能少地让读者感到惊讶。遵循标准惯例的方法，代码应该做注释和名称所暗示的，并且应该尽可能避免可能出人意料的副作用。 http://en.wikipedia.org/wiki/Principle_of_least_astonishment

单一责任原则 - 代码（例如类或函数）应执行单个定义良好的任务。 http://en.wikipedia.org/wiki/Single_responsibility_principle

最小化耦合 - 代码的任何部分（代码块，函数，类等）应最小化对其他代码区域的依赖性。这是通过尽可能少地使用共享变量来实现的。“低耦合通常是结构良好的计算机系统和良好设计的标志，当与高内聚相结合时，支持高可读性和可维护性的一般目标” [http://en.wikipedia.org/wiki/Coupling_（ computer_programming](http://en.wikipedia.org/wiki/Coupling_(computer_programming)）

最大化内聚 - 应在同一组件中找到具有类似功能的代码。 http://en.wikipedia.org/wiki/Cohesion_(computer_science）

隐藏实现详细信息 - 隐藏实现详细信息允许更改代码组件的实现，同时最小化影响使用该组件的任何其他模块。 http://en.wikipedia.org/wiki/Information_Hiding

迪米特法则 - 一个组件只应与它的直接关系进行通信（例如它继承的类，它包含的对象，通过参数传递的对象等） http://en.wikipedia.org/wiki/Law_of_Demeter

避免过早优化 - 除非你的代码有效，否则不要考虑优化，但要比你想要的慢。只有这样才能开始考虑优化，然后才能借助经验数据。“我们应该忘记小的效率，大约97％的时间说：过早的优化是所有邪恶的根源” - 唐纳德克努特。 http://en.wikipedia.org/wiki/Program_optimization

重用代码 - 重用代码可提高代码可靠性并缩短开发时间。 http://en.wikipedia.org/wiki/Code_reuse

关注点分离 - 不同的功能区域应该由不同且最小重叠的代码模块来管理。 http://en.wikipedia.org/wiki/Separation_of_concerns

拥抱变化 - 这是Kent Beck的一本书的副标题，也被认为是极限编程和敏捷方法的一个原则。许多其他原则都基于您应该期待的概念并欢迎变革。事实上，最小化耦合等非常古老的软件工程原则与使代码更容易更改的要求直接相关。无论您是否是一名极限编程实践者，这种编写代码的方法都是有意义的。http://www.amazon.com/gp/product/0321278658

参考文献：

• The Principles of Good Programming