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

vaikan發表於2014-02-19

　　自上而下(Top Down)開發模式是指從一個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的程式碼，開發任務就完成了。使用這種方式，你需要設計、編寫出所有你需要的但還沒有實現模擬介面、服務、虛擬碼。

　　自下而上(Bottom up)開發模式是指從一個應用的最底層開始開發。這種方式的考量在於認為最底層是應用中最複雜的部分，或者認為是最重要的部分。這種模式下系統將從一個個小模組做起，最終構建起整個系統。

　　我在上大學之初就聽說了自上而下開發模式和自下而上開發模式。當時我並沒有在意它們的區別——因為就是一個徹頭徹尾的自下而上開發的程式設計師。

　　然而，隨著閱歷的積累，我慢慢的完全改變了我的立場。我認為，是敏捷開發和TDD讓我發生了這樣的變化。我非常強烈的感覺到，我想對每個人大聲說：在一個敏捷開發團隊裡，自下而上開發是反模式的。

　　假設有一個四個人的開發團隊，要完成一個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開發，我們的測試程式碼最終會驅動對這些模擬功能的真實實現。頂層的業務邏輯的確定決定了底層的資料服務介面，如果在底層需要增加一個新類，這很容易，它只是底層的實現，不會影響上層的業務流程。

　　這種自上而下的開發方法並不是一個新事物，然而有很多人仍然沒有看到它的好處。我計劃在隨後幾個月裡對這種實用主義風格的TDD做進一步的討論。

　　英文原文：Top Down vs Bottom Up

相關文章