
206
| 第廿二章:凍結奇碼
凍結的長度
你必須宣告一個正確的數位冬天長度。如同納尼亞的冬天,你不會想要有一個無謂的冗
長凍結,讓聖誕節永遠不會到來!但是如果它太短,凍結會是個沒意義的舉動。
正確的週期取決於你的專案的複雜程度、它在測試時需要的事物(包括人與資源—我
們需要安裝或設置一整個獨立的測試平台,再加入管理員與技術人員來讓它持續運轉
嗎?)、已經被放入釋出版本的修改範圍(可能會影響回歸測試的程度),及可用來投入
測試與驗證的資源。
典型的凍結週期是兩週。
小心 Pareto 原則:我們在 IT 專案中經常看到“最後”的 20% 工作會花費總時間的 80%
(或左右)。要避免這一點,確保你在正確的時機進入凍結。不要在認為自己只需要“完
成”某些事情時宣告凍結。一旦凍結,所有事情就都結束了。
感受凍結
從程式碼凍結到釋出是段艱難的道路—不是在公園內野餐。相應地設定你的期望。
在程式碼凍結期間,你要知道,你無法修改被找出的 bug,因為它們的重要程度不足以
讓風險涉入其中。這已經不再是允許你修改所有程式的自由編寫時期了,否則你就不需
要宣告凍結。因此你要有失望及出貨的產品不如你預期的心理準備!
重點
你認為可以有更好的軟體出貨,並不是不尋常(或錯誤)的事情。
看一下光明面:因為你發現那些 bug 了,所以可以在下一個版本中修改它們。[Page-200]
你也要有心理準備在凍結期間累積
技術債務
1
。這是少數可以這麼做的時間點:沒有空
間可以做大範圍的修復時,你就必須用治標不治本的技術來修改問題,來產生“夠好”
的出貨產品。但是記得將這種工作視為 ...