為什麼程式中常常有弱點 (的一個解釋)

是我自己的主觀認為啦，機械式和機械式的產品有一個很大的差異點: 機械式的東西 (例如馬達，引擎等等)，只要主體結構沒有太大的損害或損耗，可以用好幾十年 (君不見三十年以上的野狼 125 有時在街上還看的到?)。但是數位式的東西，先撇開人為故意設計的短壽命，即使沒故障，經過個 2-3 年就不能用了 (現在你即使有一隻完好無缺的 PHS 手機，也是無法使用)。我並不是在鼓吹機械式有多好，究竟這兩類產品的本質是不一樣的。而是想到數位式的東西，因為使用環境的快速變遷，即是基本的功能需求並沒有改變，產品本身還是要被迫「升級」。

程式更是如此，目前經手的一個案子就是典型的例子。它的功能需求接近二十年中一直都沒麼大變化。這是真的，雖然年輕人很難想像，但還是有這種情況，而且還不少見。但是舊的程式就是沒辦法在新的作業系統上執行，必須修改原始碼。其中很大一塊 (雖然不是全部)，是因為使用者和新的作業系統的資安要求變嚴謹了。

進一步研究，需要修改的地方又大致分兩類: 第一類是新系統的要求，使得很多以前能做的事情，後來不能做了，或是要用不同的做法。例如，以前程式可以自由在根目錄上存檔案，現在預設是不能的，還有許多跟硬體存取相關的動作，也會有同樣的問題。這些大多跟新系統中更嚴謹的權限設計有關，也是有些大公司開始在宣傳 least privileged programming 觀念的原因。

我覺得這些倒還好，反正新的規矩照做就對了，至少這些功夫是可事先預期和規劃的。但是另一類，情況比較複雜。

新的系統和開發環境，由於資安的需求提高，也增加了很多關卡和檢查 (例如編譯器加入對 stack 的檢查)，程式不一定不能執行，但是會有許多警告產生，提醒 dev 去修正。如果大家都乖乖的去把 bug 給修了，世界就會太平許多。只是加上「人性」這個因素，案件就越來越不單純。

就我的觀察，關鍵是在發現和修正的時機: security check 通常沒有辦法在程式開發的前中端執行，因為那個時候的架構還不夠穩定，check 也沒有大用。然而，在產品後期做 security check，面臨的問題是修正的代價會越來越高。根據自己的經驗，要修 security bug 會動到架構的比例實在不低；試想一個情況，產品都要 release 了，誰敢去動程式的基礎? 這時候，「我運氣不會那麼糟吧?」的小惡魔聲音一定會冒出來，再自律的工程師都一樣。

我的心得: 單打獨鬥的天才型工程師會越來越少見，應該跟系統的關鍵問題 (資安就是個好例子) 越來越多複雜，越來越多有關。要解決這類型的問題，光靠技術力是不夠的。必須要有較不受人性影響的程序存在才行。看樣子我也只能繼續「業餘」下去了。