優秀程式設計師的 18 大法則

2015-10-11    分類:程式設計師人生、首頁精華2人評論發表於2015-10-11

本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃

經過多年的積累,我發現,下面這些基本的指導法則,可以幫助我成為一個更加高效的程式設計師

程式設計法則,與設計和工程的原理密切相關。下面這些程式設計法則幫助我讓我獲益匪淺,所以我想分享給大家,希望也能幫助大家更高效,生產出的程式碼更容易維護,並且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寫的一本書的副標題,也被認為是極端程式設計和通用敏捷方法的原則。許多其他原則都基於這個理念:你應該期待和歡迎變化。事實上,很多古老的軟體工程法則,例如最小化耦合原則,就是和讓程式碼變得更容易改變是直接相關的。無論你是不是一個極端程式設計的實踐者,這種寫程式碼的方法真的很有意義。

有什麼想法嗎?歡迎參與到我們熱烈的討論中來!

譯文連結:http://www.codeceo.com/article/18-good-programming-principles.html
英文原文:The Principles of Good Programming
翻譯作者:碼農網 – 小峰
轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]

相關文章