複雜程式的不確定性

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

那這裡為什麼會提到不確定性呢? 雖然運作的本質沒變，但是外部環境的輸入有變化，程式碼的運作途徑 (execution paths)，就會大不相同。所以在全部的程式碼中，實際真正會運算到的比例 (或從另一個角度，可以被人為所測試到的)，稱為 code coverage (覆蓋率)。舉一個例子來說，MS 的 Word，它的覆蓋率約略只有 30% 左右。問題的核心是，我們不知道自終端使用者的環境當中，倒底是那一部分的 30% 會被用到。這是不確定的所在。

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

大公司的作法是: 產品釋出之前，先發行夠多的 beta 版本，透過資料回傳的機制，統計出運作的大致範疇。現在互聯網的服務更直接，也不出 beta 了，直接將線上使用者當白老鼠。但是能這樣做的前提，是公司知名度夠大，而且程式好到有足夠多的冤大頭來用才行。那像我們這種小手藝人該怎麼辦?

目前我所知道最能說服我的解法，是從 S 大神 (Steven Sinofsky) 那裏聽來的。他說，在沒有足夠多的資料之前，與其亂猜，不如集設計/coding/測試的中火力在你最炫的一小撮功能 (有時我們成為 marquee features 招牌功能)，讓使用者完全聚焦於這裡，而不去注意其他陽春或甚至功能很爛的地方，反守為攻，化不確定為確定。

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