架構師應該遵守的編程原則

程序員擁有一個較好的編程原則能使他的編程能力有大幅的提升，可以使其開發出維護性高、缺陷更少的代碼。以下內容梳理自 StactOverflow 的一個問題：編程時你最先考慮的準則是什麼？

目錄

• KISS（Keep It Simple Stupid）

• DRY（Don’t Repeat Yourself）

• YAGNI – You ain’t gonna need it

• Code For The Maintainer

• Be as lazy as possible.

• Programming is only the road, not the way.

• If you are in a hurry, stroll along slowly. If you really are in a hurry, make a detour.

• Know your path, Neo.

• If it wasn’t tested, it is broken.

• 與程序溝通時分辨原因和結果，與人交流時要分辨事實和觀點

KISS（Keep It Simple Stupid）

KISS 原則是英語 Keep It Simple, Stupid 的首字母縮略字，是一種歸納過的經驗原則。KISS 原則是指在設計當中應當注重簡約的原則。總結工程專業人員在設計過程中的經驗，大多數系統的設計應保持簡潔和單純，而不摻入非必要的複雜性，這樣的系統運作成效會取得最優；因此簡單性應該是設計中的關鍵目標，儘量迴避免不必要的複雜性。

這個首字母縮略詞根據報導，是由洛克希德公司的首席工程師凱利 · 約翰遜（U-2 、SR-71 等的設計者）所創造的。雖然長久以來，它一直是被寫爲 “Keep it simple, stupid”，但約翰遜將其轉化成 “Keep it simple stupid”（無逗號），而且這種寫法仍然被許多作者使用。詞句中最後的 S 並沒有任何隱涵工程師是愚蠢的含義，而是恰好相反的要求設計是易使人理解的。

說明這個原則最好的實例，是約翰遜向一羣設計噴射引擎飛機工程師提供了一些工具，他們所設計的機具，必須可由一名普通機械師只用這些工具修理。因此，“愚蠢” 是指被設計的物品在損壞與修復的關聯之間，它們的難易程度。這個縮寫詞已被美國軍方，以及軟件開發領域的許多人所使用。

另外相類似的概念也可作 KISS 原則的起源。例如 “奧卡姆剃刀”，愛因斯坦的 “一切儘可能簡單”、達芬奇的 “簡單是最終的複雜性” 、安德魯 · 聖艾修伯裏的 “完美不是當它不能再添加時，它似乎是在它不能被進一步刮除時實現的”。

有兩種軟件設計方法，一種是儘可能的簡單並保證沒有什麼缺陷。另外一種方式是儘可能的複雜並保障沒有什麼缺陷。而第一種方式相比第二種更加困難。

保持簡單（避免複雜）永遠是你應該做的第一件事，簡單的代碼不僅寫起來簡單、不容易出 Bug，還易於維護。簡單規則下，還包括：

• Don’t Make Me Think：如果一段程序對於閱讀者來說需要花費太多的努力才能理解，那它很可能需要進一步簡化。

• 最少意外原則：程序代碼應儘可能的不要讓閱讀者感到意外。也就是說應該遵循編碼規範和常見習慣，按照公認的習慣方式進行組織和命名，不符常規的編程動作應該儘可能的避免。

如何把 Kiss 原則應用到工作中？

• 要謙虛，不要認爲自己是個天才，這是你第一個誤解。只有謙虛了，你才能真正達到超級天才的水平，即使不行，who cares！你的代碼那麼 stupid simple，所以你不需要是個天才！

• 將你的任務分解爲 4-12 小時的子任務。

• 把你的問題拆分成多個小問題。每個問題用一個或者很少的幾個類來解決掉。

• 保持你的方法足夠小，每個方法永遠不要超過 30-40 行代碼。每個方法都應該只處理一個小小的問題，不要搞太多 uses case 進去。如果你的方法中有多個分支，嘗試把他們拆分成多個小的方法。這樣不僅容易閱讀和維護，找 bug 也更快。慢慢的你將學會愛。

• 讓你的類也小點，原則和上面的方法是一樣的。

• 先解決問題，然後開始編碼。不要一邊編碼，一邊解決問題。這樣做也沒什麼錯，但你有能力提前把事情切分成多個小的塊，然後開始編碼可能是比較好的。但也請你不要害怕一遍遍重構你的代碼。另外行數還不是爲了衡量質量的標準，只是有個基本的尺子而已。

• 不要害怕幹掉代碼。重構和重做是兩個非常重要的方面。如果你遵循上面的建議，重寫代碼的數量將會最小化，如果你不遵循，那麼代碼很可能會被重寫。

• 其他的任何場景，都請你嘗試儘可能的簡單，simple，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會說，之前的事情就是一坨屎。

參考鏈接：

Do The Simplest Thing That Could Possibly Work：

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

DRY（Don’t Repeat Yourself）

DRY 即 Don’t repeat

ourself（不要重複你自己，簡稱 DRY），或一個規則，實現一次（One rule, one place）是面向對象編程中的基本原則，程序員的行事準則。旨在軟件開發中，減少重複的信息。DRY 的原則是 “系統中的每一部分，都必須有一個單一的、明確的、權威的代表”，指的是（由人編寫而非機器生成的）代碼和測試所構成的系統，必須能夠表達所應表達的內容，但是不能含有任何重複代碼。當 DRY 原則被成功應用時，一個系統中任何單個元素的修改都不需要與其邏輯無關的其他元素髮生改變。此外，與之邏輯上相關的其他元素的變化均爲可預見的、均勻的，並如此保持同步。

我對 DRY 的理解：

• 儘可能的減少重複，如代碼重複、文檔重複、數據重複、表徵重複、開發人員重複（相同的功能不能的開發人員的優自己的實現）

• 不重複造輪子，能夠使用開源的解決方案的情況下沒有必要再實現一遍。

• 重複的事項，儘可能的使用自動化程序解決。

• 不要過於優化，過度追求 DRY，破壞了程序的內聚性。

相關規則有： 

代碼複用：http://en.wikipedia.org/wiki/Code_reuse

YAGNI – You ain’t gonna need it

YAGNI 是 You Ain’t Gonna Need It（你不會需要它）的簡寫，是極限編程的關鍵原則。YAGNI 意思非常簡單：僅在您真正需要它們時纔去做，而不是在您認爲或預見將來可能需要它們時就提前做了！

您可以將 YAGNI 視爲即時製造的擁護者。在這種情況下，製造業正在編寫代碼並交付功能。只有當有人真的需求功能存在時，您纔可以開始工作並創建它。否則，您將保持自己的懶惰！

它爲什麼如此重要？沒有編寫的每一行代碼都是時間，因此可以節省金錢。但是，甚至更多！它是：

• 更少的代碼維護

• 更少的代碼測試

• 事情發生變化時更少的代碼可重構

• 更多時間用於更重要的功能

• 更多時間用於文檔編制

而且還包括：

• 節省了編譯 / 移植的時間

• 節省了測試運行的時間

• 生成時 / 運行時節省了資源

• 不必以某種方式保留的知識

它可以防止什麼？如今，大多數軟件開發都是根據客戶的需求進行的。無論您是在產品公司，在提供開發服務的公司還是在其他地方工作。總是會在某處某人想要具有某個功能。是您的客戶要求具有某個需求的功能，還是產品經理響應客戶的反饋的功能。無論實際驅動者是誰，無論是早晚，這都是實際需求的體現。您正確預見未來功能請求的機會非常低。因此，您很有可能實現某些功能，而不是您的實際利益相關者想要的功能。過早地執行某些操作很可能會導致一切都被丟棄。這是一個沒人真正喜歡的場景！然後，有時會發生另一種情況：沒有人真正需要該功能！

Code For The Maintainer

爲維護者編寫程序。比如讓代碼有自解釋的功能。在你編寫代碼的時候永遠記得將來需要維護他。

參考鏈接：
Code For The Maintainer：http://wiki.c2.com/?CodeForTheMaintainer

Be as lazy as possible.

人類因 “偷懶” 而進步。懶惰只是創造了需求。需求本身並不算進步。滿足需求形成了進步。

偷懶還包括：

• 不要重複發明輪子

• 過度優化是萬惡之源

參考鏈接：

Do The Simplest Thing That Could Possibly Work：

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

Programming is only the road, not the way.

編碼只是一種實現方式，而不是解決方案。編碼只是告訴電腦應該如何去做。要編寫高效、可靠的軟件需要精通算法、最佳實踐等其他與變成相關的內容。

編程前需要先了解你要解決的問題是什麼。編程只是手段並不是目的。能實現並不代表需要實現。知道什麼時候不需要編程或沒有必須要去編程。

If you are in a hurry, stroll along slowly. 

If you really are in a hurry, make a detour.

如果你很忙，那就放慢速度。如果你真的很忙，那就先放一放。這聽起來很愚蠢，但是千萬不要讓自己陷入會導致後期問題的妥協。如果你正在編寫程序的核心部分，儘可能保證精確。如果你在編寫離核心代碼較遠的方法，可以儘可能的加快速度。

Know your path, Neo.

知道你的實現路徑，你需要了解你每天使用的環境、工具及其他依賴的內容，並且把它調試到適合自己的配置。如果你的編程環境真的很好，那麼你編程中的基本不需要關心他。如果你需要完成一項任務，最好的方式是不要引進 “新的內容”，只有當你完全掌握“新的內容” 的時候再去考慮引入。

If it wasn’t tested, it is broken.

如果沒有經過測試的代碼都是不能運行的。

與程序溝通時分辨原因和結果，與人交流時要分辨事實和觀點

相關的準則，包括：

• 最小化耦合關係：代碼片段（代碼塊，函數，類等）應該最小化它對其它代碼的依賴。這個目標通過儘可能少的使用共享變量來實現。

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

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

• 單一職責原則：一個代碼組件 (例如類或函數) 應該只執行單一的預設的任務。

• 隱藏實現細節：隱藏實現細節能最小化你在修改程序組件時產生的對那些使用這個組件的其它程序模塊的影響。

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

原文鏈接：What do you consider the 1st principle(s) of programming?
http://programmers.stackexchange.com/questions/91527/what-do-you-consider-the-1st-principles-of-programming

參考鏈接：Programming Principles
https://github.com/webpro/programming-principles

作者：錢魏 Way

來源：www.biaodianfu.com/principles-of-programming.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6zbTfVnyfnFeqwETsH1D-g