在本文中將介紹 3 條重要的軟件開(kāi)發(fā)原則，你可能已經(jīng)知道，也可能只知道其中一條。這些原則看似很簡(jiǎn)單，但實(shí)施起來(lái)會(huì)很難。無(wú)論如何，這些原則提供了一個(gè)管理復(fù)雜軟件項(xiàng)目的強(qiáng)大的途徑。當(dāng)涉及到真實(shí)世界中的項(xiàng)目開(kāi)發(fā)時(shí)，你會(huì)發(fā)現(xiàn)這些原則都是非常有用的。

原則1：不要重復(fù)自己（Don’t Repeat Yourself，DRY 原則）

這個(gè)原則非常重要，換言之，就是不要寫(xiě)重復(fù)的代碼。

當(dāng)你正在構(gòu)建一個(gè)大型的軟件項(xiàng)目時(shí)，你通常會(huì)被整體復(fù)雜性搞得不知所措。解決復(fù)雜性的最基本的策略是將系統(tǒng)分成若干個(gè)容易處理的部分。起初，你可能想將系統(tǒng)按組件劃分，每個(gè)組件代表了一個(gè)子系統(tǒng)，其中包含了完成特定功能所需的一切。

組件還可以往下再分，這樣復(fù)雜性將被降低到單一職責(zé)（single responsibility），每個(gè)職責(zé)可以使用一個(gè)類(lèi)來(lái)實(shí)現(xiàn)，類(lèi)包含了方法和屬性。方法實(shí)現(xiàn)算法，這些算法和算法的子部分是構(gòu)成軟件業(yè)務(wù)邏輯的最小知識(shí)塊。你只需要保證這些塊不重復(fù)即可。

DRY 原則規(guī)定，在整個(gè)系統(tǒng)中，每一個(gè)小的知識(shí)塊只可能發(fā)生一次，且每個(gè)知識(shí)塊必須有一個(gè)單一、明確、權(quán)威的表征。

在一個(gè)完美的應(yīng)用程序中，每一小塊業(yè)務(wù)邏輯將被封裝在一個(gè)表征中，也就是一個(gè)變量或一個(gè)類(lèi)。變量被封裝在一個(gè)能夠被描述為一個(gè)職責(zé)表征的類(lèi)中，類(lèi)被封裝在一個(gè)能被描述為功能表征的組件中。這種方式稱為模塊化架構(gòu)，DRY 原則是其一個(gè)重要的部分。

實(shí)現(xiàn) DRY

你可以按照以下方式降低軟件項(xiàng)目的復(fù)雜度，以便更容易地發(fā)現(xiàn)潛在的重復(fù)問(wèn)題：

●繪制軟件架構(gòu)圖，并映射主要的組件，復(fù)雜的項(xiàng)目可能需要為每個(gè)組件繪制一個(gè)專(zhuān)門(mén)的架構(gòu)圖。

●如果你到達(dá)了連接職責(zé)的層級(jí)，你可能需要轉(zhuǎn)換到 UML 圖。

●在寫(xiě)代碼塊之前，根據(jù)它在項(xiàng)目中的層級(jí)命名。定義它代表什么，并確定你知道它在組件中的作用。

●定義表征應(yīng)該展示的內(nèi)容（如功能是在數(shù)據(jù)庫(kù)驅(qū)動(dòng)程序中執(zhí)行 SQL）以及應(yīng)該隱藏的內(nèi)容（如數(shù)據(jù)庫(kù)認(rèn)證信息）。

●確保表征不依賴于另一個(gè)復(fù)雜層級(jí)的表征（如一個(gè)組件依賴于另一個(gè)組件中的類(lèi)）。

當(dāng)你發(fā)現(xiàn)正寫(xiě)的代碼與之前寫(xiě)過(guò)的代碼類(lèi)似或相同，你就需要花時(shí)間來(lái)考慮你正在做什么，并確保不重復(fù)自己。

原則2：盡量簡(jiǎn)單、一目了然（Keep it Simple Stupid，KISS 原則）

最簡(jiǎn)單的解釋往往是最正確的。

這里的 Stupid 翻譯為“一目了然”更好一些，簡(jiǎn)單并不意味著一目了然，比如“.(){..&};.”，夠簡(jiǎn)單吧，但看懂這是什么嗎？這其實(shí)是一個(gè) bash 中的 fork 炸彈（不斷 fork 一個(gè)新進(jìn)程，耗盡系統(tǒng)資源）。

所以做到簡(jiǎn)單的同時(shí)，還要做到一目了然。你也可以這樣理解，將一個(gè)軟件做得連白癡都會(huì)用。這就是用戶體驗(yàn)的最高境界了。

如何做到簡(jiǎn)單且一目了然呢？這要?dú)w結(jié)到軟件開(kāi)發(fā)的可維護(hù)性和可理解性。KISS 原則往往體現(xiàn)在需求設(shè)計(jì)階段，當(dāng)你考慮如何將客戶的需求轉(zhuǎn)變成一個(gè)可實(shí)現(xiàn)組件時(shí)，嘗試確認(rèn)以下部分：

●收益和努力比例不調(diào)的功能

●高度依賴其他功能的功能

●可能會(huì)變得復(fù)雜的功能

總而言之，如果一個(gè)任務(wù)看起來(lái)超復(fù)雜，試著去考慮一種創(chuàng)造性、獨(dú)特的方式。多花時(shí)間去討論關(guān)鍵點(diǎn)，看是否有其他更合適的方案。

原則3：適可而止（You Ain’t Gonna Need It，YAGNI 原則）

YAGNI 原則指的是只需要將應(yīng)用程序必需的功能包含進(jìn)來(lái)，而不要試圖添加任何其他你認(rèn)為可能需要的功能。

在一個(gè)軟件項(xiàng)目中，往往 80% 的時(shí)間花費(fèi)在 20% 的功能上。

當(dāng)你準(zhǔn)備列出一個(gè)項(xiàng)目清單時(shí)，試著考慮以下問(wèn)題：

●通過(guò)降低抽象的層級(jí)，來(lái)實(shí)現(xiàn)低復(fù)雜度

●根據(jù)特性將功能獨(dú)立出來(lái)

●適度接受非功能性需求

●識(shí)別耗時(shí)的任務(wù)，并擺脫它們

這些原則看似簡(jiǎn)單，但在實(shí)際運(yùn)作中，會(huì)有各種各樣的問(wèn)題出現(xiàn)。一旦你強(qiáng)迫自己應(yīng)用這些原則，你會(huì)發(fā)現(xiàn)你距離創(chuàng)造一個(gè)完美的軟件已經(jīng)不遠(yuǎn)了。