有一个微妙的原因可能不太好:有时候,破坏某些东西的责任应该放在那些编写脆弱代码而没有自动化测试的人身上,而不是通过做一个应该是无关的改变来破坏他们的代码的人.别的地方.
一个可以想象的例子是当某人以某种方式对接口进行编程时,该方式假设特定于实现的行为,但不能由现有合同保证.然后其他人对合同中的实现进行了更改,但打破了依赖的代码.没有测试失败,因为没有为依赖代码编写测试.谁真的应该受到责备？
这样做的目的不是责怪人,而是要理解责任,如果"你打破它,你买它"真的是一个很好的政策.
编辑:我真的措辞不好.我的意思是如何编写关于依赖关系的正确软件,包括隐藏的依赖关系.我的意思是这是一个问题,程序员的责任是什么来避免错误,而不是在发现意外错误时该怎么做.但是,由于已经给出了很多答案,我会让问题保持原样并相应地指出答案.
Pau*_*lin 14
我认为你没有任何好处可以通过提升责备和指责的气氛而失去一切.当某些东西被打破时,你应该把它分配给最好的人来解决这个问题,不管是因为他或她知道这个区域而触摸那个区域的最后一个人,还是那个先写这个区域的人才知道最好的设计理念,甚至只是没有任何更迫切要求的人.
"你打破它,你买它"在打破构建方面是有意义的,而不是更严重的问题.
如果将构建置于无法编译或运行基本测试的状态,则会阻止其他人的工作.如果你不能看到一个快速和简单的解决(因为你介绍一个快速和简单的错误),然后就回滚所做的更改(也许你在此期间的工作有什么想对本地副本),并提交.
如果您破坏构建的事实最终是由于更广泛的问题,那么处理更广泛的问题,无论是通过修复,报告还是分配它.
短期内,使代码库无法快速工作的人再次使其可行.从长远来看,这项工作的最佳人选(平衡不同因素)可以胜任这项工作.
| 归档时间： |
|
| 查看次数： |
510 次 |
| 最近记录： |