程式設計師在專案中要先照顧好自己(2010/1/10改版)

一位專業的程式開發人員，每天接觸的技術與技能很多，使用的API、Framework各不相同。做為技術主管該做的叮嚀與規定似乎多如牛毛，不勝枚舉。假設Java有了程式規範，Ajax時代來臨了，是不是Javascript也應該有規範?程式要記錄Log，到底該記多細?可以規定程式碼要加註解，可是有的人只在顯而易見處加註解，洋洋灑灑，只是讓程式版面更亂。有的高手懂得只在關鍵處加上恰到好處的註解，雖然看起來註解很少，但程式碼卻更好讀。另一個問題是Refactoring，重構是好技術，但是實際上執行起來會是破壞多還是建設多？不懂自己怎麼能當那麼多年的技術主管，這麼多問題還是無解，想來真是汗顏。

最近在這個問題上有了新的體會，還沒充分地驗證正不正確，先在此分享：

對於技術人員，第一步該要求的是要能照顧自己。基於為自己考慮(而對其他人無害)的立場做好該做的事。而不用先要求主動對同儕與客戶的立場的考慮太多。假設能照顧好自己就有80分，為團隊著想是90分，為客戶著想是100分。第一個目標就是要求80分，達到80分以前其他的要求，多少有些好高騖遠，不切實際。

文字上這麼寫好像容易誤會，舉例說明一下。

例如Exception處理。一個基本的設計原則是:

凡是與外部系統介接的程式碼(例如email寄送、FTP或是HTTP client、Web Service呼叫等)，設計上都要假設介接是不穩定的。

客戶環境的網路設定可能改變、或者帳號密碼改變、斷線、移機等等。問題發生時，無論客戶找的窗口是誰，最後排除問題的工作通常還是落到原開發人員自己頭上。因此，即使這個案子經費有限，我們只提供陽春的功能，SA也沒做要求......但是問題是，保固維護還是要做啊！

你接到叫修，跟客戶問清楚問題、請對方網管開放遠端連線、連進去測試等等。總算順利找出原因是mail server的IP換了，卻已經花費了四小時了。雖然問題出在客戶自己，但也是一樣花你的時間。通常主管也不可能太感謝你找出客戶問題，而比較關心目前專案的進度，也許還要你加班趕回這四個小時。

所以，即使專案經費有限，能省的是功能規格，但保固維護還是一定要做。越拮据、越賠錢的案子，更是要降低後續保固成本。

我們開發人員應該為自己著想，懂得用技術幫自己的忙，開發期就要設想這些問題。Java的每一個checked exception都是在提醒我們想這件事。我們最常做的是在try-catch中把exception訊息丟到log檔以供日後查閱。但是這麼做不是害到自己嗎?客戶起初只會覺得奇怪為甚麼系統沒異狀而她的作業卻失敗。也許初期會先以為是自己操作的問題。試了一兩天了，才認定是系統問題。等到電話打來叫修時已經很急、情緒也不太好了。客服窗口會把叫修案件pass給你，跟你說客戶非常急，你手上的工作再趕也要優先處理這個問題。而你需要連進去查log檔才能猜出問題所在。如果log量很大，問題可能要找很久。

處理exception的不同方法會造成不同結果。仔細看這個try-catch的try block，一定能攔截出是不是連線等網路類的問題的exception。如果希望發生網路環境問題時，客戶一開始根本就不要打這通電話，而知道該找自己的網管，就要在訊息上提示他找網管人員，並且把網管人員需要知道的資訊(而不是開發人員才懂的stacktrace)準備好在畫面上。如果是期待客戶先聯絡我們，由我們來判斷，那麼最好讓客戶寄來的第一封email就把我們想知道的訊息都完整提供，省去我們再聯繫詢問的功夫，也讓我們能快速判斷原因。所以要注意訊息不該用alert而應該呈現在網頁上，以方便使用者copy paste進email。

如果該客戶沒有開放遠端連線，就應該考慮做個網頁來查log資訊。（當然Log顯示在網頁上，有資訊安全的問題，不過資安不是本文重點。）如果log檔要靠承辦人員手動用email寄送，最好將log檔切成小塊，以免客戶因為檔案太大而寄不出來。以時間做log檔名，客戶才知道該寄哪一個檔。Log該怎麼紀錄，以及該在什麼場合紀錄，也許有很多技巧與原則，但是最重要的是要記得，這是給自己用的功能。它很現實地、血淋淋地反映每個開發人員的能力與態度的差異。

這些都沒有一成不變的標準答案，不同情景、要達成不同效果，就會有不同的做法。不變的是，log以及exception handling都是舉手之勞，而且成果是自己在享受。做了錯誤的設計，或是甚至忽視這些問題，只是會莫名其妙地覺得這個客戶很討厭，系統問題多又很難維護。

不用期待這些處理方法會預先寫在功能規格中。萬一有的話，恭喜貴單位有很棒的SA作業。不然的話，只能自立自強，要體諒SA光是追逐客戶商業邏輯已經夠他努力了。換個角度看，既然是自己用的功能，當然能自己親自設計是最好。(才能用最體諒自己的立場來設計呀!)

有時處理方式會牽涉到畫面設計，不在自己的權限內，就應該主動找SA討論該如何設計。不妨想像成，自己才是這個系統最重要的使用者。也許有的專案功能規格達成就好，不用太豪華，但是所有的專案都絕對要好維護。讓自己在未來的專案能有好表現，而不被這個舊案子的收尾與維護工作拖累。

所以，我們不用等主管安排時間Refactor或是寫log，通常光是為自己著想就值得去做。未來其他人交接程式碼順不順利反而是其次的考慮。只是別人看不懂的程式碼，遲早自己也會看不懂。為了自己，該翻還是要翻。

成熟度先發展到照顧得好自己，才能有效考慮團隊同儕的立場，如交接問題、長期維護與續案問題等等。成熟度還沒到，即使規定每支程式都做文件，每行指令都加註解，也可能只是虛功。另一方面，如果一個開發人員沒辦法把系統弄得自己很好維護，他就不可能有效設想系統如何對使用者user-friendly。要談user-friendliness之前，最起碼的先決條件是能做到developer-friendliness。如果設計來提昇自己的工作效率都辦不到，怎麼可能去設計客戶的流程，去設計一個陌生的領域呢？何況從前面的例子來看，廠商能快速有效地排除問題，這本身也是客戶的一大福音，算是雙贏。

所以，一切從照顧自己的需要努力起。