R17 工程首重精確(4)──注重問題根本

雜亂無章的系統很容易在品質方面出現暇疵，不小心寫錯的地方如果也不小心沒有被測試出來，等到系統到客戶手中後才不小心地蹦出來，除了要勞民傷財地追溯影響並修正測試外，客戶對於系統的品質也會越來越不信任。

系統的測試沒有辦法使用80/20原則，保證80%重要且常用的功能是沒有用的，因為只要有任何一個功能在上線後出問題，客戶就會把廠商直接叫過去嚴重的甚至退版。系統的測試應該是精確且完整的，然而在隨性開發的專案裡根本沒法定義出應測試的範圍，僅能含糊地說作好測試系統自然不會出問題。

“完整”必須經由精確地計算得到，不是用推估的方式。鯀不知水性，在治水時硬用全面圍堵想求滴水不漏，結果大量建立的堤防反被大水沖毀；舜明白全面圍堵的困難也知道無法平息洪水，因而根據水性計算出在最少的地方施工而達成目標。瞭解系統內部設計的根本才容易從根本解決問題，而不是根據外部現象硬加程式在表面把錯的修成對的。從表面修補時注重的只是滿足結果的產出，每一次掩飾都是讓系統隱藏一顆不定時的炸彈。

有時會發生罕見又難解的問題，因為找不到真正的發生原因且客戶一時間沒法重現而暫時擱置。在專案裡有幾次這樣的現象，但是到最後一定會迸發出來；有位同事在遇到兩年前的舊問題在上線版本復發時就曾感嘆地說，該來的總是會來，躲得掉一時不代表躲得掉永遠。

問題都應找到根本再加以解決，暫時其他因素苟且放過後，終有一天會回饋到自己身上的。