优秀程序员的18大法则

DRY原则

不要重复（Don’t repeat yourself）——程序设计中一个最根本的原则就是要避免重复。许多编程结构（好比循环、函数、类等）的存在就是为了不重复。一旦重复（例如，一个长表达式，一系列语句，相同的概念）的话，就会建立一个新的抽象。

 

抽象原则

“每一个在程序中有意义的功能片断应该只在源代码的一处地方实现。”

 

KISS（Keep it simple, stupid!）原则

简单性（避免复杂性）应该永远看成是一个重要的目标。写简单的代码，不但花费的时间少，错误少，并且修改起来也容易。

 

避免建立YAGNI（You aren’t going to need it）原则

只有当你须要的时候才去添加额外的功能，不须要就不要多此一举。

 

方法要最简单，效果要同样好

在编程时，咱们须要问问本身：“有没有最简单的完成任务的途径？”这有助于咱们保持一直行走在简约设计的道路上。

 

不要让我思考

这其实是由Steve Krug写的一本书的书名。关键要点是，代码应该尽量地易于阅读和理解。若是阅读人须要大量的思考才能理解代码，那么或许这代码还须要被简化。

 

开/闭原则

软件实体（类，模块，函数等）在扩展时应该开放，在修改时应该关闭。换句话说，你写的类你们能够扩展，但不能修改。

 

为维护者写代码

值得写的代码要保证未来必定值得维护。将来的你因为经历的代码太多，也许再回过头来看这些代码的时候，也和其余人同样，已经成为了一个彻底的陌生人。请记住，“写代码的时候，就假设未来要维护的人是个知道你住在哪里的暴力型精神病患者吧。”

 

最小惊讶原则

最小惊讶原则一般引用于用户界面方面，但这一原则也适用于编写代码。代码应该尽量地不要让阅读者惊讶。遵照标准约定，注释说什么代码就作什么，命名是什么意思代码就是什么意思，尽量地避免惊讶致使的潜在的负面影响。

 

单一职责原则

代码（如类或函数）的组成部分执行的应该是一个单一的明确的任务。

 

最小化耦合原则

代码的任何部分（代码块，函数，类等）都应该尽可能减小对其余代码的依赖。这能够经过尽可能不要使用共享变量来实现。“低耦合经常是计算机系统构造良好和设计良好的标志，而且当和高内聚力相结合的话，还能够大大支持高可读性和可维护性的总体目标。”

 

最大化内聚原则

具备类似功能的代码应该放在同一个组件内。

 

隐藏实现细节原则

隐藏实现细节，容许在改变代码组件的实现的同时，最低限度地减小对使用该组件的其余模块的影响。

 

得墨忒耳定律

代码组件应该只和它们的直接关系（如，继承的类，包含的对象，经过参数传递的对象等）沟通。

 

避免过早优化原则

除非代码开始工做，不然甚至就不要有优化的念头。只有当你必需要优化的时候，才能借助实战数据的帮助。“咱们必定要有大局观：过早的优化是万恶之源”——Donald Knuth。

 

重用代码才是好代码

这和任何其余法则同样之精辟。重用代码能够提升代码的可靠性，并减小开发时间。

 

关注点分离原则

不一样的功能区域应该由明显的重叠最小的代码模块进行管理。

 

拥抱变化原则

这是Kent Beck写的一本书的副标题，也被认为是极端编程和通用敏捷方法的原则。许多其余原则都基于这个理念：你应该期待和欢迎变化。事实上，不少古老的软件工程法则，例如最小化耦合原则，就是和让代码变得更容易改变是直接相关的。不管你是否是一个极端编程的实践者，这种写代码的方法真的颇有意义