2009年9月14日 星期一

Y03 與理論型同事對設計作法的討論

E主管是之前提到過的理論型同事,在技術部門裡可以說就只有我與他有把握能夠將分析與設計全部轉化為可以實現的作法。最近我們在參考RUP想要定義出一套可實現的OOAD作法,但是為了用什麼而做的議題有了一場“熱烈”的討論。

他的想法主要是參考大師們的說法,因為那些都是根據有經驗者的智慧結晶而定義出來的;不管是分析設計時應該做的步驟、使用的工具與應有的產出等等,都鉅細靡遺地遵循書上的方式。我則根據部落格上的心得,先把使用UML工具會作出的產出定義為程式碼,再逐一將分析與設計的想法衍伸在程式碼裡。

我們的分歧點在於“不應該用程式碼作設計”。E主管的感覺是直接產出程式碼而不先模組化就會回到以前設計不良的窠臼,同時也提到以前在學校若先寫出程式碼會被教授責備根本不作設計的事,當然也聽不進去我希望解決之前使用UML工具進度緩慢、達到分析與設計模組追溯的目標,因為他暫時落入“馬上有程式碼絕對作不出好設計”的想法中。

爭辯了一陣子雙方僵持不下,最後我只好換一種方式說明。先解釋說,現在有一個功能與Rose完全一樣的UML工具,採用的OOAD作法也與RUP完全一樣,然而那個工具的存檔格式剛好與Java程式碼一模一樣。今天我們的OOAD作法每一步應該做什麼就同樣地在“程式碼”會有什麼,這樣一來無論分析或是設計都能夠採用我計畫的工具作出全部的管理與追溯;分析的“程式碼”則在build產出時不處理而僅作為模組化的分途。

E主管認同了我的說法,但有個前提是:要先明確定義好OOAD的詳細步驟後,才能逐一定義與我想法之間的對應。前面的討論對於modeling來說都只是產出的物,先要有應做之事與其順序後再去談應有之物;這也正是做事的基本前提。

沒有留言:

張貼留言