嚴肅對待構(gòu)建錯誤

構(gòu)建服務(wù)器可以隨心所欲地傳遞出錯誤和代碼質(zhì)量問題的信號，如果開發(fā)團隊不關(guān)心這些問題，那么這些通知和可視化的投資收益為零。

這并不是技術(shù)本身可以解決的。流程需要每個人都同意，讓人人都能看見自己參與所帶來的利益是達成共識的最簡方法。

問題是企業(yè)里總是有一大堆迫在眉睫的事。構(gòu)建錯誤會比產(chǎn)品錯誤更重要嗎？還有代碼質(zhì)量指標方面，如果改進代碼質(zhì)量需要數(shù)年，值得著手解決這個問題嗎？

我們怎樣解決這類問題？這里有一些想法：

不要過分追求代碼質(zhì)量指標。可以先減少測試的數(shù)量，直到代碼質(zhì)量報告達到了可以修復(fù)的水平。解決之后再把測試加回來。

定義問題的優(yōu)先級。產(chǎn)品問題優(yōu)先，然后才是構(gòu)建錯誤。在問題被完全解決之前，不要在損壞的代碼之上提交新代碼。