業餘大叔程式心得筆記#9:程式設計要看多遠、看多近?/葉光釗

寫程式跟一般日常生活一樣,要做各種各樣的決定;但這些決定跟選陽春麵、還是滷肉飯之類的,有一個很大的不同:就是不管做對做錯,都很難走回頭路,而且魔鬼往往藏在細節裡。

看多遠、看多近?

這裡談的遠近,當然不是指眼睛到螢幕的距離。

寫程式跟一般日常生活一樣,要做各種各樣的決定;但這些決定跟選陽春麵、還是滷肉飯之類的,有一個很大的不同:就是不管做對做錯,都很難走回頭路。

所以越資深的人,多半對設計的選擇會越來越謹慎、越來越遲疑,每一個關卡都好像是要賭上人生一樣。

在前東家所受的教訓中,幾乎所有的資深長官都說:「你要看的是三五年之後的技術觀點」。老實說,有一段時間我自己也是深信不疑的;不過到了現今,恐怕沒有多少人或企業有自信可以看得這麼長遠了。

技術的變化速度實在太快,而程式交付的時間越來越短;迫於現實,一些技術參數能決心定下來,就已經不錯了。

兩難的是,很多東西一旦定了,就等於水潑出去了;而且還不是甚麼高深的演算法之類的決定。我周遭還有很多早期因為需求簡單,所以使用ANSI編碼(encoding)的程式;到了現在想改成Unicode通用編碼,如果不是自己碰到,很難瞭解有多難改。

另一個典型的基本設計問題,是要繼續用32位元程式,還是轉成64位元。不要看那些大公司推64-bit程式,不過一個版本的功夫;看來稀鬆平常,殊不知背後要花上多少人力、資源、還有辛酸血淚。

看來又是個無解的難題:看得近了,後面要還債的機會極大;看得遠,也是要看有沒有賭對。萬一賭錯了,一樣下場悽慘。

我的心得是,人家說 「盡量不要欠技術債」,我倒是覺得欠債恐怕迴避不了;唯一能做的,是認清這個事實,然後盡量攢一些本錢,早點想想甚麼時候還、要怎麼還。

魔鬼藏在細節裡

這句話四處可見,字面的意思也不難理解;不過最近的一個經驗教訓,讓我對這句話有著接近刻骨銘心般的強烈理解。

在電影或是電視劇中,常常看到醫學手術的情節;主刀醫生氣定神閒地將最重要的部分完成,接下來就有其他團隊成員接手,將剩下的部分收拾完畢。

此時,鏡頭通常會停留在主治醫師辛苦之後的滿足表情,但幾乎看不到團隊收拾善後的樣子。這個時候我都會想,如果寫程式也能像這樣,該有多好啊。

我只要把最重要的主架構做完,其他助手就會今來把細節處理好,案子完美落幕,這應該是每個人的夢想吧?。

現實當然是與夢想差一大截,而且通常在主架構完成之後,才是惡夢的開始。

最近的經驗就是如此:一開始的規劃十分順利,而且透過簡單的幾個原型,也證實了可行性很高;心想應該可以手到擒來,所以一開始心情還蠻愉快的。

中間的實作也沒甚麼顛簸,主要的演算法和資料結構也跟預期一樣發生效果,只剩下幾個細節修正完畢,就可以結案了,大概就是幾天的功夫吧。

沒想到,要命的就是這幾個「細節」。

一路修改下去,好像踏入了一個泥沼。由於都不是大問題、也跟主架構無關,所以一開始並沒有特別警覺,但是越修越像在打地鼠。為了要解決這隻臭蟲,必須去改另外兩個地方;而為了讓那兩個地方能運作,又要去改其他地方。

到了後來,專案的大部份原始碼都改到了,還是搞不定;感覺就像泳賽的終點明明就在眼前,卻始終就是游不到,甚至還有快淹死的感覺。

我的心得是,不管專案規模大小,永遠要有打持久戰的準備;一步一步紮實往前推進,不奢想一步到位,才有看到隧道彼端亮光的希望。