本文是從 The Principles of Good Programming 這篇文章翻譯而來。

　　好的編程原則跟好的系統(tǒng)設計原則和技術實施原則有著密切的聯(lián)系。下面的這些編程原則在過去的這些年里讓我成為了一名優(yōu)秀的程序員，我相信，這些原則對任何一個開發(fā)人員來說，都能讓他的編程能力大幅度的提高，能讓他開發(fā)出可維護性更強、缺陷更少的程序。

　　不要自我重復（DRY - Don’t repeat yourself）—— 這也許是在編程開發(fā)中最最基本的一個信條，就是要告訴你不要出現(xiàn)重復的代碼。我們很多的編程結構之所以存在，就是為了幫助我們消除重復（例如，循環(huán)語句，函數(shù)，類，等等）。一旦程序里開始有重復現(xiàn)象的出現(xiàn)（例如很長的表達式、一大堆的語句，但都是為了表達相同的概念），你就需要對代碼進行一次新的提煉，抽象。

　　http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

　　提煉原則（Abstraction Principle） ——跟“不要自我重復”原則相關，這一原則是說“程序中任何一段具有功能性的代碼在源代碼文件中應該唯一的存在。”

　　http://en.wikipedia.org/wiki/Abstraction_principle_(programming)

　　保持簡單 ——簡單化（避免復雜）永遠都應該是你的頭等目標。簡單的程序讓你寫起來容易，產(chǎn)生的bug更少，更容易維護修改。

　　http://en.wikipedia.org/wiki/KISS_principle

　　不要開發(fā)你目前用不到的功能 ——除非你真正需要用到它，否則不要輕易加上那些亂七八糟用不到的功能。

　　http://en.wikipedia.org/wiki/YAGNI

　　用最簡單的方法讓程序跑起來 ——在開發(fā)時有個非常好的問題你需要問問自己，“怎樣才能最簡單的讓程序跑起來？”這能幫助我們在設計時讓程序保持簡單。

　　http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

　　不要讓我動腦子 ——這實際上是Steve Krug 關于web界面操作的一本書的書名，但也適用于編程。主旨是，程序代碼應該讓人們花最小的努力就能讀懂和理解。如果一段程序對于閱讀者來說需要花費太多的努力才能理解，那它很可能需要進一步簡化。

　　http://www.sensible.com/dmmt.html

　　開放/封閉原則 ——程序里的實體項（類，模塊，函數(shù)等）應該對擴展行為開放，對修改行為關閉。換句話說，不要寫允許別人修改的類，應該寫能讓人們擴展的類。

　　http://en.wikipedia.org/wiki/Open_Closed_Principle

　　為維護者寫程序 ——任何值得你編寫的程序在將來都是值得你去維護的，也許由你維護，也許由他人。在將來，當你不得不維護這些程序時，你對這些代碼的記憶會基本上跟一個陌生人一樣，所以，你最好還是當成一直在給別人寫程序。一個有助于你記住這個原則的辦法是“寫程序時時刻記著，這個將來要維護你寫的程序的人是一個有嚴重暴力傾向，并且知道你住在哪里的精神變態(tài)者”。

　　http://c2.com/cgi/wiki?CodeForTheMaintainer

　　最少意外原則 ——最少意外原則通常是使用在用戶界面設計上，但這個原則同樣適用于編寫程序。程序代碼應盡可能的不要讓閱讀者感到意外。也就是說應該遵循編碼規(guī)范和常見習慣，按照公認的習慣方式進行組織和命名，不符常規(guī)的編程動作應該盡可能的避免。

　　http://en.wikipedia.org/wiki/Principle_of_least_astonishment

　　單一職責原則 ——一個代碼組件（例如類或函數(shù)）應該只執(zhí)行單一的預設的任務。

　　http://en.wikipedia.org/wiki/Single_responsibility_principle

　　最小化耦合關系 ——一個代碼片段（代碼塊，函數(shù)，類等）應該最小化它對其它代碼的依賴。這個目標通過盡可能少的使用共享變量來實現(xiàn)。“低耦合是一個計算機系統(tǒng)結構合理、設計優(yōu)秀的標志，把它與高聚合特征聯(lián)合起來，會對可讀性和可維護性等重要目標的實現(xiàn)具有重要的意義。”

　　http://en.wikipedia.org/wiki/Coupling_(computer_programming)

　　最大化內聚性 ——具有相似功能的代碼應該放在同一個代碼組件里。

　　http://en.wikipedia.org/wiki/Cohesion_(computer_science)

　　隱藏實現(xiàn)細節(jié) ——隱藏實現(xiàn)細節(jié)能最小化你在修改程序組件時產(chǎn)生的對那些使用這個組件的其它程序模塊的影響。

　　http://en.wikipedia.org/wiki/Information_Hiding

　　笛米特法則(Law of Demeter) ——程序組件應該只跟它的直系親屬有關系（例如繼承類，內包含的對象，通過參數(shù)入口傳入的對象等。)

　　http://en.wikipedia.org/wiki/Law_of_Demeter

　　避免過早優(yōu)化 ——只有當你的程序沒有其它問題，只是比你預期的要慢時，你才能去考慮優(yōu)化工作。只有當其它工作都做完后，你才能考慮優(yōu)化問題，而且你只應該依據(jù)經(jīng)驗做法來優(yōu)化。“對于小幅度的性能改進都不該考慮，要優(yōu)化就應該是97%的性能提升：過早優(yōu)化是一切罪惡的根源” — Donald Knuth。

　　http://en.wikipedia.org/wiki/Program_optimization

　　代碼復用 ——這不是非常核心的原則，但它跟其它原則一樣非常有價值。代碼復用能提高程序的可靠性，節(jié)省你的開發(fā)時間。

　　http://en.wikipedia.org/wiki/Code_reuse

　　職責分離 ——不同領域的功能應該由完全不同的代碼模塊來管理，盡量減少這樣的模塊之間的重疊。 

　　http://en.wikipedia.org/wiki/Separation_of_concerns

　　擁抱變化 ——這是Kent Beck的一本書的副標題，它也是極限編程和敏捷開發(fā)方法的基本信條之一。很多的其它原則都基于此觀念：面對變化，歡迎變化。事實上，一些經(jīng)典的軟件工程原則，例如最小化耦合，就是為了讓程序更容易面對變化。不論你是否采用了極限編程方法，這個原則對你的程序開發(fā)都有重要意義。

　　http://www.amazon.com/gp/product/0321278658

it知識庫：每個程序員都必須遵守的編程原則，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。