2015-10-11 19:01:54
来源：码农网
 

经过多年的积累，我发现，下面这些基本的指导法则，可以帮助我成为一个更加高效的程序员。

程序设计法则，与设计和工程的原理密切相关。下面这些编程法则帮助我让我获益匪浅，所以我想分享给大家，希望也能帮助大家更高效，生产出的代码更容易维护，并且bug和缺陷更少。

DRY原则

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

抽象原则

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

KISS（Keep it simple, stupid!）原则

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

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

只有当你需要的时候才去添加额外的功能，不需要就不要画蛇添足。

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

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

不要让我思考

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

开/闭原则

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

为维护者写代码

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

最小惊讶原则

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

单一职责原则

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

最小化耦合原则

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

最大化内聚原则

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

隐藏实现细节原则

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

得墨忒耳定律

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

避免过早优化原则

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

重用代码才是好代码

这和任何其他法则一样之精辟。重用代码可以提高代码的可靠性，并减少开发时间。

关注点分离原则

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

拥抱变化原则

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

其實現在學編程的專業中到底有沒有教這些的課程？

這些就是敲代碼的必備技能，不屬行業知識。行業的標準和規範，是行業的，而這個是編程專業自己專有的。

學任何編程語言，都是培養這些思想的過程。你不可能學會所有的語言，但祗要在學會一門語言的過程中養成了這些思想，那麼將來學任何語言都是輕而易舉，因為這些指導你學語言時哪些是好的、哪些是不好的、應如何學。

KISS原則，stupid是“笨”、“愚蠢”的意思，文中並沒有把這個翻譯出來。那句英文的意思，是“保持簡單和愚蠢”，所謂大巧若拙，即是此意。我也經常說“寫直接代碼”，其實“直接代碼”並非我的獨特說法，很多編程規範和建議上都是這麼說的，也是這個意思。

之所以特意挑這個出來說，是因為據我觀察，這裡太多人熱衷於玩技巧了，熱衷寫簡短代碼而不是直接代碼，以技巧高深為榮，能夠直白說出的事情非要繞個圈子說，以別人不懂為能。最典型的例子，是那種用移位代替乘除法的，以及用異或算符交換變量値的，很多人（包括某些“大拿”）都熱衷於推介和使用這類技巧，明明是乘除法不用，非要放棄直接邏輯寫移位代碼叫讀者花費時間思考到底這段代碼的邏輯是真移位還是在做乘除運算（讓讀者遲疑也屬於編碼大忌），他們覺得人家直接寫乘除法就沒技術含量了，殊不知移位算法受限於數據類型是有符號還是無符號，不是萬用的，而異或交換，除了不直接，也祗適用於整型，到別的數據類型，還得老老實實地用中間變量交換，如此則屬於“何必異類”範圍。諸如此類的例子，都正犯KISS原則。學編程以學出那些屠龍術為能，那是走火入魔了。

最後，附送1樓沒有提到兩條箴言給大家：

1.對於那些快速算法，我們總是可以拿一些速度差不多但是更容易理解的算法來替代它們。
2.當你為了加速，把一頁代碼變成幾條簡單的指令時，請不要忘了增加注釋，以使源碼的行數保持為一個常量。（代碼規模守恆定律）

[ 本帖最后由 TonyDeng 于 2015-10-12 16:09 编辑 ]

看看這個人最新的問題，跟他以前所問的問題連起來看，就明白我所謂的“偏”是怎麼回事了。

再送幾句：

1.如果還沒想清楚，就用蠻力算法吧。
2.代碼寫得越急，程序跑得越慢。
3.你用英語都寫不出來的東西就別指望用代碼寫了。
4.注意細節。
5.如果代碼和注釋不一致，那很可能兩者都錯了。
6.如果你發現特殊情況太多，那你肯定用錯方法了。
7.先把數據結構搞清楚，程序的其餘部分自現。

接15樓再來幾個：

1.測試祗能證明程序有錯誤，而不能證明程序沒有錯誤。
2.東西沒壞，就不要亂修。
3.修正程序錯誤的第一步是要先重現這個錯誤。
4.【程序優化第一法則】不要優化。
5.【程序優化第二法則——僅對專家適用】還是不要優化。
6.如果程序員自己模擬實現一個構造比編譯器本身實現那個構造還要快，那編譯器的作者也太失敗了。
7.Lisp程序員知道所有東西的値，卻不知道那些東西的計算成本。
8.那些用手做就已經很快了的事情，就不要用計算機去做了。
9.那些能用計算機迅速解決的問題，就別用手做了。
10.拼命幹活無法取代理解。

我這裡特意摘出來的這些，是有針對性的！比如，這裡第7條，表面上說是Lisp，但實際上對SQL也適用。