程序設(shè)計法則，與設(shè)計和工程的原理密切相關(guān)。下面這些編程法則可以讓大家獲益匪淺，所以分享給大家，希望也能幫助大家高效地生產(chǎn)出更容易維護(hù)的代碼，并且bug和缺陷更少。
1.DRY原則：不要重復(fù)（Don’t repeat yourself）–程序設(shè)計中一個最根本的原則就是要避免重復(fù)。許多編程結(jié)構(gòu)（比如循環(huán)、函數(shù)、類等）的存在就是為了避免重復(fù)。
2.抽象原則：“每個在程序中有意義的功能片段應(yīng)該只在源代碼的一處地方實(shí)現(xiàn)”。
3.KISS（Keep it simple, stupid!）原則：簡單性（避免復(fù)雜性）應(yīng)該永遠(yuǎn)當(dāng)作是一個重要的目標(biāo)。寫簡單的代碼，不但花費(fèi)的時間少，錯誤少，而且修改起來也容易。
4.避免創(chuàng)建YAGNI（You aren’t going to need it）原則：只有當(dāng)你需要的時候才去添加額外的功能，不需要就不要畫蛇添足。
5.方法要最簡單，效果要一樣好：在編程時，我們需要問問自己“有沒有最簡單的完成任務(wù)的途徑”，這有助于我們保持一直行走在簡約設(shè)計的道路上。
6.不要讓我思考：這實(shí)際上是由Steve Krug寫的一本書的書名。關(guān)鍵要點(diǎn)是，代碼應(yīng)該盡可能地易于閱讀和理解。如果閱讀人需要大量的思考才能理解代碼，那么或許這代碼還需要被簡化。
7.開/閉原則：軟件實(shí)體（類，模塊，函數(shù)等）在擴(kuò)展時應(yīng)該開放，在修改時應(yīng)該關(guān)閉。換句話說，你寫的類大家可以擴(kuò)展，但不能修改。
8.為維護(hù)者寫代碼：值得寫的代碼要保證將來一定值得維護(hù)。未來的你由于經(jīng)歷的代碼太多，也許再回過頭來看這些代碼的時候，也和其他人一樣，已經(jīng)成為了一個完全的陌生人。請記住，“寫代碼的時候，就假設(shè)將來要維護(hù)的人是個知道你住在哪里的暴力型精神病患者吧”！
9.最小驚訝原則：最小驚訝原則通常引用于用戶界面方面，但這一原則也適用于編寫代碼。代碼應(yīng)該盡可能地不要讓閱讀者驚訝。遵守標(biāo)準(zhǔn)約定，注釋說什么代碼就做什么，命名是什么意思代碼就是什么意思，盡可能地避免驚訝導(dǎo)致的潛在的負(fù)面影響。
10.單一職責(zé)原則：代碼（如類或函數(shù)）的組成部分執(zhí)行的應(yīng)該是一個單一的明確的任務(wù)。
11.最小化耦合原則：代碼的任何部分（代碼塊，函數(shù)，類等）都應(yīng)該盡量減少對其他代碼的依賴。這可以通過盡量不要使用共享變量來實(shí)現(xiàn)?！暗婉詈铣３Ｊ怯嬎銠C(jī)系統(tǒng)構(gòu)造良好和設(shè)計良好的標(biāo)志，并且當(dāng)和高內(nèi)聚力相結(jié)合的話，還可以大大支持可讀性和可維護(hù)性的整體目標(biāo)?！?/p>
12.最大化內(nèi)聚原則：具有相似功能的代碼應(yīng)該放在同一個組件內(nèi)。
13.隱藏實(shí)現(xiàn)細(xì)節(jié)原則：隱藏實(shí)現(xiàn)細(xì)節(jié)，允許在改變代碼組件的實(shí)現(xiàn)的同時，最低限度地減少對使用該組件的其他模塊的影響。
14.得墨忒耳定律:代碼組件應(yīng)該只和它們的直接關(guān)系（如繼承的類，包含的對象，通過參數(shù)傳遞的對象等）溝通。
15.避免過早優(yōu)化原則:除非代碼開始工作，否則甚至就不要有優(yōu)化的念頭。只有當(dāng)你必須要優(yōu)化的時候，才能借助實(shí)戰(zhàn)數(shù)據(jù)的幫助?！拔覀円欢ㄒ写缶钟^，過早的優(yōu)化是萬惡之源”–Donald Knuth。
16.重用代碼才是好代碼:這和任何其他法則一樣精辟。重用代碼可以提高代碼的可靠性，并減少開發(fā)時間。
17.關(guān)注點(diǎn)分離原則:不同的功能區(qū)域應(yīng)該由明顯的重疊最小的代碼模塊進(jìn)行管理。
18.擁抱變化原則:這是Kent Beck寫的一本書的副標(biāo)題，也被認(rèn)為是極端編程和通用敏捷方法的原則。許多其他原則都基于這個理念：你應(yīng)該期待和歡迎變化。事實(shí)上，很多古老的軟件工程法則，例如最小化耦合原則，就是和讓代碼變得更容易改變是直接相關(guān)的。無論你是不是一個極端編程的實(shí)踐者，這種寫代碼的方法真的很有意義。