“你打破它,你买它”是最好的政策吗?

修复它是目的而不是指责。假设脆弱代码的原始作者已经离开了,谁会拥有这个问题?假设他或她只是被分配到另一个项目?遇到问题的人必须是问题解决前的所有者,他或她是当前所在的人,并且当前被指派对应用程序进行更改的任务。

我认为,营造一种指责和指责的氛围,你没有任何收获,也没有任何损失。当某个东西坏了,你应该把它分配给最好的人来解决问题,不管是因为他或她知道这个区域而最后一个接触到这个区域的人,还是第一个写它的人最了解设计理念,甚至只是一个没有任何更紧迫的事情要做的人。

如果你破坏了构建的事实最终是因为一个更广泛的问题, 然后

短期而言,使代码库无法工作的人很快又使它可以工作了。从长远来看,最适合这份工作的人(平衡不同的因素)做这项工作。

我要说的是,将所有权分配给易受灾害影响的人可能并不总是最有效的策略。它很可能是它自己的奖赏。

这就是说,如果有什么不起作用,整个团队应该承担责任。

在一个人们必须共同努力的环境中,合作应该比指责更重要。如果某个人的模块很脆弱,并且他/她的同事同意应该对此采取措施,那么一个好的团队合作者会解决问题;也就是说,他会编写单元测试等等

在任何情况下,程序员自己的代码最终都是他们的责任,如果他们不能承担让自己的代码与他人的代码合作的责任,那么他们理应承担责任。但在给他们一到两次机会让他们改过自新之前。