Redundancy

March 16 22:42~23:45

這次日本福島第一核電廠發生爆炸與輻射線外洩事件，引起了全世界的關切。台電急忙出來說明，台灣的核電廠比福島第一核電廠多一部緊急柴油發電機（每部核能機組配備兩台柴油發電機，外加一部備用機，一共五台，10 秒內可供電），2 部氣渦輪發電機（10 分鐘可供電）。此外，核一廠還有 10 萬噸，核二廠有 4 萬噸深水池，可經用來降溫或滅火。

容錯（fault tolerance）的一個最基本的方法就是 redundancy，A 計畫失敗換 B 計畫， B 計畫失敗換 C 計畫，C 計畫再失敗就...雙腳開開，準備投胎...XD。總之，設計一個容錯系統必須依據人們對於『錯誤發生的機率，嚴重性，與可承受性』的不同，來決定要準備多少套『備案』。

講到這邊鄉民們會想，噯呀，當初福島第一核電廠如果設計成『可以防止 10 級地震』那就 OK 了啊，因為地球上還沒有紀錄過超過 10 級的地震...或是準備個 10 台緊急柴油發電機，外加一個翡翠水庫大小的深水池，以及『原子能研究所』所使用的『防護罩』，就不會有今天的問題發生了。姑且不論這樣的『設計』是否有可能被實做出來。就算可以，蓋一座這樣的核電廠可能需要 100 兆新台幣...你出錢嗎？

***

鏡頭轉到軟體開發，從 software process 的角度來看，一個軟體專案會『失敗』有很多原因，好的 process 會想辦法從多種角度來避免這些錯誤發生。例如，defects （或是 bugs）對於軟體開發而言是最直接可被觀察到的錯誤，一個 defects 太多的專案要成功也很難，光是接客戶抱怨的電話就什麼事都不用做了。Agile methods，像是 XP 就採取多重手段來避免 defects 的發生（Extreme Programming Explained, 2nd, p. 31），例如：

• Pair programming：簡單的數學：兩個腦袋 + 四隻眼睛 > 一個腦袋 + 兩隻眼睛。採用 pair programming 通常可以的到較佳的設計與較低的錯誤率。
• Continuous integration：衛生署提醒您：定期做健康檢查，早期發現，早期治療。Kent Beck 提醒您：導入持續整合，早期發現整合錯誤，早期修復。
• Sitting together：開發人員都坐在一起（在同一個房間），萬一有一個 defect 你沒看到，可能會『不小心』被你的同事找出來。
• Real customer involvement：開發軟體最可悲的一件事情，莫過於軟體做好了，設計的很漂亮，品質也很好，但是卻不是客戶要的。把錯誤的需求做的很漂亮，還是錯誤的需求，白搭。所以讓 real customer 參與軟體的開發，或是至少和開發團隊有很密切的互動，將可大幅減少這個問題。
• Daily deployment：平常家裡亂的跟豬窩一樣，突然明天有客人要來家裡，今天晚上才熬夜打掃也來不及。平常都把家裡整理得很乾淨，便可隨時都歡迎朋友到訪。軟體也是一樣，如果是在準備 release 之前才開始考慮『軟體佈署』的問題，那麼很多 defects 此時才會出現而且時間很緊迫可能會來不及在 release 之前修復完成。如果可以『每天都讓開發中的軟體保持可佈署的狀態』，那麼就可以將軟體的品質保持在一定的水準。

有些軟體開發人員終其一生在尋找『銀子彈』，希望能有某種單一方法能夠將 defects 一槍斃命，很可惜這種特效藥還沒被發明。Kent Beck 說：

You can't solve the defect problem with a single practice. It is too complex, with too many facets, and it will never be solved completely. What you hope to achieve is few enough defects to maintain trust both within the team and with the customer.

***

友藏內心獨白：『小三』算不算是一種 redundancy ?