1.DRY原则：不要重复（Don’t repeat yourself）--程序设计中一个最根本的原则就是要避免重复。许多编程结构（比如循环、函数、类等）的存在就是为了避免重复。
2.抽象原则：“每个在程序中有意义的功能片段应该只在源代码的一处地方实现”。
3.KISS（Keep it simple, stupid!）原则：简单性（避免复杂性）应该永远当作是一个重要的目标。写简单的代码，不但花费的时间少，错误少，而且修改起来也容易。
4.避免创建YAGNI（You aren’t going to need it）原则：只有当你需要的时候才去添加额外的功能，不需要就不要画蛇添足。
5.方法要最简单，效果要一样好：在编程时，我们需要问问自己“有没有最简单的完成任务的途径”，这有助于我们保持一直行走在简约设计的道路上。
6.不要让我思考：这实际上是由Steve Krug写的一本书的书名。关键要点是，代码应该尽可能地易于阅读和理解。如果阅读人需要大量的思考才能理解代码，那么或许这代码还需要被简化。
7.开/闭原则：软件实体（类，模块，函数等）在扩展时应该开放，在修改时应该关闭。换句话说，你写的类大家可以扩展，但不能修改。
8.为维护者写代码：值得写的代码要保证将来一定值得维护。未来的你由于经历的代码太多，也许再回过头来看这些代码的时候，也和其他人一样，已经成为了一个完全的陌生人。请记住，“写代码的时候，就假设将来要维护的人是个知道你住在哪里的暴力型精神病患者吧”！
9.最小惊讶原则：最小惊讶原则通常引用于用户界面方面，但这一原则也适用于编写代码。代码应该尽可能地不要让阅读者惊讶。遵守标准约定，注释说什么代码就做什么，命名是什么意思代码就是什么意思，尽可能地避免惊讶导致的潜在的负面影响。
10.单一职责原则：代码（如类或函数）的组成部分执行的应该是一个单一的明确的任务。
11.最小化耦合原则：代码的任何部分（代码块，函数，类等）都应该尽量减少对其他代码的依赖。这可以通过尽量不要使用共享变量来实现。“低耦合常常是计算机系统构造良好和设计良好的标志，并且当和高内聚力相结合的话，还可以大大支持可读性和可维护性的整体目标。”
12.最大化内聚原则：具有相似功能的代码应该放在同一个组件内。
13.隐藏实现细节原则：隐藏实现细节，允许在改变代码组件的实现的同时，最低限度地减少对使用该组件的其他模块的影响。
14.得墨忒耳定律:代码组件应该只和它们的直接关系（如继承的类，包含的对象，通过参数传递的对象等）沟通。
15.避免过早优化原则:除非代码开始工作，否则甚至就不要有优化的念头。只有当你必须要优化的时候，才能借助实战数据的帮助。“我们一定要有大局观，过早的优化是万恶之源”--Donald Knuth。
16.重用代码才是好代码:这和任何其他法则一样精辟。重用代码可以提高代码的可靠性，并减少开发时间。
17.关注点分离原则:不同的功能区域应该由明显的重叠最小的代码模块进行管理。
18.拥抱变化原则:这是Kent Beck写的一本书的副标题，也被认为是极端编程和通用敏捷方法的原则。许多其他原则都基于这个理念：你应该期待和欢迎变化。事实上，很多古老的软件工程法则，例如最小化耦合原则，就是和让代码变得更容易改变是直接相关的。无论你是不是一个极端编程的实践者，这种写代码的方法真的很有意义。
2.抽象原则：“每个在程序中有意义的功能片段应该只在源代码的一处地方实现”。
3.KISS（Keep it simple, stupid!）原则：简单性（避免复杂性）应该永远当作是一个重要的目标。写简单的代码，不但花费的时间少，错误少，而且修改起来也容易。
4.避免创建YAGNI（You aren’t going to need it）原则：只有当你需要的时候才去添加额外的功能，不需要就不要画蛇添足。
5.方法要最简单，效果要一样好：在编程时，我们需要问问自己“有没有最简单的完成任务的途径”，这有助于我们保持一直行走在简约设计的道路上。
6.不要让我思考：这实际上是由Steve Krug写的一本书的书名。关键要点是，代码应该尽可能地易于阅读和理解。如果阅读人需要大量的思考才能理解代码，那么或许这代码还需要被简化。
7.开/闭原则：软件实体（类，模块，函数等）在扩展时应该开放，在修改时应该关闭。换句话说，你写的类大家可以扩展，但不能修改。
8.为维护者写代码：值得写的代码要保证将来一定值得维护。未来的你由于经历的代码太多，也许再回过头来看这些代码的时候，也和其他人一样，已经成为了一个完全的陌生人。请记住，“写代码的时候，就假设将来要维护的人是个知道你住在哪里的暴力型精神病患者吧”！
9.最小惊讶原则：最小惊讶原则通常引用于用户界面方面，但这一原则也适用于编写代码。代码应该尽可能地不要让阅读者惊讶。遵守标准约定，注释说什么代码就做什么，命名是什么意思代码就是什么意思，尽可能地避免惊讶导致的潜在的负面影响。
10.单一职责原则：代码（如类或函数）的组成部分执行的应该是一个单一的明确的任务。
11.最小化耦合原则：代码的任何部分（代码块，函数，类等）都应该尽量减少对其他代码的依赖。这可以通过尽量不要使用共享变量来实现。“低耦合常常是计算机系统构造良好和设计良好的标志，并且当和高内聚力相结合的话，还可以大大支持可读性和可维护性的整体目标。”
12.最大化内聚原则：具有相似功能的代码应该放在同一个组件内。
13.隐藏实现细节原则：隐藏实现细节，允许在改变代码组件的实现的同时，最低限度地减少对使用该组件的其他模块的影响。
14.得墨忒耳定律:代码组件应该只和它们的直接关系（如继承的类，包含的对象，通过参数传递的对象等）沟通。
15.避免过早优化原则:除非代码开始工作，否则甚至就不要有优化的念头。只有当你必须要优化的时候，才能借助实战数据的帮助。“我们一定要有大局观，过早的优化是万恶之源”--Donald Knuth。
16.重用代码才是好代码:这和任何其他法则一样精辟。重用代码可以提高代码的可靠性，并减少开发时间。
17.关注点分离原则:不同的功能区域应该由明显的重叠最小的代码模块进行管理。
18.拥抱变化原则:这是Kent Beck写的一本书的副标题，也被认为是极端编程和通用敏捷方法的原则。许多其他原则都基于这个理念：你应该期待和欢迎变化。事实上，很多古老的软件工程法则，例如最小化耦合原则，就是和让代码变得更容易改变是直接相关的。无论你是不是一个极端编程的实践者，这种写代码的方法真的很有意义。
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/8602/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
内存泄漏分析工具tMemoryMonitor
[实践OK]苹果扩展显示器,Mac如何快捷切换桌面 Mac切换桌面快捷键评论列表
