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