業餘大叔程式心得筆記#7:「B計畫」與反向思考/葉光釗

實際案例告訴我們,做事一定要有「B計畫」,千萬不要等出事了再去想備案,那時候已經來不及籌備額外的資源了;而且,計畫內容也要徹底考慮周全,不要做完了才發現方向整個錯誤。

B計畫

由於前東家也算是有頭有臉的企業、而且混的資歷夠久,所以還是會學到一些有用的技能;懂得做「B計畫」,就是其中之一。

我們所受到的訓練、以及養成的習慣是:千萬不要等出事了再去想備用計畫,那時候已經來不及籌備額外的資源了。

更重要的是心理因素。通常出現意外的情況時,很容易反應慌張、甚至反應不過來;如果有個「B計畫」在那裡,就有穩住陣腳的效果。這一點的重要性,是有許多案例可以證實的。

年輕的時候,自然是滿懷理想;「A計畫」當然是設定在最佳產出,有時還會耍帥設定成超標水準,天不怕地不怕的。那個時候的「B計畫」往往只是交差了事,選一個 「快速而骯髒」(quick and dirty,翻譯怪怪的)的解法當備胎就好了。

當時總覺得,要動用到「B計畫」是無能的表現,會被人看不起。

但是隨著經歷漸長,發現實際的情形是:其實只有運氣好的時候,才能只執行「A計畫」,絕大多數時候被執行的反而是「B計畫」。

其實也不難理解,這正是「莫非定律」的實現:該出事的一定畫出事,不出事是例外,這才是常態。

那一定有人好奇,「B計畫」變成了「A計畫」,那還需要新的「B計畫」嗎? 這個原則可不能改變,計畫一定要有備胎;只是原來的「A計畫」已經簡陋到了底線,「B計畫」還能怎麼再退一步?

當然有,這時候的「B計畫」會是「讓功能消失,收拾善後」,而且要想一個好藉口。這件事可沒有想像的那麼簡單,還是要花上很多功夫的;尤其是你的工作牽連到很多人的時候。我和我們團隊就遭過牽連。

我的心得是,人生總是充滿驚奇的;除了燒香拜拜之外,還是多一分準備,心裡比較踏實吧。

反向思考

最近寫程式很容易碰到瓶頸,已經逐漸稀少的頭髮開始岌岌可危。

最主要是三個個大麻煩:一是複雜的資料結構,二是有著數不清邊角條件的UI模式,然後中間還有長時間累積下來連結兩端、亂結成一團球狀電線的邏輯。

這樣一來,要解臭蟲還勉強可以,然而一旦要加一個新功能進介面模式,總要盤算個老半天,想著要怎樣才不會讓這一團脆弱的結構坍塌下來。

沒辦法,只能繞開主體,從旁邊加進去:做了一個分離的資料結構,而使用者的動作事件則用攔截的方式接下來,讓處理邏輯跟原來那一團分開;這樣等於做了一個圍牆,圍住不想去動的舊核心。

一開始還沾沾自喜,這樣的設計看起來好像可以用。但萬萬沒想到,一路做下去,原來應該只是輔助用的資料結構越來越龐大,攔截使用者動作的地方也越來越多。

更糟糕的是,新的處裡邏輯模組因為是加在外圍,所以要處理很多原來舊核心已經處理的地方;等於圍牆越蓋越肥大,舊核心都還沒塌,外面反而撐不住先垮了。

最後只好舉白旗投降,並且深切反省;如果一開始不是依本能反應想躲開棘手的雷區,而是相反的直接切開核心把手弄髒,就不會繞這麼大一圈,最後還是功虧一簣。

回想在前東家也見過類似的例子:原來以為雲端架構不過就是一堆伺服器的集合,只是把管理和運營做好一點就可以;但是當規模越來越大、維運成本始終壓不下來,效能又一直上不去,才警覺到方向根本錯了。

正確的發展方向,應該是先做符合雲端定義的技術架構,等確定可以用了,再摘取子集合成為伺服器版本;也就是說,原本思考的方向根本就反了。

我的心得是,當腦筋打結的時候,在做運動、淋浴、或是吃甜食麻痺自己的同時,可以考慮把思考方向反轉過來,或許會有驚喜。