軟件三原則的個人理解
在軟件的設計當中前人已經總結了許多的設計原則和設計模式。例如SOLID，GRASP設計原則，這些原則都是基於面向對象設計總結而來的。而GOF23是基於許多常見的場景總結出了一套設計模式，在我們遇到類似的場景，都可以套用設計模式。而今天所講到的軟件三原則是適用於在軟件設計的各個層面的。它不僅適用於面向對象的設計，也適用於面向過程的程序設計；不僅適用於類的設計，也適用於模塊、子系統的設計。就連在項目架構運維部署中也適用於這一套簡單的法則。
1. DRY - Don’t Repeat Yourself
第一條準則是千萬不要重複你自身。盡量在項目中減少重複的代碼行，重複的方法，重複的模塊。其實許多設計原則和模式最本質的思想都是在消除重複。==我們經常提起的重用性和可維護性其實是基於減少重複這一簡單的思想==。為什麼現在微服務盛行呢？正是因為將系統中的服務進行抽取的話，便減少了重複。重複冗餘在維護代碼的時候將是非常困難的。 DRY意味著系統內的每一個部件都應該是唯一的並且是不模糊的。我們可以==通過應用單一職責接口隔離等原則盡量拆分系統，模塊，類，方法·。使其每一個部件都是職責明確的並且可重用的。==
2. KISS - Keep It Simple & Stupid
第二條準則是保持簡單易懂。從小到幾行代碼的寫法大到整個系統的架構我們都應該保持簡單易懂。高手高就高在可以將復雜的東西“簡單”的實現出來。剛入行的時候，我總喜歡用三目運算符將復雜的邏輯用一句冗長的代碼行寫出來。後面才發現這是非常愚蠢的。到了重構或者需求變更的時候，連我自己寫的代碼我都看著非常費勁難以下手。所以我們應該致力於代碼的可理解性。降低複雜度也意味著維護變得簡單。 ==Martin Flower在《重構》中有一句經典的話：”任何一個傻瓜都能寫出計算機可以理解的程序，只有寫出人類容易理解的程序才是優秀的程序員。”== 其實不光是程序，這個原則也可以延伸到產品的設計，業務的設計，項目結構的設計上。
3. YAGNI - You Ain’t Gonna Need It
==第三條準則是你將不會需要它。千萬不要進行過度設計。== 我們經常會在開發當中盡可能的迎合未來可能的需求。而為了迎合某些產生概率極低的需求而設計的成本是非常高的，這種過度設計的收益非常低。可能你深思熟慮的設計花了不少時間成本，卻在未來的兩三年內這個設計卻完全沒有派上用場。一些設計是否必要，更多的應該基於當前的情況。而不是為了應對未來的各種變化，畫蛇添足的設計。如果淘寶一開始就往日均交易上億的情況進行設計的話，那麼可能就不會有今天的淘寶了。因為創業公司的時間是非常寶貴的，比其他公司早一步退出新的服務就能搶占先機。並不是說淘寶不需要考慮以後交易量暴增的情況，而是不應該以當前日均交易才幾萬的情況下去設計編碼日均交易上億的項目。過度設計往往會延緩開發迭代的速度。
YAGNI 原則想到想當在讀易讀程式碼之美學時，也有講到類似的概念，主要是釐清需求範圍跟可能發生的狀況，將會大大減少不必要的開發成本與過度開發可能沒用到的功能