严肃对待构建错误

构建服务器可以随心所欲地传递出错误和代码质量问题的信号，如果开发团队不关心这些问题，那么这些通知和可视化的投资收益为零。

这并不是技术本身可以解决的。流程需要每个人都同意，让人人都能看见自己参与所带来的利益是达成共识的最简方法。

问题是企业里总是有一大堆迫在眉睫的事。构建错误会比产品错误更重要吗？还有代码质量指标方面，如果改进代码质量需要数年，值得着手解决这个问题吗？

我们怎样解决这类问题？这里有一些想法：

不要过分追求代码质量指标。可以先减少测试的数量，直到代码质量报告达到了可以修复的水平。解决之后再把测试加回来。

定义问题的优先级。产品问题优先，然后才是构建错误。在问题被完全解决之前，不要在损坏的代码之上提交新代码。