目錄
-
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，這也是最難的一步，但一旦你擁有了它，你再回頭看，就會說，之前的事情就是一坨屎，
DRY（Don’t Repeat Yourself）
DRY即Don’t repeat yourself（不要重復你自己，簡稱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
為維護者撰寫程式，比如讓代碼有自解釋的功能，在你撰寫代碼的時候永遠記得將來需要維護他，
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.
如果沒有經過測驗的代碼都是不能運行的，
與程式溝通時分辨原因和結果，與人交流時要分辨事實和觀點
相關的準則，包括：
-
最小化耦合關系：代碼片段（代碼塊，函式，類等）應該最小化它對其它代碼的依賴，這個目標通過盡可能少的使用共享變數來實作，
-
最大化內聚性：具有相似功能的代碼應該放在同一個代碼組件里，
-
開放/封閉原則：程式里的物體項(類，模塊，函式等)應該對擴展行為開放，對修改行為關閉，換句話說，不要寫允許別人修改的類，應該寫能讓人們擴展的類，
-
單一職責原則：一個代碼組件(例如類或函式)應該只執行單一的預設的任務，
-
隱藏實作細節：隱藏實作細節能最小化你在修改程式組件時產生的對那些使用這個組件的其它程式模塊的影響，
-
笛米特法則(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
參考資料
-
Do The Simplest Thing That Could Possibly Work
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
-
Code For The Maintainer
http://wiki.c2.com/?CodeForTheMaintainer
-
Do The Simplest Thing That Could Possibly Work
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
-
Programming Principles
https://github.com/webpro/programming-principles
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/principles-of-programming.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/542025.html
標籤：其他
上一篇：讀編程與型別系統筆記07_子型別
下一篇：(Java)設計模式：結構型