改程式的掙扎

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

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

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

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

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

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

到底該怎麼選擇呢？

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

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

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

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

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