業餘大叔程式心得筆記#7：「B計畫」與反向思考／葉光釗
實際案例告訴我們，做事一定要有「B計畫」，千萬不要等出事了再去想備案，那時候已經來不及籌備額外的資源了；而且，計畫內容也要徹底考慮周全，不要做完了才發現方向整個錯誤。
B計畫
由於前東家也算是有頭有臉的企業、而且混的資歷夠久，所以還是會學到一些有用的技能；懂得做「B計畫」，就是其中之一。
我們所受到的訓練、以及養成的習慣是：千萬不要等出事了再去想備用計畫，那時候已經來不及籌備額外的資源了。
更重要的是心理因素。通常出現意外的情況時，很容易反應慌張、甚至反應不過來；如果有個「B計畫」在那裡，就有穩住陣腳的效果。這一點的重要性，是有許多案例可以證實的。
年輕的時候，自然是滿懷理想；「A計畫」當然是設定在最佳產出，有時還會耍帥設定成超標水準，天不怕地不怕的。那個時候的「B計畫」往往只是交差了事，選一個 「快速而骯髒」（quick and dirty，翻譯怪怪的）的解法當備胎就好了。
當時總覺得，要動用到「B計畫」是無能的表現，會被人看不起。
但是隨著經歷漸長，發現實際的情形是：其實只有運氣好的時候，才能只執行「A計畫」，絕大多數時候被執行的反而是「B計畫」。
其實也不難理解，這正是「莫非定律」的實現：該出事的一定畫出事，不出事是例外，這才是常態。
那一定有人好奇，「B計畫」變成了「A計畫」，那還需要新的「B計畫」嗎? 這個原則可不能改變，計畫一定要有備胎；只是原來的「A計畫」已經簡陋到了底線，「B計畫」還能怎麼再退一步?
當然有，這時候的「B計畫」會是「讓功能消失，收拾善後」，而且要想一個好藉口。這件事可沒有想像的那麼簡單，還是要花上很多功夫的；尤其是你的工作牽連到很多人的時候。我和我們團隊就遭過牽連。
我的心得是，人生總是充滿驚奇的；除了燒香拜拜之外，還是多一分準備，心裡比較踏實吧。
反向思考
最近寫程式很容易碰到瓶頸，已經逐漸稀少的頭髮開始岌岌可危。
最主要是三個個大麻煩：一是複雜的資料結構，二是有著數不清邊角條件的UI模式，然後中間還有長時間累積下來連結兩端、亂結成一團球狀電線的邏輯。
這樣一來，要解臭蟲還勉強可以，然而一旦要加一個新功能進介面模式，總要盤算個老半天，想著要怎樣才不會讓這一團脆弱的結構坍塌下來。
沒辦法，只能繞開主體，從旁邊加進去：做了一個分離的資料結構，而使用者的動作事件則用攔截的方式接下來，讓處理邏輯跟原來那一團分開；這樣等於做了一個圍牆，圍住不想去動的舊核心。
一開始還沾沾自喜，這樣的設計看起來好像可以用。但萬萬沒想到，一路做下去，原來應該只是輔助用的資料結構越來越龐大，攔截使用者動作的地方也越來越多。
更糟糕的是，新的處裡邏輯模組因為是加在外圍，所以要處理很多原來舊核心已經處理的地方；等於圍牆越蓋越肥大，舊核心都還沒塌，外面反而撐不住先垮了。
最後只好舉白旗投降，並且深切反省；如果一開始不是依本能反應想躲開棘手的雷區，而是相反的直接切開核心把手弄髒，就不會繞這麼大一圈，最後還是功虧一簣。
回想在前東家也見過類似的例子：原來以為雲端架構不過就是一堆伺服器的集合，只是把管理和運營做好一點就可以；但是當規模越來越大、維運成本始終壓不下來，效能又一直上不去，才警覺到方向根本錯了。
正確的發展方向，應該是先做符合雲端定義的技術架構，等確定可以用了，再摘取子集合成為伺服器版本；也就是說，原本思考的方向根本就反了。
我的心得是，當腦筋打結的時候，在做運動、淋浴、或是吃甜食麻痺自己的同時，可以考慮把思考方向反轉過來，或許會有驚喜。