英文原文：3 Key Software Principles You Must Understand，翻譯：iteye
在本文中將介紹 3 條重要的軟體開發原則，你可能已經知道，也可能只知道其中一條。這些原則看似很簡單，但實施起來會很難。無論如何，這些原則提供了一個管理複雜軟體專案的強大的途徑。當涉及到真實世界中的專案開發時，你會發現這些原則都是非常有用的。
原則1：不要重複自己（Don’t Repeat Yourself，DRY 原則）
這個原則非常重要，換言之，就是不要寫重複的程式碼。
當你正在構建一個大型的軟體專案時，你通常會被整體複雜性搞得不知所措。解決複雜性的最基本的策略是將系統分成若干個容易處理的部分。起初，你可能想將系統按元件劃分，每個元件代表了一個子系統，其中包含了完成特定功能所需的一切。
元件還可以往下再分，這樣複雜性將被降低到單一職責（single responsibility），每個職責可以使用一個類來實現，類包含了方法和屬性。方法實現演算法，這些演算法和演算法的子部分是構成軟體業務邏輯的最小知識塊。你只需要保證這些塊不重複即可。
DRY 原則規定，在整個系統中，每一個小的知識塊只可能發生一次，且每個知識塊必須有一個單一、明確、權威的表徵。
在一個完美的應用程式中，每一小塊業務邏輯將被封裝在一個表徵中，也就是一個變數或一個類。變數被封裝在一個能夠被描述為一個職責表徵的類中，類被封裝在一個能被描述為功能表徵的元件中。這種方式稱為模組化架構，DRY 原則是其一個重要的部分。
實現 DRY
你可以按照以下方式降低軟體專案的複雜度，以便更容易地發現潛在的重複問題：
●繪製軟體架構圖，並對映主要的元件，複雜的專案可能需要為每個元件繪製一個專門的架構圖。
●如果你到達了連線職責的層級，你可能需要轉換到 UML 圖。
●在寫程式碼塊之前，根據它在專案中的層級命名。定義它代表什麼，並確定你知道它在元件中的作用。
●定義表徵應該展示的內容（如功能是在資料庫驅動程式中執行 SQL）以及應該隱藏的內容（如資料庫認證資訊）。
●確保表徵不依賴於另一個複雜層級的表徵（如一個元件依賴於另一個元件中的類）。
當你發現正寫的程式碼與之前寫過的程式碼類似或相同，你就需要花時間來考慮你正在做什麼，並確保不重複自己。
原則2：儘量簡單、一目瞭然（Keep it Simple Stupid，KISS 原則）
最簡單的解釋往往是最正確的。
這裡的 Stupid 翻譯為“一目瞭然”更好一些，簡單並不意味著一目瞭然，比如“.(){..&};.”，夠簡單吧，但看懂這是什麼嗎？這其實是一個 bash 中的 fork 炸彈（不斷 fork 一個新程式，耗盡系統資源）。
所以做到簡單的同時，還要做到一目瞭然。你也可以這樣理解，將一個軟體做得連白痴都會用。這就是使用者體驗的最高境界了。
如何做到簡單且一目瞭然呢？這要歸結到軟體開發的可維護性和可理解性。KISS 原則往往體現在需求設計階段，當你考慮如何將客戶的需求轉變成一個可實現元件時，嘗試確認以下部分：
●收益和努力比例不調的功能
●高度依賴其他功能的功能
●可能會變得複雜的功能
總而言之，如果一個任務看起來超複雜，試著去考慮一種創造性、獨特的方式。多花時間去討論關鍵點，看是否有其他更合適的方案。
原則3：適可而止（You Ain’t Gonna Need It，YAGNI 原則）
YAGNI 原則指的是隻需要將應用程式必需的功能包含進來，而不要試圖新增任何其他你認為可能需要的功能。
在一個軟體專案中，往往 80% 的時間花費在 20% 的功能上。
當你準備列出一個專案清單時，試著考慮以下問題：
●通過降低抽象的層級，來實現低複雜度
●根據特性將功能獨立出來
●適度接受非功能性需求
●識別耗時的任務，並擺脫它們
這些原則看似簡單，但在實際運作中，會有各種各樣的問題出現。一旦你強迫自己應用這些原則，你會發現你距離創造一個完美的軟體已經不遠了。