每一個程序員都必須遵照的編程原則

  好的編程原則跟好的系統設計原則和技術實施原則有着密切的聯繫。下面的這些編程原則在過去的這些年裏讓我成爲了一名優秀的程序員，我相信，這些原則對任何一個開發人員來講，都能讓他的編程能力大幅度的提升，能讓他開發出可維護性更強、缺陷更少的程序。 

我不要自我重複 — 這也許是在編程開發這最最基本的一個信條，就是要告訴你不要出現重複的代碼。咱們不少的編程結構之因此存在，就是爲了幫助咱們消除重複(例如，循環語句， 函數，類，等等)。一旦程序裏開始有重複現象的出現(例如很長的表達式、一大堆的語句，但都是爲了表達相同的概念)，你就須要對代碼進行一次新的提煉，抽 象。 
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself 

提煉原則 — 跟「不要自我重複原則」相關，這一原則是說「程序中任何一段具備功能性的代碼在源代碼文件中應該惟一的存在。」 
http://en.wikipedia.org/wiki/Abstraction_principle_(programming) 

保持簡單 — 簡單化(避免複雜)永遠都應該是你的頭等目標。簡單的程序讓你寫起來容易，產生的bug更少，更容易維護修改。 
http://en.wikipedia.org/wiki/KISS_principle 

不要開發你目前用不到的功能 — 除非你真正須要用到它，不然不要輕易加上那些亂七八糟用不到的功能。 
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/Cohesion_(computer_science) 

隱藏實現細節 — 隱藏實現細節能最小化你在修改程序組件時產生的對那些使用這個組件的其它程序模塊的影響。 
http://en.wikipedia.org/wiki/Information_Hiding 

笛米特法則(Law of Demeter) — 程序組件應該只跟它的直系親屬有關係(例如繼承類，內包含的對象，經過參數入口傳入的對象等。) 
http://en.wikipedia.org/wiki/Law_of_Demeter 

避免過早優化 — 只有當你的程序沒有其它問題，只是比你預期的要慢時，你才能去考慮優化工做。只有當其它工做都作完後，你才能考慮優化問題，並且你只應該依據經驗作法來優 化。「對於小幅度的性能改進都不應考慮，要優化就應該是97%的性能提高：過早優化是一切罪惡的根源」—Donald Knuth。 
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