程序员应该修复别人的失败构建吗？[关闭]

45

一位程序员将一些工作委托给SVN存储库，然后回家。他离开后，哈德森的自动构建失败了。另一位程序员看到了这一点，并在查看了代码更改之后，发现问题是缺少一个库。他将此库添加到SVN中，下一个构建成功完成。

第二个程序员是做正确的事情还是应该等到第一个程序员解决了这个问题之后？

teamwork continuous-integration

— nahab
source

31

问题：一位程序员成员提出了一个问题。另一位成员阅读了该问题，并看到了一些语法和语法错误，因此他决定编辑问题并进行更正，以使问题更易于阅读。编辑是对的还是对的，他应该只是等待发布者纠正错误？

— yannis，2011年

2

您的团队对此情况有何规定？

4

@nahab哦，不用担心，我并不是说这是个问题:)。只是在社区和团队中，应该鼓励成员互相帮助。同样，我也不认为开发人员破坏构建不是专业的，即使是很小的错误，这些事情对我们来说都是最好的。

— yannis 2011年

11

首先拥有 Hudson 的整个想法是因为人类是人类，并且会不时地破坏建筑。您只想早点抓住它。可以说，有问题的程序员在回家之前应该已经验证了构建版本。

14

如果您考虑相反的话，这会更容易理解-如果构建被破坏，减慢整个团队的速度（甚至在几个小时后在家中），您可以修复它，但可以出于某些程序点做出有意的选择，应该允许您继续工作吗？

— Bill K

87

在某种程度上取决于您的团队通常的工作方式，但是我想这很好。保持构建正常进行可以节省其他所有人的时间。

对于第二位程序员，请放下第一封电子邮件以说明自己的工作，这是有礼貌的，以防万一需要特定版本的库或出现其他复杂情况。指出他们破坏了构建也是一种更微妙的方式。

— 卢克·格雷厄姆
source

101

其还客气第一个开发商买甜甜圈，以弥补破坏构建

— JK。

17

我想要啤酒而不是甜甜圈。

— 马丁·约克

2

甜甜圈可能会使面筋不耐。另一方面，百思买（Best Buy）的$ 5礼品卡...

— Christopher Mahan

1

@ChristopherMahan可能导致所有团队成员之间为争夺谁而斗争；或者如果给一个团队成员像从休息室中的甜甜圈盒中隐式分配的提议，则要昂贵得多。无论如何，百思买的礼品卡可能会冒犯曾经在Circuit City或CompUSA工作的任何人。:)

— Dan Neely

1

不到5美元就能在百思买买到什么？

— 凯文·克莱恩

12

这取决于。

该错误是否很明显，以至于添加库即可解决该问题？有时，解决方法是找到不需要该库的解决方法。
项目是否处于必须将所有更改链接到现有票据的阶段？如果是这样，您是否提交了罚单？那张票已经分配给您了吗？

无论如何，要专注于修复错误，而不是归咎于责任人。

— Mouviciel
source

9

“ ...不要责怪负责人。” 除非是正常情况。

— 肖恩D.

11

是的，没关系。但是，对于原始程序员来说，在测试构建版本是否编译之前回家并不专业。

您的声誉可以控制100％。像这样的东西会损害您的声誉，而试图抛光受损的声誉非常困难。

— 迈克尔·赖利（Michael Riley）
source

2

+1：让第一个开发人员来测试构建的责任。第二段确实不正确或不相关。即使您的行为完全超出预期，其他人也可能有意或无意地损害您的声誉。

— Caleb

6

原始程序员很可能在其计算机上拥有该库，但是进行自动构建的计算机却没有。是的，该库应该位于SVN中，但这可能是一个非常细微的问题，甚至没有注意到。

— mpdonadio 2011年

7

通信

对于这些情况，没有严格的规则（除了您自己的团队规则之外）。

开发人员2应该能够告诉开发人员1他可以解决自己的错误，他们两个都不应该担心这次交换会导致某些事情，他们是团队的一部分。

— 萨斯
source

5

为什么不？如果您的产品比固定责任更重要，那当然可以。尽管由于库更改而导致构建失败的原因很la脚，但是您需要谴责开发人员不要对其进行测试。

— DPD
source

3

生成失败。如果重要的是要进行每日构建，则我将对其进行修复，然后要求签入破损代码的开发人员第二天查看此修复程序，并确保该代码现在应为正确的。

如前所述，修复此问题的人可能应该向破坏该问题的人发送电子邮件，并详细说明修复的内容。

— AndyC
source

2

我的座右铭是，不要在下午3点之后提交SVN，那样您就可以始终修复自己的构建失败。

如果您不解决他/她的构建失败，那么其他人的构建也会失败。从长远来看，我会修复它以节省时间，但请确保他们知道您必须修复它。

进行某种“责备指责”脚本是实现此目的的一种好方法，或者使破坏构建的人购买甜甜圈！

— 卢克托瑞森
source

2

实际上，我们的CI工具可以选择将电子邮件发送给破坏构建的开发人员（除团队其他成员之外）。

— TMN

2

有人需要修复它，并且第一个程序员在没有确保他没有破坏构建之前就不应该回家。但是，对于这样一个容易解决的问题，叫他自己去解决这个问题是极端的。

我同意卢克·格雷厄姆（Luke Graham）关于发送说明性电子邮件的建议，尽管我说这不只是礼貌，而是基本的交流。

— 亚历克斯·达齐尔
source

由于集成构建有时需要一个小时或更长时间，具体取决于系统的复杂性，因此您必须每天实施“提交截止”，以确保一天的最后构建将在每个人都在的时候进行。即使这样，人们仍然要去看医生，进行儿童足球训练等，并且无论身材高低，都需要立即退缩。敏捷说工作应该以可持续的步伐进行，而不应该浪费工人。将它们保留到8:00观看构建成功是相反的。

— KeithS 2011年

@KeithS：是的。但是我发现，不管我什么时候离开，我最有可能中断建筑的时间就是我急忙：午餐前，会议前，一天结束前。因此，我认为在没有足够的时间来观看和修复构建之后，不提交任何内容是“个人最佳实践”。

— Daniel Pryden 2011年

2

对对对！它促进了集体代码的所有权，并在团队中施加了一种健康的同等压力，以保持较高的标准，而不会让残破的窗口场景出现。让其他开发者知道一些沟通是一个好主意。

— 彼得·凯利
source

2

我认为可以解决明显的问题-即，如果您100％确定要修复的代码的人将进行相同（或基本相同）的修复。如果修复程序比较复杂，通常与要修复代码的人交谈是很礼貌的-可能是您误解了意图，或者破坏的原因不是您想的那样，或者他打算进行其他修复但是由于某种原因，还不能提交它（生活发生了，你知道:)。

通常，规则通常是：破坏构建-修复构建，但是也有例外，尤其是在修复很明显和/或负责人不可达的情况下。

当然，如果您遇到串行构建破坏者的情况-尤其是采用“签入，回家，几天破坏构建”的模式-负责人需要就CI系统和测试为何存在以及应该如何存在进行讨论。签入之前检查:)

— 斯塔姆
source

1

事情发生。假设无法在Subversion中添加新的代码文件（无论是源代码还是已编译的文件），则可能是导致构建破坏的最常见原因，前提是该文件可以在开发人员的计算机上工作。在我最后一次使用CI环境的工作中，即使是最高级的人有时也会忘记。

我认为，如果另一个人能够修复构建并因此使团队保持嗡嗡作响，那很好。我确实认为回家的程序员至少需要一封友好的电子邮件，说明发生了什么，并提醒他确保在提交之前添加新代码。如果它经常发生，也许可以通过“耻辱之舞”将轻微罪行定罪，以帮助减少发生（并减轻情绪）。

— 基思
source

1

这取决于团队的动力，但是在理想的世界中，团队中的每个人都将“拥有”整个项目，所有代码，并因此“拥有”所有错误。因此，如果您发现问题，则可以将其解决，并仅在这样做的代码具有某些特定附加值的情况下，与错误的发起者进行沟通。

— 戴夫
source

0

除非这是经常的事，否则可以解决，在这种情况下，我会让老板打电话给他，让他自己归还并自行解决。

— 赫尔格姆
source

0

取决于，取决于...

作为程序员，我们的工作是使事情运转，而不是去评判人。所以我想说，您可以做的最好的事情就是修复它，或者如果它不明显，只需回滚所做的更改，并让第一个程序员知道，以便他以后可以修复它。

无论如何，让最新的坏蛋穿上怪异的帽子足以在下次吸引更多关注^ _ ^

— Fortran
source

0

在某些环境中，这是非常不礼貌的，并且有充分的理由。在其他环境中，这是可以预期的，并且有充分的理由。

在其他环境中，出于非常糟糕的原因，这是非常不礼貌或期望的。

它在很大程度上取决于损坏的构建的重要性与经过验证的正确构建的重要性。在某种程度上，这取决于该修补程序是正确的修补程序，也是唯一所需的修补程序。

— 大卫·施瓦兹
source

0

首先，“回家”是不合时宜的。程序员不再回家-他们只是在线还是离线。您可以ping并等待。

更严重的是，问题实际上有两个部分。“查看代码更改”是可以的；休息可能不是正确的事情。如果他对缺少图书馆的判断是错误的怎么办？

— 克里斯
source