業餘大叔程式心得筆記#5:80/20法則的觀察/葉光釗

應該大部分的人都聽過 「80/20 法則」,雖然它的起始目的只是用來描述經濟學上的資源分配的情形,後來適用的範疇越來越廣,也有許多變形。

在軟體開發工程這個領域中,也有許多人引用「80/20 法則」這個觀念,倡導工程師要專注那些影響全局的20%程式碼,不要分散注意力。

基於自己的經驗,我想80/20法則是的確存在的;但是一直很好奇,那些該注意的20%在哪裡?

如果根據理論推導,以程式運行的範疇來看,那些 20% 應該是執行主要功能的部分,這一點倒是沒有太多懷疑。

不過有一天,無意間瞄到我目前check-in code的頻率,修改最多的前二名居然不是主架構的部分。這一點引起了我的好奇心;仔細追下去,從自己留下來的程式臭蟲修正紀錄上看,修最多的多半是邊界條件的處理部分。

所以,如果是以修正臭蟲的角度來看,那些20%反而是boundary condition handling的部份,也就是邊界條件處理。現在反省起來,這些時間應該用在調整條件處理的架構,以容納更多的變化。

我當然不會認為這是通則。這個情況只是反映了我手邊這個程式的特性,每個專案的20%究竟如何,應該還是個案處理。

我的心得是:拍腦袋直覺很好用,但是很多情況也會騙人,事情並不都是能用膝蓋想出來的。還是老老實實建個架構蒐集資料,從資料中找證據,做決定才會實在。

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

我自己的主觀認為,機械式和數位式的產品有一個很大的差異點:機械式的東西(例如馬達、引擎等等),只要主體結構沒有太大的損傷或磨耗,可以用好幾十年(君不見,三十年以上的「野狼125」有時在街上還看得到?)。

但是數位式的東西,先撇開人為故意設計的短壽命,即使沒故障,往往經過個兩三年就不能用了。即使現在你有一隻完好無缺的PHS手機,也已經無法使用了。

我並不是在鼓吹機械式有多好,究竟這兩類產品的本質是不一樣的;而是想到數位式的東西,因為使用環境的快速變遷,即是基本的功能需求並沒有改變,產品本身還是要被迫「升級」。

程式更是如此,目前經手的一個案子就是典型的例子。

它在功能需求方面,在近二十年中一直都沒什麼大變化,這是真的;雖然年輕人很難想像,但還是有這種情況,而且還不少見:程式就是沒辦法在新的作業系統上執行,必須修改原始碼。

其中很大一塊(雖然不是全部),是因為使用者和新作業系統的資安要求變嚴謹了。

進一步研究,需要修改的地方又大致分兩類:

  • 第一類:權限問題

新系統的要求,使得很多以前能做的事情後來不能做了,或是要用不同的做法。例如以前程式可以自由在根目錄上存檔案,現在預設是不行的,還有許多跟硬體存取相關的動作,也會有同樣的問題。

這些大多跟新系統中更嚴謹的權限設計有關,也是有些大公司開始宣傳「最小權限程式設計」(least privileged programming)觀念的原因。

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

  • 第二類:安全檢查

新的系統和開發環境,由於資安的需求提高,也增加了很多關卡和檢查(例如編譯器加入對stack的檢查),程式不一定不能執行,但是會有許多警告產生,提醒開發者去修正。

如果大家都乖乖的去把臭蟲給修了,世界就會太平許多;只是加上「人性」這個因素,案件就越來越不單純。

就我的觀察,關鍵是在發現和修正的時機。安全檢查通常沒辦法在程式開發的前中端執行,因為那個時候的架構還不夠穩定,即使檢查也沒有大用;然而,如果是在產品後期做安全檢查,面臨的問題是修正的代價會越來越高。

根據自己的經驗,要修安全方面的臭蟲,會動到架構的比例實在不低;試想一個情況:產品都要上市了,誰敢去動程式的基礎?這時候,「我的運氣不會那麼糟吧?」的小惡魔聲音一定會冒出來,再自律的工程師都一樣。

我的心得是,單打獨鬥的天才型工程師會越來越少見,應該跟系統的關鍵問題(資安就是個好例子)越來越多複雜,越來越多有關。

要解決這類型的問題,光靠技術力是不夠的。必須要有較不受人性影響的程序存在才行。看樣子,我也只能繼續「業餘」下去了。