“你打破它，你买它”是最好的政策吗？

Question

有一个微妙的原因可能不太好：有时候，破坏某些东西的责任应该放在那些没有自动化测试而编写脆弱代码的人身上，而不是那些通过制作应该破坏他们代码的人。在其他地方没有相关的变化。

一个可以想象的例子是某人以某种方式对一个接口进行编程，该方式假设特定于实现的行为，但现有合同无法保证。然后其他人对合同中的实现进行了更改，但打破了依赖的代码。没有测试失败，因为没有为依赖代码编写测试。谁真的应该受到责备？

这样做的目的不是责怪人，而是要理解责任，如果“你打破它，你买它”真的是一个很好的政策。

编辑：我的确措辞不好。我的意思是如何编写关于依赖关系的正确软件，包括隐藏的依赖关系。我的意思是这是一个问题，程序员的责任是什么来避免错误，而不是在发现意外错误时该怎么做。但是，由于已经给出了很多答案，我会让问题保持原样并相应地指出答案。

Answer 1

我认为你可以通过提升责备和指责的气氛来获得任何好处和失去的一切。当某些东西被打破时，你应该把它分配给最好的人来解决这个问题，不管是因为他或她知道这个区域而触摸那个区域的最后一个人，还是那个先写这个区域的人才知道最好的设计理念，或者甚至只是没有任何更迫切要求的人。

Answer 2

“你打破它，你买它”在破坏构建方面是有意义的，而不是更严重的问题。

如果您将构建置于无法编译或运行基本测试的状态，则会阻止其他人的工作。如果您看不到快速简单的修复（因为您引入了一个快速而简单的错误），那么只需回滚您的更改（可能使用您在此期间工作的本地副本）并提交。

如果您破坏构建的事实最终是由于更广泛的问题，那么然后将处理更广泛的问题，无论是通过修复，报告还是分配它。

短期内，使代码库无法快速工作的人再次使其可行。从长远来看，这项工作的最佳人选（平衡不同因素）可以胜任这项工作。

Answer 3

修复它的目的不是责备。假设脆弱代码的原始作者继续前进，谁会拥有这个问题呢？假设他或她被简单地分配到另一个项目？遇到问题的人需要是拥有该问题的人，直到问题得到解决，他或她是当前在那里并且目前被分配到更改应用程序的任务的人。

现在，如果您知道代码是在未来应该避免的问题中创建的，并且原始开发人员仍然存在，那么让他或她知道该问题及其导致问题的原因将是一件好事。但最终遇到问题的人是需要修复它才能让他的新代码工作的人。

Answer 4

我想说，为易受灾害分配所有权可能并不总是最有效的策略。这可能是它自己的奖励。

Answer 5

最后触摸它的人应该是错误的，重构是软件开发的一个重要部分，如果有人触及代码并且没有正确地记录，编写和测试代码而不是它们。作为估算的一部分，应该包括正确地使代码处于比找到状态更好的时间。

话虽如此，如果某些事情不起作用，整个团队都应该垮台。

Answer 6

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

在任何情况下，程序员自己的代码最终都是他们的责任，如果他们无法承担使他们的代码与他人合作的责任，那么他们必须承担责任。但是，在给他们一两次机会清理他们的行为之前，不是这样。