業餘大叔程式心得筆記#9：程式設計要看多遠、看多近？／葉光釗
寫程式跟一般日常生活一樣，要做各種各樣的決定；但這些決定跟選陽春麵、還是滷肉飯之類的，有一個很大的不同：就是不管做對做錯，都很難走回頭路，而且魔鬼往往藏在細節裡。
看多遠、看多近？
這裡談的遠近，當然不是指眼睛到螢幕的距離。
寫程式跟一般日常生活一樣，要做各種各樣的決定；但這些決定跟選陽春麵、還是滷肉飯之類的，有一個很大的不同：就是不管做對做錯，都很難走回頭路。
所以越資深的人，多半對設計的選擇會越來越謹慎、越來越遲疑，每一個關卡都好像是要賭上人生一樣。
在前東家所受的教訓中，幾乎所有的資深長官都說：「你要看的是三五年之後的技術觀點」。老實說，有一段時間我自己也是深信不疑的；不過到了現今，恐怕沒有多少人或企業有自信可以看得這麼長遠了。
技術的變化速度實在太快，而程式交付的時間越來越短；迫於現實，一些技術參數能決心定下來，就已經不錯了。
兩難的是，很多東西一旦定了，就等於水潑出去了；而且還不是甚麼高深的演算法之類的決定。我周遭還有很多早期因為需求簡單，所以使用ANSI編碼（encoding）的程式；到了現在想改成Unicode通用編碼，如果不是自己碰到，很難瞭解有多難改。
另一個典型的基本設計問題，是要繼續用32位元程式，還是轉成64位元。不要看那些大公司推64-bit程式，不過一個版本的功夫；看來稀鬆平常，殊不知背後要花上多少人力、資源、還有辛酸血淚。
看來又是個無解的難題：看得近了，後面要還債的機會極大；看得遠，也是要看有沒有賭對。萬一賭錯了，一樣下場悽慘。
我的心得是，人家說 「盡量不要欠技術債」，我倒是覺得欠債恐怕迴避不了；唯一能做的，是認清這個事實，然後盡量攢一些本錢，早點想想甚麼時候還、要怎麼還。
魔鬼藏在細節裡
這句話四處可見，字面的意思也不難理解；不過最近的一個經驗教訓，讓我對這句話有著接近刻骨銘心般的強烈理解。
在電影或是電視劇中，常常看到醫學手術的情節；主刀醫生氣定神閒地將最重要的部分完成，接下來就有其他團隊成員接手，將剩下的部分收拾完畢。
此時，鏡頭通常會停留在主治醫師辛苦之後的滿足表情，但幾乎看不到團隊收拾善後的樣子。這個時候我都會想，如果寫程式也能像這樣，該有多好啊。
我只要把最重要的主架構做完，其他助手就會今來把細節處理好，案子完美落幕，這應該是每個人的夢想吧？。
現實當然是與夢想差一大截，而且通常在主架構完成之後，才是惡夢的開始。
最近的經驗就是如此：一開始的規劃十分順利，而且透過簡單的幾個原型，也證實了可行性很高；心想應該可以手到擒來，所以一開始心情還蠻愉快的。
中間的實作也沒甚麼顛簸，主要的演算法和資料結構也跟預期一樣發生效果，只剩下幾個細節修正完畢，就可以結案了，大概就是幾天的功夫吧。
沒想到，要命的就是這幾個「細節」。
一路修改下去，好像踏入了一個泥沼。由於都不是大問題、也跟主架構無關，所以一開始並沒有特別警覺，但是越修越像在打地鼠。為了要解決這隻臭蟲，必須去改另外兩個地方；而為了讓那兩個地方能運作，又要去改其他地方。
到了後來，專案的大部份原始碼都改到了，還是搞不定；感覺就像泳賽的終點明明就在眼前，卻始終就是游不到，甚至還有快淹死的感覺。
我的心得是，不管專案規模大小，永遠要有打持久戰的準備；一步一步紮實往前推進，不奢想一步到位，才有看到隧道彼端亮光的希望。