業餘大叔程式心得筆記#8:寫程式的不確定性與多重人格/葉光釗

自己寫程式往往有兩個盲點:測試資源不夠,因而難以全盤瞭解用戶使用情形的全貌;另一個則是只有自己跟自己對話時,往往難以做出正確的判斷和決定。無論個人或團隊開發,都有各自的優缺點。

懂得電腦運作原理的人都知道,它的運作是一種「決定性」(deterministic)的機制。簡單的說,程式碼一但寫成,就決定了運作的順序;原則上只要給定同樣的參數,不管重複運作幾次,順序和結果都會是一樣的。

那這裡為什麼會提到不確定性呢?

雖然運作的本質沒變,但是當外部環境的輸入有變化時,程式碼的運作途徑 (execution paths)就會大不相同;所以在全部的程式碼中,實際真正會運算到的比例(或從另一個角度來說,就是「可以被人為測試到的」),就稱為「覆蓋率」(code coverage)。

舉微軟的Word為例子,它的覆蓋率約略只有30%左右。問題的核心是我們開發者並不知道:

在終端使用者的環境當中,倒底是哪30%會被用到,這就是不確定的所在。

最近寫的程式也面臨了同一個問題:由於使用者操作介面的複雜度超高,有各種各樣的邊界條件要處裡,而我的測試資源非常有限(就是我一個人而已),那麼我應該把重兵放在哪裡?

大公司的作法是,產品釋出之前先發行夠多的beta(測試)版本,透過資料回傳的機制來統計出運作的大致範疇。現在互聯網的服務更直接,也不用再出beta版了,直接將線上使用者當白老鼠就是。

但是能這樣做的前提,是公司知名度夠大、而且程式好到有足夠多的冤大頭來用才行;那麼,像我們這種小手藝人該怎麼辦?

目前我所知道最具說服力的解法,是從S大神(Steven Sinofsky)那裏聽來的。

他說,在沒有足夠多的資料之前,與其亂猜,不如將設計、程式、以及測試的火力,集中在你最炫的一小撮功能(有時我們稱之為「marquee features/招牌功能」),讓使用者完全聚焦在這裡,而不去注意其他比較陽春、甚至功能很爛的地方;也就是反守為攻、化不確定為確定。

我的心得是,大公司有到公司的做法,但是小資源的個體戶也不一定玩不動市場,就看看要不要放手一搏。

寫程式之多重人格

當初轉為「業餘」程式師,本來覺得應該是非常輕鬆自在的事情。一方面寫碼本來就是自己從小有興趣的工作,另一方面又自己可以決定一切,沒有以前職場中人多嘴雜、要伺候公公婆婆的情況。

也就是說,有許多之前累積的構想,現在總算有個時機可以一試身手了。然而故事中永遠有個「但是」,這裡也不例外;一路做下來,不但沒有越做越順手,反而越來越焦慮。

原因當然很多,有些是已經知道的、更多的卻是不想要的意外。在這些意外當中,有一項還蠻驚悚的:居然內心常常有不同的聲音開始對話。這裡就舉幾個對話的片段。

  • 場景一

天使:這裡就用這麼簡單的單向linked list,當項目多起來不是一直會重複 travel跑來跑去?還是加個hash做輔助吧?

魔鬼:不用了啦,這樣要加很多判斷耶;更何況也不一定會多花很多時間,現在CPU這麼快。簡單就好,簡單就好……。

天使:喂,你不要就這這樣跑了阿,還有很多設計要討論啊……喂!

  • 場景二

阿呆:這個資料表schema架構就這麼定了喔,你不再看一下可不可再正規化(normalize)一下?

阿瓜:就這樣啦,再不定另一邊沒辦法開始寫,有問題再改。

阿瓜:好吧,你說了算,等下中午吃甚麼?


每當心中有不同的對白產生,表示又有各式各樣的糾結要做取捨。

只有一個人做決定最大的問題,就是太容易一下妥協;無論這個人多聰明,做出來的決定八成以上都是草率的。

看樣子,寫程式還是比較像打球的團隊,這樣才有人能罩你、你也可以罩別人;不然如果都是單兵作戰,爛程式可以從你自己的盲點一槍把你撂倒,怎麼死的都不知道。