Design和Coding其實是兩回事,不過在程式開發這個領域裡,常常會被混在一起,而且很多人喜歡一邊Design一邊Coding,我個人則是喜歡先Design再Coding,至於Design要做到哪個程度才開始Coding,我想這恐怕因project而異了。雖然建築和軟體無法相提並論,但某種程度上,我還是喜歡拿建築來類比軟體的開發,一個建築都會有一份設計圖,然後這份設計圖再交給建築工人施工,當然設計偶而會變更(好吧!在台灣常會聽到建築工人自行變更設計的傳聞),但說真的,如果是結構性的設計變更,越是晚期,變更的成本會非常大,例如都已經灌漿了,卻說要加鋼骨或是減鋼骨,或是要將部分的RC結構換成鋼骨結構,這樣的變更成本會非常大,但如果是管線的變更,某種程度上成本可以比較小(不把管線藏在牆裡或天花板中,比較醜的作法),就像是最近學校科研大樓11-16F的空調改善工程,那邊打個洞這邊打個洞,然後水冷管直接加在走廊上,反正只要會冷(功能性需求),管它好不好看(非功能性需求)。

  我這個人有點程式上的潔癖(生活上不邋遢但不到潔癖的程度),所以Design通常會做到一定的細節後才開始Coding,不過最近很流行的Scrum或eXtreme Programming倒是喜歡別過度設計(Over Design),先把功能完成,然後再用Refactoring的方式讓設計變好,心理上某種程度會抗拒。這幾年很喜歡看《全能住宅改造王》,改造前是A,改造後根本就是Z,完全不是A'或是B了,常常會納悶,這樣的改造以軟體來類比算是Refactoring還是Rewriting?節目中的建築師把外牆、天花板和隔間都打掉,有時候連屋頂都拆了,甚至還要補強被侵蝕或腐爛的結構,真不知道到底留下什麼東西能稱作這是『一間被改造的房屋』?勉強說來,改造前是一棟房屋,改造後是另一棟房屋,以軟體來說(我的看法),那樣的改造根本就只留下軟體架構(Software Architecture),其他的肉(程式)都被打掉重寫了,有時候連軟體架構都拆了。

  這也是我心理上會抗拒不做某種程度Design就Coding的理由,要我寫出那種A的程式(節目中改造前的A是滿足功能性需求的房子,但不符合屋主的非功能性需求),然後用Refactoring的方式改到Z,我寧可一開始多花點時間,把Design做到O,Coding做到R,隨著需求變更,用Refactoring的方式慢慢地改到Z,當然有人會質疑,如果設計都已經到O了,變更的成本會不會像把RC結構換成鋼骨結構那樣更大?關於這點我還沒有明確的答案,但內心深處還是喜歡整齊有條理的Design,而且相信當要套用Refactoring書中的方法時,從『混沌』中修改是比較痛苦的。說真的,念博班後很少寫『大量的』程式了,即便是三年帶WiMAX計畫,我也都只是幫學弟妹微幅(500行以內)的新增或修改,幾年累積下來恐怕還沒有我幫念醫工所的朋友所寫的RFID定位系統(大約4000行左右)多,可能是案子不大,所以在初版的設計後,程式就差不多寫到R了,後面細部的修改,也都沒有遇到架構上大幅的改變,然後靠Refactoring方式慢慢地改到Z,真的沒遇過從A到Z的案例。

  我還記得WiMAX計畫第二年的某天,一位電子系的某子計畫PM問我:『念資工系的是不是程式都很強?很愛寫程式?』我苦笑,我不覺得自己程式很強,而且我不是那麼愛寫程式,應該更精確地說,我不是那麼愛Coding,但我喜歡Design (畫設計圖),平時看到有趣的Topic,會把Visio打開,然後就開始畫設計圖,不過很少會付之實現,這樣的設計圖還蠻多張的。三年的WiMAX計畫加上今年的DVB-H計畫,我都只負責Design (WiMAX總計畫的部分,Class Diagram足足8張A4),程式大多是學弟妹寫的,我只對有趣的、有挑戰性的或是關鍵的部分才會親自動手,就像是《全能住宅改造王》節目中的建築師一樣,拿著設計圖到現場監工(盯學弟妹寫程式,寫不好或不漂亮就動嘴巴),但有些關鍵的家具或是設備,節目中就會看到建築師自己動手了。

  OS:不過進入業界後,從基礎工程師開始,主要工作內容還是Coding,要Design還得看有沒有人(主管)欣賞(看懂)軟體的Design了...

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()