三條你必須知道的軟件開發原則

在本文中將介紹3條重要的軟件開發原則，你可能已經知道，也可能只知道其中一條。這些原則看似很簡單，但實施起來會很難。不管如何，這些原則提供了一個管理複雜軟件項目的強大的途徑。當涉及到真實世界中的項目開發時，你會發現這些原則都是很是有用的。

原則1：不要重複本身（Don’t Repeat Yourself，DRY原則）

這個原則很是重要，換言之，就是不要寫重複的代碼。

當你正在構建一個大型的軟件項目時，你一般會被總體複雜性搞得不知所措。解決複雜性的最基本的策略是將系統分紅若干個容易處理的部分。起初，你可能想將系統按組件劃分，每一個組件表明了一個子系統，其中包含了完成特定功能所需的一切。

組件還能夠往下再分，這樣複雜性將被下降到單一職責（single responsibility），每一個職責能夠使用一個類來實現，類包含了方法和屬性。方法實現算法，這些算法和算法的子部分是構成軟件業務邏輯的最小知識塊。你只須要保證這些塊不重複便可。

引用

DRY原則規定，在整個系統中，每個小的知識塊只可能發生一次，且每一個知識塊必須有一個單1、明確、權威的表徵。

在一個完美的應用程序中，每一小塊業務邏輯將被封裝在一個表徵中，也就是一個變量或一個類。變量被封裝在一個可以被描述爲一個職責表徵的類中，類被封裝在一個能被描述爲功能表徵的組件中。這種方式稱爲模塊化架構，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%的功能上。

當你準備列出一個項目清單時，試着考慮如下問題：

• 經過下降抽象的層級，來實現低複雜度
• 根據特性將功能獨立出來
• 適度接受非功能性需求
• 識別耗時的任務，並擺脫它們

這些原則看似簡單，但在實際運做中，會有各類各樣的問題出現。一旦你強迫本身應用這些原則，你會發現你距離創造一個完美的軟件已經不遠了。