当您破坏了夜间版本时如何道歉[关闭]

我在项目中的第一次提交导致夜间构建被破坏，当我们临近发布时，人们遍布我。我想发送一封道歉的电子邮件，听起来应该很真诚，同时暗示这是我的第一次提交，不再赘述。

作为非英语母语者，我很难提出正确的单词。有人可以帮忙吗？

不要道歉！

• 一次在蓝月亮中打破构建不是什么大问题，并且永远不应该成为阻碍。
• 不配置连续的自动构建是您经理的错。

另外，我敢打赌，您的团队无法通过“ Joel测试”，并且无法一步一步完成构建。

如果是这样，那将是您不应该道歉的另一件事。确实，这是团队的反模式。

贝果。甜甜圈。等等，在我过去工作过的一家公司中，通常通过第二天进场道歉的食品来解决代码损坏或以其他方式导致同事受到干扰的问题。

一天，我们有一个人炸毁了一个生产数据库，这引起了整个团队的恐慌和深夜。第二天，他烤汉堡吃午餐。

我喜欢同事的道歉。美味，道歉。

为您提供两个引号：

不会犯错误的人通常不会做任何事。-威廉·康纳·马吉（William Connor Magee）

任何不犯错误的人都不会努力去做。

我同意Jim G.的观点，不要道歉，但要从中吸取教训，不要再犯同样的错误……请将其保留为DRY;）

不要道歉，请尽快修复它。没关系，每个人至少破坏一次构建，在我的上一家公司中，这是一种启动仪式。当团队成员破坏构建时，我们会在他进来前的早晨在他的办公桌上放一个橡皮鸭，这让他知道他破坏了构建并将他修复。

我们将其称为“持续集成Duckie”，当您拥有它的那一天，人们会嘲笑您，但是这一切都很有趣，没有一个人会那么生气。

我们采取了类似破损的构建方式，并将其转变为团队建设活动。

“对不起这是我的错！” 当我破坏构建时，我通常会道歉。它发生了。但是，正如其他人所说的那样，这是一个改进系统的机会，这样一个人就无法轻易地破坏其他所有人的构建。

在这种情况下，我不会进行正式的道歉，但是如果您实际上认为更正式的道歉是适当的，那么您的道歉应该做以下事情：

• 表示遗憾。
• 陈述问题。
• 承担责任。
• 作出修改。
• 面子。

也就是说，“对不起[表达遗憾]，由于不小心[保存面孔]破坏了版本[陈述问题]，给您带来了不便[承担责任]。甜甜圈明天就在我身上。[做出修改]“

每个部分都必须以适当的道歉来表示；如果您未指出问题，则不清楚。如果您不表示遗憾，承担责任并做出修改，那么人们会觉得您很不真诚。面子保护的部分是道歉中最被忽略的部分；面子保护的意思是让受伤的一方想起您是一个有价值的同事，有时会犯错，而不是一个白痴（或破坏分子！）。

最后，关于构建中断的一些想法：

我在C＃/ Visual Basic编译器团队中工作。当然，今天的Visual Studio现在是一个庞大的项目，它拥有一个自己的团队来管理构建基础结构，以及一个拥有专用空调系统的宽敞房间。早在1990年代中期，我作为实习生开始时，Visual Basic的构建团队就是一个实习生-我-是一个壁橱里装满了机器。时代变了！

早在持续集成和强大的签入流程之前的那段时间里，团队会因破坏构建而受到各种处罚。在某些团队中，惩罚是如果您破坏了版本，则每天必须在工作中戴好笑的帽子，直到其他人破坏了版本。在某些团队中，如果您戴着那顶帽子，则负责验证每晚的构造是否正确。

最后一点听起来可能很残酷，但实际上起到了重要作用。由于几乎每个人一次或一次都破坏了构建，因此最终整个团队将学习验证夜间构建的过程。

不要道歉 应当责怪您的同事是因为您没有审查您的第一次提交，并且没有像持续集成服务器那样的快速反馈系统。

在我目前的工作中，我们有一条非正式的规定，即某人在下班前偷偷地做出承诺，结果破坏了产品结构，第二天必须为整个团队带来糖果/蛋糕/饮料。但是我们确实有持续的整合，这会警告我们白天的构建已损坏。该规则可能不适用于某人的首次提交。

无论如何，正式道歉的邮件可能有点太多。

基本规则-当您输入错误时，请输入：-| 您不必深表歉意。每个人都会犯错。专业人士承认这一点。那是团队合作。其他团队成员应该齐心协力，为您提供帮助。如果没有，请寻求帮助。之后必须说的是-我们可以从中学到什么？

他们说成功的婚姻基于三个小词-“我错了”。

如果某人没有偶尔犯错误，那么他们就没有工作，但是一个人不能从中汲取的错误就是两个错误。

最好的道歉是迅速解决问题

如果您的公司已经有一种方法可以测试您的构建更改，则（A）您的更改要么失败（但无论如何您都对其进行了检查），要么（B）他们成功了（您需要构建一个新的测试用例）。

如果您的同事小心翼翼地测试他们的更改，并希望在夜间构建中找到休息，那么（C）您的过程很脆弱（您需要引入类似于极限编程中的测试）。

（D）您的更改有可能导致Bill的代码发生无法预料的更改，这些更改是在您之前进行的，或者在与您相同的版本上进行了更改。

根据您和您公司的测试方式，我会根据具体情况道歉：

• （A）我未通过构建测试，但签入了更改。抱歉，我正在更改流程，所以我不会再做。
• （B）我通过了构建测试，并添加了JUnit测试XYZtest.java，以减少再次发生的机会。
• （C）由于我们没有构建测试过程，因此我将为更改创建一个过程。我想与您分享我们如何改善构建过程。
• （D）我将与Bill一起编写一个JUnit测试XYZtest.java，以减少再次发生的机会。

我确定有一个我没有想到的（E）。

请注意，我说的是“减少再次发生的机会”，而不是“这样就不会再发生了”。它将再次发生。但是您可以改善流程以减少这种可能性。我认为，这是成功的程序员的标志之一。

不要道歉 你是人类，你会犯错误。每个人偶尔都会破坏构建，关键是要快速修复它。

至于到处都是人的人……我很好奇他们是否曾经写过错误。

如何做到这一点取决于小组中的气氛。如果这是一种怪罪的文化，那么在道歉以及您的处理方式方面，我会非常小心。如果这是一种合作的积极氛围，那么，是的，类似“我搞砸了，很抱歉。将来如何避免这种情况？” 可能是个好主意。

在任何情况下，这样的蠢事都应伴随某种验尸，以：a）查明它是如何发生的，b）如何使它再次发生的机会最小化。

我不熟悉您的结构（我在非常不同的环境中工作），但最终，现实是人们偶尔会犯错误，并且事情会崩溃。您将从经验中学到并继续前进。

在我的环境中，如果您破坏了构建，则将获得自然的肋骨和一些机智的彗星。我不确定您所在的英语国家/地区，但是作为非英语母语者，您可能没有获得评论的重点。

作为另一位高级开发人员，我曾经在一次代码审查中评论说，某种“吸引”的方式不是因为代码不好，而是对项目结构的影响。我自己要评论的是，我需要解决结构性问题。直到后来我才发现Jr Dev，尽管由于我的讲话不准确，我对他非常生气。

嗯 您将获得损坏的构建令牌。将狂犬病传给下一个幸运的接收者。一直发生。质量很重要，但错误是不可避免的。修复它们。继续。羞愧下一个可怜的家伙。

一般来说，我会说：

如果您的签入导致编译器错误，如果您在签入之前先进行了“获取最新”操作，那么您将陷入困境，可以使用一个简单的“呜呼，我不好”的命令。（尤其是如果您第二天早上10点钟漫步，而每个人都在决定要回滚到哪个变更集时）

如果您的签入导致一般性的意外行为，甚至是运行时错误，我认为也不应反对。它带有领土。只要每个人的“最新”通常都可以通过他们的编译器，人们真的就不应该摆弄自己（除了几个例外，例如删除数据库，删除项目的服务器副本和所有变更集，或者其他任何这样的例外）愚蠢的人们必须承担恶意意图）。

TEAM失败。

您的公司需要在进行首次构建的开发人员上进行更多代码审查。

我只是看不到团队如何允许这种情况继续进行，而无需他们进行审查并保证您做得正确。

接近发布时间并不是借口，而是更好地理由仔细检查新代码。

如果您的发行版本无法轻易撤消，则该小组的问题甚至更大。

我不明白为什么人们到处都是你。如果系统设置正确，他们应该能够弄明白您的更改/非常快地进行修复。

但是，如果您是那些破坏Windows构建的人之一，那么...我无能为力。（顺便说一下，很难做到这一点-在有人质疑MS建立哲学之前，但时不时地有人这样做-并且整个公司的质量检查会停止一天）。

是的-不要道歉。只需与您的经理聊天，就可以使他明白您是从自己的工作中学到的。

建造一直都在中断。错误和错误是生活中不可或缺的事实，这就是为什么您应该有一个使错误和错误的影响最小化的过程的原因。

如果构建中断很重要，则意味着您的过程已中断。

您应该进行连续构建，而不是夜间构建。

迟来的答复总比没有好...

正如许多其他人所说的那样，不要为破坏构建而道歉。只需承认是您，然后继续工作即可。无论您身在何处，都会发生这种事情，因此，没有人应该受到不良对待。人们在压力下反应不良，因此，如果您能够保持镇定并简单地继续工作，那么在重要的时候您会脱颖而出。我对人们何时遇到困难的建议是，只是避免防御，通过让人们知道您正要解决问题或当您发现自己陷入困境时迅速寻求建议来化解局势。

我个人认为破碎的建筑是一个机会。

• 如果构建中断，并且您可以证明是您的错，那么很可能表明持续集成和构建过程正在发挥作用。这是一件好事，因为它可以验证您的流程。如果构建不会中断，我担心它有问题。
• 如果您以相当普遍的方式破坏了构建，并且碰巧经常以这种方式破坏，则CI流程中可能缺少某些东西。这是一个改进流程的机会，以便可以更好地管理常见的故障情况。
• 如果您已经超出职责范围，并且确实用一个晦涩的问题弄乱了构建，那么您就有机会学习一些新知识，这些新知识可能足以引起团队其他成员的注意。

因此，我要说的是，偶尔中断构建意味着人们正在做他们的工作。当然，您可能犯了一个错误，但是如果您将其用作学习的机会，那么您所做的只是简单地学习下一次做得更好。

告诉他们他们每次入住都需要CI版本。这样，您不必等到晚上知道它已经坏了。耶！告诉他们这是错误的过程，仅此而已。您刚刚发现了他们系统中的空白。

但是，是的，请确保将其修复。没有大碍。它不在生产中。只是一个一文不值的夜晚。

我公司的常规做法是：

• 大喊“不是我！” （通常是CVS / SVN证明）
• 穿着T恤，上面写着“ my-userlogin ist Schuld！” （是的，我们开发人员拥有的此类衬衫的50％）
• 声称它可以在本地发件箱中运行并且所有测试都通过了

我公司还有一种处理此类“事件”的好方法：

• 工人必须穿以下服装半天（http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html）

• 我不会道歉。

• 我会责怪CI主管允许我提交损坏的版本。

• 应该有一个CI流程来阻止开发人员提交损坏的代码。

• 如果本地构建失败，则不应允许它进入构建服务器。

虽然我认为可以道歉，但请不要说：“我将确保不会再发生这种情况。” 因为会。如果这样做的话，它会咬你。

如果您从事的是开源项目，

只是说：“对不起，我破坏了版本。可能是我太困了！”

并将其添加为github注释。

这是因为许多开源开发人员在午夜期间编写代码。