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