促使我思想轉變的原因就是兩個字：變化。我原來也知道變化對設計的影響，但是還是低估了變化對設計帶來的沖擊�，F實中的詳細設計只是一個看上去很美的東西，開始編寫代碼一個月后的詳細設計就基本上不能指導代碼編寫了，甚至變成和實際代碼完全兩回事的東西，成了一堆廢紙，原因還是那兩個字：變化。是的，變化，在某個時間已經很縝密的設計，在下個時間就會變得漏洞百出，因為計劃趕不上變化，通常情況下，詳細設計文檔從其完成的那一刻起就開始散發出“腐敗”的味道。只有沒有任何軟件開發經驗的人才會天真地認為一次做好完備的詳細設計，然后就可以在其指導下完成軟件開發，最終得到產品。
在傳統的軟件過程中，面對逐漸散發出“腐敗”味道的設計文檔，通常有兩種對策，一種是安排專職的文檔開發人員，每次在代碼中修改設計都及時更新到設計文檔中，以保持文檔的“新鮮”。其實這種方法也只是一種看上去很美的東西，且不說多數項目組都不會有多余的人手專職做文檔開發（有哪個項目組敢在項目還在進行中就說自己的人手足夠了？），就算有這樣一個文檔開發人員，那么是否每次設計上的小修改都會通知到他（她）呢？顯然不會，他（她）必須Review 每一個開發人員的代碼，并與大家隨時溝通，發現與原始設計不一致的修改，這樣會累死人的。那么是否可以由開發人員自己負責維護與自己工作相關的那部分文檔呢？試想一下，當轟轟烈烈地代碼編寫開始后，或者頭頂著產品交付倒計時牌，開發人員是否還有“閑情逸致”時不時停下正在Coding的手去重新修改一下設計文檔呢？另一種對策是任由設計文檔慢慢“腐敗”，把主要力量集中在代碼上，畢竟最終交付產品依靠代碼而不是設計文檔。這種情況下原來花費大量時間完成設計文檔純粹是浪費時間，哪怕是對自己人也沒有絲毫用處，如果我是這個項目組中補充進來的新人，看到這樣的文檔和那樣的代碼，可能會得精神分裂癥。
文章來源于領測軟件測試網 http://www.kjueaiud.com/