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