軟體設計有兩種方式：一種是設計得極為簡潔，沒有看得到的缺陷；另一種是設計得極為複雜，有缺陷也看不出來。第一種方式的難度要大得多。
-- 《皇帝的舊衣》，CACM 1981 年 2 月 C.A.R. Hoare
引言
本文将介紹軟體開發中的核心原則，這裡與設計模式的七大原則不同。雖然衆多的原則都早有耳聞，但是在開發過程中，卻又常常忘記了這些原則，陷入開發的困境。本文再這裡再将這些原則進行重新介紹一番，并帶上自己的一些思考。
軟體開發的核心原則
- 原則一：Don't Repeat Yourself
- 原則二：Keep it simple stupid
- 原則三：You Ain't Gonna Need It
- 原則四：Done is better than perfect
- 原則五：Choose the most suitable things
DRY 原則
Don't Repeat Yourself，簡稱 DRY 原則，即不要重複自身，這是軟體開發的一個基礎原則。很好了解，在軟體開發中不要做重複性勞動。也就是經常說的“不要重複造輪子”。
任何一個知識點在系統内部都應當有一個**唯一、**明确、權威的表述。這個原則又被稱為“真理的單點性（Single Point of Truth）” 或者 SPOT 原則。
重複會導緻前後沖突、産生隐微問題的代碼，原因是當你修改重複點時，往往隻改變了一部分而并非全部。通常，這也說明我們在軟體設計中的代碼的組織沒有想清楚。
對去重的思考
設計過程中：常量、表和中繼資料隻應該聲明和初始化一次，并導入其它地方。通過，可以通過重構去除重複代碼，更改代碼的組織而不更改核心算法。
如果遇到重複資料無法避免，可以思考如下問題：
- 函數封裝：如果代碼中含有重複資料是因為在兩個不同的地方必須使用兩個不同的表現形式，能否寫個函數、工具或者代碼生成程式，讓其中一個由另一個生成，或兩者都來來自同一個來源？
- 文檔或其他形式：如果文檔重複了代碼中的知識點，能否從部分代碼中生成部分文檔，或者反之，或者兩者都來自同一個更進階的表現形式？
- 頭檔案和接口：如果頭檔案和接口聲明重複了實作代碼中的知識點，是否可以找到一種方法，從代碼中生成頭檔案和接口聲明？
資料結構中也存在類似的 SPOT 原則：“無垃圾，無混淆”（No junk，no confusion）。
- “無垃圾”是說資料結構（模型）應該最小化，比如，不要讓資料結構太通用，居然還能表示不可能存在的情況。
- “無混淆”是指在真實世界中絕對明确清晰的狀态在模型中也應該同樣明确清晰。
簡言之，SPOT 原則就是提倡尋找一種資料結構，使得模型中的狀态跟真實世界系統的狀态能夠一一對應。
KISS 原則
Keep it simple stupid，簡稱 KISS 原則。在做軟體設計的工作中，很多時候都不要想得過于複雜，也不要過度設計和過早優化，用最簡單且行之有效的方案也就避免了複雜方案帶來的各種額外成本。這樣既有利與後續的維護，也有利于進一步的擴充。
**思考：**永遠都不會知道使用者會怎麼操作，是以沒有必要在軟體開發中過度設計。
YAGNI 原則
You Ain't Gonna Need it： 即 YAGNI 原則。隻需要将應用程式必需的功能包含進來，而不要試圖添加任何其他你認為可能需要的功能。因為在一個軟體中，往往 80% 的請求都花費在 20% 的功能上。
**思考：**關注軟體中的核心功能，功能越少，開發周期就會越短，才有更有立足于市場。
完成勝于完美
Done is better than perfect： 在面對一個開發任務時，最佳的思路就是先把東西做出來，再去疊代優化。如果一開始就面面俱到，考慮各種細節，那麼很容易鑽牛角尖而延誤項目進度。
這一點在工作中深有體會，每次拿到一個需求總是要能快速傳遞，給使用者測試，能滿足他們的需求比自己想到的完美更重要。
思考：“人無完人，金無足赤”，軟體開發也是，先完成，再優化。
選擇最合适的
Choose the most suitable things： 這是在做方案選擇、技術選型時候的一個很重要的原則。在面對許多技術方案、開源實作的時候，務必做到不能盲目求新，要選擇最合适的而非被吹得天花亂墜的。
- 《Java 工程師修煉之道》
- 《Unix 程式設計藝術》