TDD，軟件測試代碼可以代替文檔嗎？

TDD，軟件測試代碼可以代替文檔嗎？開發測試

曾經，我認為只要做好詳細設計工作，軟件編碼就成為一種體力活。在我印象中傳統軟件工程理論好像是這么說得：分析和設計是軟件生產過程中最重要的兩個階段，好的設計產生好的結果，壞的設計產生壞的結果，詳細設計文檔是軟件過程中最重要的部分，甚至比代碼還重要。國內某人的書中還提到，“只要有了詳細設計，哪怕原來的開發人員都離開了，換一批人照著詳細設計仍然能把軟件做完”。一提到詳細設計我的腦子里也已經出現了這樣的影子：長長的（或者厚厚的）文檔，詳細到每個函數，甚至是每個函數參數的名字都定義好了，用這樣的詳細設計指導代碼編寫應該是一件多么愜意的事情啊。我推崇這種事無巨細的詳細設計，認為只要是設計好就能夠適應變化，并把軟件項目的失敗歸咎與設計人員的知識、能力或經驗不足。這種想法持續了很長時間，直到我有了實際軟件項目的經驗并開始單獨做設計為止。

　　促使我思想轉變的原因就是兩個字：變化。我原來也知道變化對設計的影響，但是還是低估了變化對設計帶來的沖擊?，F實中的詳細設計只是一個看上去很美的東西，開始編寫代碼一個月后的詳細設計就基本上不能指導代碼編寫了，甚至變成和實際代碼完全兩回事的東西，成了一堆廢紙，原因還是那兩個字：變化。是的，變化，在某個時間已經很縝密的設計，在下個時間就會變得漏洞百出，因為計劃趕不上變化，通常情況下，詳細設計文檔從其完成的那一刻起就開始散發出“腐敗”的味道。只有沒有任何軟件開發經驗的人才會天真地認為一次做好完備的詳細設計，然后就可以在其指導下完成軟件開發，最終得到產品。

　　在傳統的軟件過程中，面對逐漸散發出“腐敗”味道的設計文檔，通常有兩種對策，一種是安排專職的文檔開發人員，每次在代碼中修改設計都及時更新到設計文檔中，以保持文檔的“新鮮”。其實這種方法也只是一種看上去很美的東西，且不說多數項目組都不會有多余的人手專職做文檔開發（有哪個項目組敢在項目還在進行中就說自己的人手足夠了？），就算有這樣一個文檔開發人員，那么是否每次設計上的小修改都會通知到他（她）呢？顯然不會，他（她）必須Review 每一個開發人員的代碼，并與大家隨時溝通，發現與原始設計不一致的修改，這樣會累死人的。那么是否可以由開發人員自己負責維護與自己工作相關的那部分文檔呢？試想一下，當轟轟烈烈地代碼編寫開始后，或者頭頂著產品交付倒計時牌，開發人員是否還有“閑情逸致”時不時停下正在Coding的手去重新修改一下設計文檔呢？另一種對策是任由設計文檔慢慢“腐敗”，把主要力量集中在代碼上，畢竟最終交付產品依靠代碼而不是設計文檔。這種情況下原來花費大量時間完成設計文檔純粹是浪費時間，哪怕是對自己人也沒有絲毫用處，如果我是這個項目組中補充進來的新人，看到這樣的文檔和那樣的代碼，可能會得精神分裂癥。

原文轉自：http://www.anti-gravitydesign.com