它可能不好有一个微妙的原因：有时，确实应该将破坏某些东西的责任归咎于在没有自动化测试的情况下编写脆弱代码的人，而不是通过进行本应无关的更改而破坏代码的人别的地方。
一个可以想象的例子是，当某人以一种假设特定于当前实现的行为的方式对接口进行编程时，但现有合同不能保证。然后其他人对符合合同的实现进行了更改，但破坏了依赖的代码。没有测试失败，因为没有为依赖的代码编写测试。真正的罪魁祸首是谁？
这样做的目的不是责怪人，而是要明白责任，如果“你打破它，你买它”真的是一个很好的政策。
编辑：我的措辞真的很糟糕。我的意思是关于如何编写关于依赖关系的正确软件，包括隐藏的依赖关系。我的意思是这是一个程序员的责任是避免错误的问题，而不是在发现意外错误时应该做什么。但是，既然已经给出了这么多的答案，我会让问题保持原样并相应地指出一个答案。
我认为通过营造一种指责和指责的气氛，你一无所获，一无所有。当某些东西出现问题时，您应该将其分配给最适合解决问题的人，无论是因为他或她了解该区域而最后接触该区域的人，还是最先编写该区域的人，因此最了解设计理念，甚至只是没有任何更紧迫的事情要做的人。
“你打破它，你买它”就打破构建而言是有意义的，而不是更严重的问题。
如果您将构建置于无法编译或无法运行基本测试的状态，那么您就是在阻止其他人的工作。如果您看不到快速简单的修复（因为您引入了一个快速简单的错误），那么只需回滚您的更改（可能使用您在此期间所做工作的本地副本）并提交。
如果您破坏构建的事实最终是由于更广泛的问题，那么处理这个更广泛的问题，无论是通过修复它、报告它还是分配它。
短期来看，使代码库无法运行的人很快就会使其再次可用。从长远来看，最适合这项工作的人（平衡不同的因素）能胜任这项工作。
修复它的目的不是指责。假设脆弱代码的原始作者继续前进，谁将负责这个问题？假设他或她只是被分配到另一个项目？遇到问题的人必须是问题的拥有者，直到问题得到修复，他或她是当前存在并且当前分配给应用程序更改任务的人。
现在，如果您知道创建代码时应该避免将来出现问题并且原始开发人员仍然在那里，那么让他或她了解问题以及导致问题的原因将是一件好事，但最终遇到问题的人是需要修复它以使他的新代码工作的人。
我想说，将所有权分配给容易发生灾难的人可能并不总是最有成效的策略。这很可能是它自己的回报。
最后一个接触它的人应该是错误的，重构是软件开发的很大一部分，如果有人接触了代码并且没有正确地记录、编写和测试代码而不是他们的代码。作为估计的一部分，应该包括正确地将代码置于比实际更好的状态的时间。
话虽如此，如果某些事情不起作用，整个团队都应该放弃。
在人们必须一起工作的环境中，合作应该比指责更重要。如果某人的模块很脆弱，并且如果他/她的同事同意应该对此做些什么，那么一个好的团队合作者会解决这个问题；也就是说，他会编写单元测试 .etc
无论如何，程序员自己的代码最终是他们的责任，如果他们不能承担起让自己的代码与他人的代码合作的责任，那么他们理所当然地必须承担责任。但不是在给他们一两次机会来清理他们的行为之前。