優(yōu)秀程序員18大法則

　　程序設計法則，與設計和工程的原理密切相關。

　　1、DRY原則：

　　不要重復（Don’t repeat yourself）——程序設計中一個最根本的原則就是要避免重復。許多編程結構（比如循環(huán)、函數(shù)、類等）的存在就是為了避免重復。

　　2、抽象原則：

　　“每個在程序中有意義的功能片段應該只在源代碼的一處地方實現(xiàn)”。

　　3、KISS（Keep it simple， stupid！）原則：

　　簡單性（避免復雜性）應該永遠當作是一個重要的目標。寫簡單的代碼，不但花費的時間少，錯誤少，而且修改起來也容易。

　　4、避免創(chuàng)建YAGNI（You aren’t going to need it）原則：

　　只有當你需要的時候才去添加額外的功能，不需要就不要畫蛇添足。

　　5、方法要最簡單，效果要一樣好：

　　在編程時，我們需要問問自己“有沒有最簡單的完成任務的途徑”，這有助于我們保持一直行走在簡約設計的道路上。

　　6、不要讓我思考：

　　這實際上是由Steve Krug寫的一本書的書名。關鍵要點是，代碼應該盡可能地易于閱讀和理解。如果閱讀人需要大量的思考才能理解代碼，那么或許這代碼還需要被簡化。

　　7、開/閉原則：

　　軟件實體（類，模塊，函數(shù)等）在擴展時應該開放，在修改時應該關閉。換句話說，你寫的類大家可以擴展，但不能修改。

　　8、為維護者寫代碼：

　　值得寫的代碼要保證將來一定值得維護。未來的你由于經(jīng)歷的代碼太多，也許再回過頭來看這些代碼的時候，也和其他人一樣，已經(jīng)成為了一個完全的陌生人。請記住，“寫代碼的時候，就假設將來要維護的人是個知道你住在哪里的暴力型精神病患者吧”！

　　9、最小驚訝原則：

　　最小驚訝原則通常引用于用戶界面方面，但這一原則也適用于編寫代碼。代碼應該盡可能地不要讓閱讀者驚訝。遵守標準約定，注釋說什么代碼就做什么，命名是什么意思代碼就是什么意思，盡可能地避免驚訝導致的潛在的負面影響。

　　10、單一職責原則：

　　代碼（如類或函數(shù)）的組成部分執(zhí)行的應該是一個單一的明確的任務。

　　11、最小化耦合原則：

　　代碼的任何部分（代碼塊，函數(shù)，類等）都應該盡量減少對其他代碼的依賴。這可以通過盡量不要使用共享變量來實現(xiàn)�！暗婉詈铣３Ｊ怯嬎銠C系統(tǒng)構造良好和設計良好的標志，并且當和高內(nèi)聚力相結合的話，還可以大大支持可讀性和可維護性的整體目標。”

　　12、最大化內(nèi)聚原則：

　　具有相似功能的代碼應該放在同一個組件內(nèi)。

　　13、隱藏實現(xiàn)細節(jié)原則：

　　隱藏實現(xiàn)細節(jié)，允許在改變代碼組件的實現(xiàn)的同時，最低限度地減少對使用該組件的其他模塊的影響。

　　14、得墨忒耳定律：

　　代碼組件應該只和它們的直接關系（如繼承的類，包含的對象，通過參數(shù)傳遞的對象等）溝通。

　　15、避免過早優(yōu)化原則：

　　除非代碼開始工作，否則甚至就不要有優(yōu)化的念頭。只有當你必須要優(yōu)化的時候，才能借助實戰(zhàn)數(shù)據(jù)的幫助。“我們一定要有大局觀，過早的優(yōu)化是萬惡之源”——Donald Knuth。

　　16、重用代碼才是好代碼：

　　這和任何其他法則一樣精辟。重用代碼可以提高代碼的可靠性，并減少開發(fā)時間。

　　17、關注點分離原則：

　　不同的功能區(qū)域應該由明顯的重疊最小的代碼模塊進行管理。

　　18、擁抱變化原則：

　　這是Kent Beck寫的一本書的副標題，也被認為是極端編程和通用敏捷方法的原則。許多其他原則都基于這個理念：你應該期待和歡迎變化。事實上，很多古老的軟件工程法則，例如最小化耦合原則，就是和讓代碼變得更容易改變是直接相關的。無論你是不是一個極端編程的實踐者，這種寫代碼的方法真的很有意義。

【優(yōu)秀程序員18大法則】相關文章：

什么法則讓公司變得優(yōu)秀02-27

法則的作文10-13

七項法則助你事半功倍04-15

職場變態(tài)一族的生存法則02-29

C++程序員03-09

我是小小程序員作文08-26

關于有效管控情緒八大法則07-20

【精品】C++程序員5篇03-09

高壓力環(huán)境處理人際關系三大法則-交際禮儀03-06

遇見優(yōu)秀作文(優(yōu)秀)07-05