業餘大叔程式心得筆記#8：寫程式的不確定性與多重人格／葉光釗
自己寫程式往往有兩個盲點：測試資源不夠，因而難以全盤瞭解用戶使用情形的全貌；另一個則是只有自己跟自己對話時，往往難以做出正確的判斷和決定。無論個人或團隊開發，都有各自的優缺點。
懂得電腦運作原理的人都知道，它的運作是一種「決定性」（deterministic）的機制。簡單的說，程式碼一但寫成，就決定了運作的順序；原則上只要給定同樣的參數，不管重複運作幾次，順序和結果都會是一樣的。
那這裡為什麼會提到不確定性呢？
雖然運作的本質沒變，但是當外部環境的輸入有變化時，程式碼的運作途徑 （execution paths）就會大不相同；所以在全部的程式碼中，實際真正會運算到的比例（或從另一個角度來說，就是「可以被人為測試到的」），就稱為「覆蓋率」（code coverage）。
舉微軟的Word為例子，它的覆蓋率約略只有30%左右。問題的核心是我們開發者並不知道：
在終端使用者的環境當中，倒底是哪30%會被用到，這就是不確定的所在。
最近寫的程式也面臨了同一個問題：由於使用者操作介面的複雜度超高，有各種各樣的邊界條件要處裡，而我的測試資源非常有限（就是我一個人而已），那麼我應該把重兵放在哪裡？
大公司的作法是，產品釋出之前先發行夠多的beta（測試）版本，透過資料回傳的機制來統計出運作的大致範疇。現在互聯網的服務更直接，也不用再出beta版了，直接將線上使用者當白老鼠就是。
但是能這樣做的前提，是公司知名度夠大、而且程式好到有足夠多的冤大頭來用才行；那麼，像我們這種小手藝人該怎麼辦?
目前我所知道最具說服力的解法，是從S大神（Steven Sinofsky）那裏聽來的。
他說，在沒有足夠多的資料之前，與其亂猜，不如將設計、程式、以及測試的火力，集中在你最炫的一小撮功能（有時我們稱之為「marquee features／招牌功能」），讓使用者完全聚焦在這裡，而不去注意其他比較陽春、甚至功能很爛的地方；也就是反守為攻、化不確定為確定。
我的心得是，大公司有到公司的做法，但是小資源的個體戶也不一定玩不動市場，就看看要不要放手一搏。
寫程式之多重人格
當初轉為「業餘」程式師，本來覺得應該是非常輕鬆自在的事情。一方面寫碼本來就是自己從小有興趣的工作，另一方面又自己可以決定一切，沒有以前職場中人多嘴雜、要伺候公公婆婆的情況。
也就是說，有許多之前累積的構想，現在總算有個時機可以一試身手了。然而故事中永遠有個「但是」，這裡也不例外；一路做下來，不但沒有越做越順手，反而越來越焦慮。
原因當然很多，有些是已經知道的、更多的卻是不想要的意外。在這些意外當中，有一項還蠻驚悚的：居然內心常常有不同的聲音開始對話。這裡就舉幾個對話的片段。
場景一
天使：這裡就用這麼簡單的單向linked list，當項目多起來不是一直會重複 travel跑來跑去？還是加個hash做輔助吧？
魔鬼：不用了啦，這樣要加很多判斷耶；更何況也不一定會多花很多時間，現在CPU這麼快。簡單就好，簡單就好……。
天使：喂，你不要就這這樣跑了阿，還有很多設計要討論啊……喂！
場景二
阿呆：這個資料表schema架構就這麼定了喔，你不再看一下可不可再正規化（normalize）一下？
阿瓜：就這樣啦，再不定另一邊沒辦法開始寫，有問題再改。
阿瓜：好吧，你說了算，等下中午吃甚麼?
每當心中有不同的對白產生，表示又有各式各樣的糾結要做取捨。
只有一個人做決定最大的問題，就是太容易一下妥協；無論這個人多聰明，做出來的決定八成以上都是草率的。
看樣子，寫程式還是比較像打球的團隊，這樣才有人能罩你、你也可以罩別人；不然如果都是單兵作戰，爛程式可以從你自己的盲點一槍把你撂倒，怎麼死的都不知道。