2011年9月18日 星期日

Problem Solving 的技巧 (3):因事制宜

不知不覺,這類文章可以寫到第三篇,感到頗意外的。前兩篇是:

昨天看到 TonyQ 在 Soft_Job 寫的文章:《Re: [閒聊] 你在開發程式時,是重視績效還是品質。覺得深有同感,摘錄幾段如下:

對我們來講很多其實可以是 nice to have 的東西, 都會被我們當成 must have。

這個判斷是經驗跟 domain 累積下來的,沒有公式,沒有法則, 做久了你就是會知道什麼架構之後會一直噴 exception ,

而且你還會知道等他出事時你一定沒辦法好好處理, 所以你要在這個當下把它處理掉。

...

觀察他們影響到哪些地方,你有沒有能力測試他們, 還有你的環境允不允許這件事情帶來的不穩定性。

一般來講,如果是我個人自己的專案,我非常不介意大改, 只要我後續還有時間可以處理這些出來的問題。

對公司或者客戶的專案,我會採取相對保守的態度。

這是對風險管理的策略問題。

在 Plurk 上貼了這篇文章後,Thinkerqrtt1 提出另一面看法,強調「早期發現,早期治療」的好處。於是決定借題寫一下自己的看法。

在討論這個議題前,我想先強調,為了方便聚焦討論,我們往往會先偋除一些條件,或是先依自己的假設開始論述。而有爭論的地方,往往卻是這些隱藏的前提。好比說「寫測試碼重不重要?」單單這樣一個命題,只能討論出很模糊的概念,不論支持與否,看起來都有些道理。但加入一些條件後,像是「這是長期開發並有多人參與的專案」或是「後天要交的雛型」,相信大家對此會有不同的答案,也會少一些分歧。相關的想法,可以參考《黑天鵝效應》這篇有摘要讀書心得,其中敘事謬誤和戲局謬誤啟發我這個觀點。

我的想法是,在達到必要需求的前提下,依個人以及團隊的能力,看看能提昇多少品質。問題在於,何謂 must have、何謂 nice to have,每個人的見解不同。爭議點在於,每個人的能力不同,導致評估的實作成本不同。一樣是 nice to have,有些被認同可以做,有些則否。

( ps. 這篇文章不討論規格不明確的問題,這是另一個大議題。 )

舉例來說,A 認為現在重構只能提升一點品質,卻要花兩天;B 認同 A 評估的品質,但 B 覺得只要花半天。所以 A 覺得不划算,而 B 持相反意見。從這樣的評估結果很難說 A 或 B 誰對誰錯,也許 A 沒重構經驗不信任重構,也可能 A 有豐富的經驗,估得比 B 準。

在體認到個人能力不同、習慣不同的前提下,對自己的要求是盡量提高自己的能力,多付出時間提高品質,減少日後維護成本並能練功,形成正向循環對其他人來說,看對方是那種人,是「過」或「不及」,再從另一個角度和對方討論。

舉例來說,若團隊成員不熟或不認同 unit test。當下就要出貨了,這時硬要大家學習並實作測試,並不適合 (不如當「負面教材」,待下次專案的開頭提出討論)。但若成員有過相關經驗,同樣時程下,就能針對核心程式補些測試,花最小成本減少最多風險。當成員嘗到測試甜頭,不小心寫過多測試碼時,和對方討論優先順序,減少寫 C/P 值低的測試碼。

回頭看品質的問題,能力愈強、經驗愈豐富,增加 nice to have 的成本愈低,自然能前期處理,減少技術債。反之,在時程的考量下 (ship or die),能力和經驗不夠時,得選擇先放過一些潛在問題,日後仍有需求時,再花更多成本補救。先活下去,才有更多的本錢來還債。

因事制宜說來簡單,只有四個字而已。實務上卻需經年累月的經驗,不止要考量時程、未來需求變化等項目,也要留意每個人的能力和習性,才能在當下找到較為適當的平衡點。而增加經驗的方法,如同杜書伍在《打造將才基因》裡所言,除了比別人投入更多時間外,沒有其它的捷徑。

2011-09-25 更新

看到 Thinker 提了他的相關看法:《程式碼要清的多乾淨?》,裡面提了不錯的建議:

除了能力不同之外,個人的膽量、積極態度和價值觀也同樣影嚮著評估的差異。 我強調的是,積極態度和個人的能力呈正相關。
...
要評估自己的能力,並適度的承受犯錯的風險。
勇於嘗試、有控制性地犯錯,對於學習很有幫助。我覺得在我學習的前一大段生涯裡,過於謹慎而不敢犯錯,以致於學習速度較為緩慢。而我認識一些晚起步、卻成長相當快的朋友,都具有大膽嘗試、不斷犯錯的特質。他們快速地累積經驗,並培養出更多的膽識和更大的企圖心。