自上而下、自下而上的軟體開發

標籤：style   color   ar   使用   java   sp   strong   資料   on   

首先說明本文是軟體開發方面，不是什麼心理學、社會主義形態。

自上而下（top-down）：也稱逐步設計，指從一個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的代碼，開發工作單位就完成了。使用這種方式，你需要設計、編寫出所有你需要的但還沒有實現類比介面、服務、虛擬碼。相對於“黑匣子”，自上而下的設計方法更容易操作，“黑匣子”可能無法闡述基本的構成要素和模型。

自下而上（bottom-up）：指從一個應用的最底層開始開發。這種方式的考量在於認為最底層是應用中最複雜的部分，或者認為是最重要的部分。這種模式下系統將從一個個小模組做起，最終構建起整個系統。小模組之間是基於訪問-處理而進行相互連訊，彼此間相互聯絡組成一個大的系統。

程式員中有些人有一些潔癖、強迫症的偏好，這並不是表示你寫的代碼有多強，這是一種不好的習慣，如果你養成了這種習慣，你會發現自己很難閱讀別人的代碼，而自己每天只能寫一些小功能、小demo，同時自己寫的小功能、小demo別人一樣也看不懂。

假設有一個四個人的Team Dev，要完成一個Web應用中的下列這些任務。

• 建立控制層(controller) – 主訪問入口，請求映射表。
• 建立服務層(service) – 服務層，簡單商務邏輯。
• 資料庫查詢 – 複雜的資料庫查詢。

按照自下而上的開發方法，兩個程式員將負責開發複雜的資料庫查詢功能。當這部分代碼可以使用後，另外兩個程式員將開始開發控制層和服務層。

這種開發模式的問題來自痛苦的整合過程。開發服務層的程式員寫代碼時很有可能無法遵守最初計劃時團隊制定的介面規範，這樣，複雜資料庫查詢開發的程式員就不得不修改他們的查詢介面。

// 資料庫介面和服務層要求不一致query.Execute(id);// 資料庫層的實現是這樣的。query.Execute(id, typeId);

這是一個很簡單的例子，但你可以想象一個含有30多個小任務的story的情況，有更多的程式員參與，更複雜的業務，這時自下而上的模式就很麻煩了。

經過過去這些年的開發，我開始轉變成使用自上而下的開發模式。我的第一步開發動作是用假方法類比出流程中需要的底層介面、服務實現。裡面沒有真正的邏輯，只實現了對象間互動需要的部分。在這個開發階段裡沒有測試，沒有TDD。因為裡面沒有邏輯。代碼非常簡單，很方便讓同伴進行代碼審查和計劃實現。

// 控制器方法public Result Index(IncomingRequest incomingRequest){    var res = service.Invoke(incomingRequest.X, incomingRequest.Y);    return new Result(res);}// 服務層方法public QueryResult Invoke(int x, int y){    return query.Execute(x, y);} // 資料庫查詢方法public QueryResult Execute(int id, int typeId){    // 這裡沒有資料庫查詢邏輯，這是只是一個空的類比介面。    return new QueryResult();}

這樣一來，任何一個程式員都可以自由選擇開發任何一項任務。如果介面需要改變，則不會發生自下而上模式中的那種依賴另外一組程式員修改進度的情況。另外一個好處是，從一開始，任何一個功能點都是可以做使用者測試的。

自上而下的開發方便每一步都採用TDD開發。每一階段開發有各自的測試程式，這保證了各個對象間協作邏輯的正確，保證了商務邏輯實現的正確。之前我說過最初的底層類比階段是沒有測試的。但這不意味著我們沒有對它們做TDD開發，我們的測試代碼最終會驅動對這些類比功能的真實實現。頂層的商務邏輯的確定決定了底層的資料服務介面，如果在底層需要增加一個新類，這很容易，它只是底層的實現，不會影響上層的商務程序。

即使是以後自己寫架構，往往很多事情不是一步到位，我們需要什麼，可能是未知的，我們就用一個“假的”對象或者介面作為代替，當大部分東西都湊齊了，再來編寫那些“假的”對象或介面。

自上而下、自下而上的軟體開發