test-driven development 測試驅動開發
如果我們遵守了以下的規則進行開發，那麼這就是測試驅動開發：
在編寫任何產品**之前先寫乙個會執行失敗的單元測試。
編寫乙個單元測試，使其剛好能夠執行失敗或者編譯失敗。
編寫的產品**應該剛好能夠使失敗的單元測試執行通過。
如果按照這種開發方式進行開發，那麼我們將處於乙個非常短的開發周期中。這樣做的好處是，首先程式中的每乙個單獨的功能模組都經過測試來驗證它的功能。這些測試將作為未來開發的乙個強有力的後盾，它保證我們的開發沒有破壞已有的功能。其次，測試先行的作法將使我們以一種呼叫者的角度來審視我們的程式。我們將關注模組之間的介面設計，這使得我們設計的程式是可以被方便地呼叫的。此外，先寫測試的方法要求我們設計的程式是可測試的。對於軟體設計來說，可呼叫和可測試是十分重要的，為了達到這個目的，軟體必須要解耦。測試先行的另乙個重要的作用是，這些測試可以作為一種文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，測試用例將告訴你如何去做。這樣的文件是可編譯的可執行的。它永遠是最新的，而且不會說謊。
test isolation 測試促使模組之間隔離
測試先行將使軟體被更好的解耦，通過介面和mock物件來解除模組與外界之間的依賴。
serendipitous decoupling 意外獲得的解耦合
單元測試將促使我們將模組隔離，迫使我們從整個程式的結構角度來進行解耦。測試先行可以改善我們的設計。
acceptance tests 驗收測試
儘管單元測試可以驗證系統中的各個小部分可以如預期的執行，但是它無法驗證整個系統的行為和預期相符。單元測試就好像是白盒測試，來驗證系統的每個個體。驗收測試則是黑盒測試來驗證客戶的需求是否被滿足。
驗收測試是乙個功能的最終文件。一旦業務人員編寫了驗收測試來驗證該功能是正確的，那麼開發人員將可以通過這些驗收測試更真實地理解這些功能。正如同單元測試是系統內部模組的可編譯和可執行的文件，驗收測試是整個系統功能的可編譯和可執行的文件。簡而言之，驗收測試是真正的需求文件。
此外，編寫驗收測試將對整個系統架構有著深遠的影響。為了使整個系統可測試，它必須在更高的層次上解耦。
serendipitous architecture 意外獲得的架構
敏捷軟體開發
敏捷軟體開發 英語 agile software development 又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作...
敏捷軟體開發
我們知道，傳統的開發模式已經不能不適用於現在情況，原因有很多 需求經常發生變化，軟硬體更新速度很快等，這些原因都使得傳統不管是 瀑布模型 還是 增量 不管是 快速原型 還是 螺旋 模型，這些軟體開發的模型，不在實用了。所以，在2001年，敏捷宣言提出，標誌著敏捷開發模型初步形成。那麼敏捷開發和傳統開...
敏捷軟體開發
隨著軟體規模的不斷擴大 軟體涉及的領域越來越廣，客戶對軟體要求也越來複雜，這一點的最直接的體現就是軟體需求的變化越來越頻繁。敏捷軟體開發正是為了應對這一問題而誕生的軟體工程學方法。它以適應性的過程代替傳統的 型的過程代替傳統的 性的過程，在很大程度上滿足了現代商業軟體業務複雜 需求多變 時間要求緊迫...