改程式的掙扎

在工作上,如果遇到前人所留下的難看程式,到底該怎麼辦?

所謂的難看程式,指的是會動,能正常運作,但是架構混亂、難以閱讀,甚至還很容易隱藏潛在的危機。本來嘛,這種程式不動它也就是了,可是偏偏又要在上面提供新的功能,這時候,身為接手人員,到底應該怎麼做呢?是大破大立,還是在危樓上持續建造呢?

目前在資策會工作這兩年,總共遇過兩次(其實也才遇過兩年,也就是一年一次囉)。這兩次,我的作法都是~砍掉重練。第一年,因為是科專計畫,只要呈現給長官和經濟部的官員看,再加上整個計畫的人力不過三個,在達成一致決議後,花了幾個月的時間將東西完工。雖然做的沒有很出色,但穩定性已經大幅提昇(當然是跟之前的東西比),而且也在過程中學到了不少東西(感謝當初的另外兩位同仁)。去年的計畫,我也做了同樣的決定,但這次不一樣了...這次不但是科專的呈現,還有廠商的產品要交付,互通性測試要通過,無止盡的「死線」...而且整天還要面對測試人員的壓力。對測試人員來說,他們不會看到程式碼,他們只在乎外在的功能,他們在意功能是否完善,特殊的CASE是否能安然度過,新的功能運作如何,但卻不會在意程式的維護性如何、還有程式內有多少的隱藏危機...

打掉重建,我自認將程式改的更容易閱讀,也更容易維護或是加上新功能,但是這段改程式的陣痛期,卻是測試人員所無法瞭解的(當然了,他們也有自己的時程壓力)。反而,原先會動的功能,可能因為程式重建過程中一些粗心大意的疏漏(還不少),反而會無法運作。他們只會無法理解的問說:「為什麼?為什麼要這樣改,這樣怎麼測試?」。還好,因為另外一個團對正好再進行大規模的更動,我獲得喘息的機會...今天,大部分的問題已經解決了...甚下就是開始進行新功能的加添、原有 BUG 的修正,還有客制化的動作。但我一直在問我自己,如果時間往前推幾個月,我會做出這樣的決定嗎?

幾個禮拜以前,我到簽約廠商那裡,進行程式碼的講解。講解的程式碼,是舊的那一份。坦白說,我講得很膽戰心驚。我一向不害怕報告,但是我害怕報告自己都無法理解的東西。原有的程式碼,其實架構設計的很...我很擔心廠商問我架構的問題,以及這樣設計的緣由,所以我隨便找了一個理由就帶過去了,好險他們似乎只要東西會動就好(感覺他們根本沒在研究那一塊程式,看來他們的產品出貨後,有可能會被一堆客戶罵吧)交那樣的程式過去,我很羞愧,而且因為接手了,還要掛我的名字...

再來一次,我會怎麼選擇?在難看的架構,也不是不能維護、更新,只要能動(不要太快陣亡),撐過這段期間,之後再交給下一個可憐的學弟接手就好了。這樣也是一種策略...很吸引人,畢竟我只要東補西補,不要翻修,勉強過去即可。測試人員也不會圍在我的周圍催促(畢竟大部分的東西之前都測過了,應該說,東補西補過了)之後,想辦法脫手...我還可以專心研究自己想研究的東西...

到底該怎麼選擇呢?

「徘徊在利與義的邊緣,天、你怎麼還不說話? 」(火鳳燎原)

用這句話來說好像太誇張了,不過我真的陷入了思考...

聽說前幾年,我的一位離職同事跟我幹過同樣的事,不過還更嚴重,將整個 stacking protocol 翻掉重新設計(這樣說應該就知道是誰了吧),當然他的工作比我還要複雜,他的時間也比我還多的感覺(除了交付廠商外沒什麼一堆外加的任務),「昔人日已遠,典範在夙昔」,我又陷入思考了...

以程式設計師來說,我的經驗很淺,設計的架構也不怎麼樣(所以很佩服一些同事的經驗),但起碼,我希望我能做到逐漸進步,將自己的程式碼越修越穩定。這是第一次,我想要當上位決策者,給予開發人員審視程式碼的時間,擋掉一些多餘額外的負擔跟壓力...又或是,乾脆離開這種環境,回到學術界呢...

Next time, I think I will make the same decision~

留言

這個網誌中的熱門文章

如何將Linux打造成OpenFlow Switch:Openvswitch

如何利用 Wireshark 來監聽 IEEE 802.11 的管理封包

我弟家的新居感恩禮拜分享:善頌善禱