由寫出程式到寫出一個好的程式

很多人都想要學會怎樣寫一個好的程式，想要學怎樣快速地寫出正確功能的程式，但也都發現其實有一定的困難度，不見得因為規則很多、推理很困難、或是步驟很繁瑣，寫程式這件事情和很多你學過的學科比起來應該要簡單很多，可是大家常常學不好，常常花很多時間和一堆程式的錯誤周旋，花掉的時間好像沒有等比例變成經驗，常常覺得都花那麼多時間整理了，怎麼下次寫程式時問題還是那麼多？

寫程式的時候，不是就用最簡潔的方法完成所要求的工作嗎？為什麼把問題拆開來以後，每一部分好像都可以很快達成目標，但是合起來就不太正確，有什麼地方還不夠仔細嗎？

簡單地分析這樣的狀況，也許可以歸咎為撰寫程式的數量不夠多、時間不夠久，你評斷什麼是一個好的程式、什麼是比較安全不容易出錯的程式寫法、什麼是有潛力能夠應付不同需求的程式的規範還在一步一步建立當中，投入更多的時間就好了，真的是嗎？會不會是因為你還沒有決定把寫程式的能力當作你吃飯的傢伙，還是你還沒有吃到自己或是別人寫的爛程式的苦頭？

打一個比喻來說：系館前面到 便利商店 最短的距離當然是橫跨那條馬路，唯一檔在你和 全家/OK 之間的只是那些死板笨笨的 "交通安全法規" 而已，也許還有學校百分之百反效果的教條式宣導，遵守這個交通規則好像沒有什麼直接的好處，搞不好還變成同學茶餘飯後的笑話，反倒是橫跨過去有一種衝撞體制的感覺，覺得好像賺到了一點時間。(真的嗎？會不會是你用風險換來的？)

話說撰寫一個 "好" 程式就有一點像遵守交通規則，是一種紀律，是一種習慣，需要注意一些看起來麻煩、遵守起來要付出不少代價又得不到直接好處的規則，比如說不要使用全域變數，儘可能使用函式切割程式，抽象化程式各個部份的功能，以函式參數調整函式的功能，變數和函式的名稱要妥善設計 (該叫做 averageBalance 的變數絕對不叫做 x)，變數不重複使用，適當運用檔案或是語法劃分模組，別的物件內的資料不要直接存取等等，如果看完下面兩段的理由以後你還是沒有辦法抗拒穿越馬路這種 "方便" 誘惑的話，要學會寫一個好程式的阻力可能就來自你自己，而且力量相當強大。

不管是寫程式還是在馬路上行走，常常需要建立良好的習慣，一旦你習慣製作有危險性的程式，你就常常會被各種程式的錯誤圍繞著，就像習慣穿越馬路一樣，也許你很有把握每一次一定會看清楚過往的車輛、評斷沒有危險才穿越它，但是習慣穿越馬路以後，會不會有一天早上你因為趕著上課、因為手上拿著早餐、因為穿著藍白拖、因為手機響了、因為作業沒有寫完、因為下著不大不小的雨、還剛好遇見社團的正妹和你打招呼，因為...(好多事情都可能在那一瞬間同時發生)，所以你就一不小心誤判了；有沒有這樣的經驗：好多人一起穿越馬路，看到一輛車子過來，你以為大家都一起走的話車子應該會讓，沒想到其他的人都停下來了，只有你自己當勇士挑戰那台車子？

幾乎所有車禍的發生幾乎都是意外，所謂意外就是你想都想不到，就是大家都覺得很OK可是卻不該發生的狀況，沒有人願意和車子過不去，也沒有司機故意和行人過不去，人走的和車子走的分隔開來，是一種確保安全的措施，如果你開過車，甚至在很疲倦的時候開過車 (這段濱海公路是由頭城過來的最末端，甚至是由花東過來的最末端)，你就可以體會這種交通規則的好處，是真的可以避免意外的方法，是強制規範出來的協定，也許覺得是一種限制，可是也是一種對自己和對別人的尊重，不要去挑戰它，不要去壓縮那個辛苦建立出來的安全距離，換個角度想馬路不讓行人橫跨過去，好像剝奪行人的權利，可是人行道、操場、海景步道也是不讓車輛走的啊，開車的時候也是不能手足舞蹈的啊，想到大家都有犧牲一點，也許你才能高高興興地遵來遵循這個協定，也才能享受 "安步當車" 的樂趣。

老實說我也常有想穿越這條馬路的衝動，去年暑假八斗子山上巨石滾下來封路的時候我還試過大搖大擺走在馬路中間，其實感覺還蠻好的，不過平常還是要忍住遵循這個安全的人車協定.........硬拗回來講寫程式，我寫程式時可是會遵循很多規範的，也常常能夠享受按步就般順利完成的樂趣。

不好意思，真的不知道是要講程式設計還是講交通安全！不過也許你不曾這樣想過，真的希望你可以在想要穿越馬路的時候有另外一種風險的思考。曾經聽別人比較過印度工程師和中國工程師寫的程式，兩種程式給人的第一印象是印度工程師寫的比較長、選擇的方法中規中矩、遵守很多無形或是有形的軟體工程規範；強國的工程師寫的比較簡捷、有快速的方法只要達成這回的目標一定會採用、沒有直接用途的就刪掉，可是這樣的程式幾乎都是比較難看懂，比較難維護與測試，比較沒有辦法修改來適應使用者不斷調整的需求，你自己寫程式的目標會是哪一種？