小問題，大麻煩

Sep. 06 09:30~10:15

 

上禮拜「例外處理設計與重構實作班」下課後有學員問了一個問題…

學員：我有一個API（物件或元件）它有兩個客戶端C1和C2，這個API會傳回null而且C1和C2針對回傳值null有特別處理。今天有一個新的客戶端C3無法接受回傳值為null，要怎麼辦？

Teddy：你的意思是說API有兩種不同的客戶端，一種是既有的客戶端可以接受回傳值null，另一種是新的客戶端無法接受回傳值null，而且你又不想或不能去改舊的客戶端或新的客戶端讓它們對於是否可接受null回傳值有一致的行為？

學員：對。因為你上課有提到NullPointerException的處理方式，所以我想問關於這一點例外處理要怎麼設計？

Teddy：這看起來不像例外處裡問題，比較像是Adapter設計模式要解決的問題。API是你的Adaptee，它有C1和C2兩個既有的客戶端。現在你想把API拿到C3這個新的客戶端來使用，而你的C3客戶端所期待的Target界面是一個不能回傳null的界面。

 

Teddy：先不管API原本的設計回傳null是否合理，既然木已成舟最簡單的作法是套用Adapter，把Adaptee（也就是原本的API）包起來，在Adapter裡面處裡回傳值為null的問題。這樣既可以不改變原本的C1和C2，也可以讓C3重複使用原本的API。

***

在軟體開發的過程中經常要做出很多大大小小的決定，大決定大家還可以花點時間去討論，但是小決定經常是交由個別的開發人員自行處理。當開發人員完全不知道該如何處理時，他可能去Google找答案或問同事。但是每次一遇到問題就去Google或問人將會嚴重影響開發流暢度，所以很多人選擇「自行判斷」。如果原本的基礎專業知識不足，這些一連串的「弱品質自行判斷」將很可能導致技術債。

透過pair programming或code review這些手段可以相當程度的解決這個問題，但是這兩種方法也都有各自局限之處。pair programming一方必須要是有經驗的老手才可以發揮作用，而code review不但需要找有經驗的人，而且更討厭的是code review與開發活動經常是非同步的行為，也就是開發完成之後交給code review，review後的結果再請開發人員修改。如此一來一往增加context switch的成本。

有些問題，看起來很小，但一連串小問題累積起來就變成大問題。這些小問題很可能肇因於「馬步沒打好（基礎功夫沒練好）」，雖然練功很辛苦，但程式品質的差異通常也都來自於此。

***

友藏內心獨白：看不到的地方才是功夫所在之處。