自上而下的軟件開發和自下而上軟件開發
自上而下(Top Down)開發模式是指從一個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的代碼，開發任務就完成了。使用這種方式，你需要設計、編寫出所有你需要的但還沒有實現模擬接口、服務、偽代碼。
自下而上(Bottom up)開發模式是指從一個應用的最底層開始開發。這種方式的考量在于認為最底層是應用中最復雜的部分，或者認為是最重要的部分。這種模式下系統將從一個個小模塊做起，最終構建起整個系統。
我在上大學之初就聽說了自上而下開發模式和自下而上開發模式。當時我并沒有在意它們的區別——因為就是一個徹頭徹尾的自下而上開發的程序員。
然而，隨著閱歷的積累，我慢慢的完全改變了我的立場。我認為，是敏捷開發和 TDD 讓我發生了這樣的變化。我非常強烈的感覺到，我想對每個人大聲說：在一個敏捷開發團隊里，自下而上開發是反模式的。
假設有一個四個人的開發團隊，要完成一個 Web 應用中的下列這些任務。
- 創建控制層(controller) – 主訪問入口，請求映射表。
- 創建服務層(service) – 服務層，簡單業務邏輯。
- 數據庫查詢 – 復雜的數據庫查詢 </ul>
按照自下而上的開發方法，兩個程序員將負責開發復雜的數據庫查詢功能。當這部分代碼可以使用后，另外兩個程序員將開始開發控制層和服務層。
這種開發模式的問題來自痛苦的集成過程。開發服務層的程序員寫代碼時很有可能無法遵守最初計劃時團隊制定的接口規范，這樣，復雜數據庫查詢開發的程序員就不得不修改他們的查詢接口。
// 數據庫接口和服務層要求不一致 query.Execute (id);// 數據庫層的實現是這樣的。 query.Execute (id, typeId);</pre>
這是一個很簡單的例子，但你可以想象一個含有 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 (); }</pre>
這樣一來，任何一個程序員都可以自由選擇開發任何一項任務。如果接口需要改變，則不會發生自下而上模式中的那種依賴另外一組程序員修改進度的情況。另外一個好處是，從一開始，任何一個功能點都是可以做用戶測試的。
自上而下的開發方便每一步都采用 TDD 開發。每一階段開發有各自的測試程序，這保證了各個對象間協作邏輯的正確，保證了業務邏輯實現的正確。之前我說過最初的底層模擬階段是沒有測試的。但這不 意味著我們沒有對它們做 TDD 開發，我們的測試代碼最終會驅動對這些模擬功能的真實實現。頂層的業務邏輯的確定決定了底層的數據服務接口，如果在底層需要增加一個新類，這很容易，它只 是底層的實現，不會影響上層的業務流程。
這種自上而下的開發方法并不是一個新事物，然而有很多人仍然沒有看到它的好處。我計劃在隨后幾個月里對這種實用主義風格的 TDD 做進一步的討論。
來自: www.vaikan.com<span id="shareA4" class="fl"> </span>本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！