Planned Design的做法正好相反，並且吸收了其它工程學中的觀念。如果你打算做一間狗屋，你只需要找些木料並在心中有一個大略的構思就可以了。但是如果你想要建一棟摩天大樓，同樣的做法，恐怕蓋不到一半大樓就垮了。那麼你要先在一間像我太太在波士頓市區那樣的辦公室裡完成工程圖。她在設計圖中確定所有的細節，一部分使用數學分析，但是大部分都是使用建築規範。所謂的建築規範就是根據成功的經驗 (有些是基礎數學) 制定出的如何設計建築的法則。一旦設計完成，她所在的設計公司就將設計圖交給另一個公司按圖施工。
自從Planned design方法從七十年代出現，已經有很多人用過它了。在很多方面它比」code and fix」演進式設計要來的好。但是它也有一些缺點。第一個缺點是當你在編寫代碼時，你不可能把所有必須處理的問題都想清楚。所以將無可避免的遇到一些讓人對原先設計產生質疑的問題。可是如果設計師在完成工作之後就轉移到了其它項目，怎麼辦？程序員開始遷就設計來寫程序，於是軟件開始趨於混亂。就算找到了設計師，花時間整理設計，變更設計圖，然後修改程序代碼。但是必須面臨更短促的時間壓力來修改問題，又是混亂的開端。
XP因為許多原因而備受爭議，其中最關鍵的原因就是它主張演進式設計而不是planned design。正如我們知道的，演進式設計可能因為特定的設計策略(ad hoc design decisions)和照成軟件開發混亂而行不通。
理解這個爭議的關鍵在於軟件變更曲線(software change curve)。變更曲線說明，隨著項目的進行，變更所花費的成本呈現指數的增長。變更曲線按照不同的階段可以表示為：在分析階段花一塊錢所作的變更，放在編碼階段中則要花費數千元。諷刺的是大部分的工程仍然沒有分析過程而以非正式的方式進行著，但是這種成本上的指數關係還是存在著。變更曲線意味著演進式設計可能行不通，它同時也說明了為什麼planned design要小心翼翼的進行，因為在planned design中產生的任何錯誤同樣會導致指數增長。
XP的基礎是建立在將變更曲線拉平，使得演進式設計可行的假設上的。XP將變更曲線拉平而又為自己所用。就XP中一系列相互依賴的實踐來說：你不能僅僅使用那部分以平滑曲線為前提的XP利用實踐(exploiting practices)而放棄那些建造平滑曲線這個前提的XP啟動實踐(enabling practices) [譯注1]。這就是爭論的來源，因為很多人不了解這其間的關係。通常評論家們提出的批評，是基於自身對XP的體驗，但是他們割裂了XP中相互依賴的實踐，結果可想而知，於是對XP的印象也就這樣了。
軟件架構是指什麼呢？對我來說，架構是系統核心元素(elements)的意思，這部分是難以改變的。剩下的都必須建造在這基礎上。
那麼當你使用演進式設計時，架構又扮演著什麼樣的角色呢？XP的批評者再一次地聲稱XP忽視架構，因為XP的路線是盡快地開始寫程序，相信重構會解決所有設計上的問題。有趣地是，這些批評者說得沒錯，這有可能是XP的缺點。的確，最激進的XP專家——像Kent Beck，Ron Jeffries和Bob Martin——盡其所能地避免任何預先的架構性的設計。在你真的要用到數據庫之前，不要加入數據庫，先用文本文件來代替，在之後的迭代中通過重構加入數據庫。
Tag: [Programming], [Manage]
沒有留言:
張貼留言