**
自上而下(top down)開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的**，開發任務就完成了。使用這種方式，你需要設計、編寫出所有你需要的但還沒有實現模擬介面、服務、偽**。
自下而上(bottom up)開發模式是指從乙個應用的最底層開始開發。這種方式的考量在於認為最底層是應用中最複雜的部分，或者認為是最重要的部分。這種模式下系統將從乙個個小模組做起，最終構建起整個系統。
我在上大學之初就聽說了自上而下開發模式和自下而上開發模式。當時我並沒有在意它們的區別——因為就是乙個徹頭徹尾的自下而上開發的程式設計師。
然而，隨著閱歷的積累，我慢慢的完全改變了我的立場。我認為，是敏捷開發和tdd讓我發生了這樣的變化。我非常強烈的感覺到，我想對每個人大聲說：在乙個敏捷開發團隊裡，自下而上開發是反模式的。
假設有乙個四個人的開發團隊，要完成乙個web應用中的下列這些任務。 1,建立控制層(controller) – 主訪問入口，請求對映表。 2,建立服務層(service) – 服務層，簡單業務邏輯。 3,資料庫查詢 – 複雜的資料庫查詢
按照自下而上的開發方法，兩個程式設計師將負責開發複雜的資料庫查詢功能。當這部分**可以使用後，另外兩個程式設計師將開始開發控制層和服務層。
這種開發模式的問題來自痛苦的整合過程。開發服務層的程式設計師寫**時很有可能無法遵守最初計畫時團隊制定的介面規範，這樣，複雜資料庫查詢開發的程式設計師就不得不修改他們的查詢介面。
// 資料庫介面和服務層要求不一致 query.execute(id);
// 資料庫層的實現是這樣的。 query.execute(id, typeid);
這是乙個很簡單的例子，但你可以想象乙個含有30多個小任務的story的情況，有更多的程式設計師參與，更複雜的業務，這時自下而上的模式就很麻煩了。
經過過去這些年的開發，我開始轉變成使用自上而下的開發模式。我的第一步開發動作是用假方法模擬出流程中需要的底層介面、服務實現。裡面沒有真正的邏輯，只實現了物件間互動需要的部分。在這個開發階段裡沒有測試，沒有tdd。因為裡面沒有邏輯。**非常簡單，很方便讓同伴進行**審查和計畫實現。
// 控制器方法 public result index(incomingrequest incomingrequest)
// 服務層方法 public queryresult invoke(int x, int y)
// 資料庫查詢方法 public queryresult execute(int id, int typeid)
這樣一來，任何乙個程式設計師都可以自由選擇開發任何一項任務。如果介面需要改變，則不會發生自下而上模式中的那種依賴另外一組程式設計師修改進度的情況。另外乙個好處是，從一開始，任何乙個功能點都是可以做使用者測試的。
自上而下的開發方便每一步都採用tdd開發。每一階段開發有各自的測試程式，這保證了各個物件間協作邏輯的正確，保證了業務邏輯實現的正確。之前我說過最初的底層模擬階段是沒有測試的。但這不意味著我們沒有對它們做tdd開發，我們的測試**最終會驅動對這些模擬功能的真實實現。頂層的業務邏輯的確定決定了底層的資料服務介面，如果在底層需要增加乙個新類，這很容易，它只是底層的實現，不會影響上層的業務流程。
這種自上而下的開發方法並不是乙個新事物，然而有很多人仍然沒有看到它的好處。我計畫在隨後幾個月裡對這種實用主義風格的tdd做進一步的討論。
資訊系統的軟體開發方法和軟體開發模型
我搞不清軟體開發方法和開發模型這兩個概念。書本上這兩部分都放在 軟體工程 這一章節裡，但是是分開介紹的，並沒有闡明二者之間的關係，比較割裂。我嘗試在網際網路上找找資料，但都非常少。這裡先把一些學習心得記錄下來，等待以後完善。一 鋪墊知識 系統生命週期分為四個階段。系統規劃 系統開發 系統運維 系統更...
軟體開發的效率
泰巖網路工作室 吳旻軟體開發專案不能如期完成似乎是普遍的事實，想想連微軟這種霸權級的公司開發乙個 vista 都要推遲了又推遲，其它公司的專案延期一些又算得了什麼呢？應該說，關於開發管理的模式很多，比如近些年流行的 rup xp什麼的，都對軟體開發中的問題提出了自己的理解。但是今天我在這裡想談的不是...
軟體開發的生涯
由於工作的關係,我接觸了web開發.首先我學的是asp,因為asp非常的直觀,非常的平易近人.後來,我學習了.net.乙個偶然的機會,我在大學三年級的時候就被一家公司聘用,並 偷偷的 從事軟體開發的事業.由於剛從學校出來,並且沒有畢業,所以,對這份工作非常的好奇.在加上在我們這個城市,2000多元的...