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

#1 楼

别道歉！




一次过破蓝的构建并不是什么大不了的事，并且永远不应该成为秀场停止。
没有配置连续的自动构建是您经理的错。

如果是这样，那你不应该道歉。
实际上，这是团队反模式。

#2 楼

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

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

我很喜欢同事的道歉。道歉，好吃。

#3 楼

为您提供两个引号：

没有错误的人通常不会做任何事情。--William Connor Magee
没有错误的人都不会努力。韦斯·罗伯茨

我同意吉姆·G。的道歉，但要向他道歉，但不要从中吸取教训，不要再犯同样的错误……请保持干燥；）

#4 楼

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

我们称之为持续集成Duckie，当您有一天的工作时，人们会嘲笑您，但这很有趣，没有一个人本来会很生气。进入团队建设练习。

#5 楼

“对不起这是我的错！”这是我通常会在破坏版本时道歉的方式。它发生了。但是，正如其他人所说的，这是一个改进系统的机会，这样一个人就不能轻易地破坏其他人的构建。实际上觉得更正式的道歉是适当的，那么您的道歉应该做这些事情：


表示遗憾。
说明问题。
承担责任。
/>进行修改。
保存面子。

即，“对不起[表达遗憾]，我因不小心[保存面孔]破坏了版本而给您[承担责任] [陈述问题]。甜甜圈明天就在我身上。[做出修正]“如果您未指出问题，则不清楚。如果您不表示遗憾，承担责任并做出修改，那么人们会觉得您很不真诚。面子保护的部分是道歉中最被忽略的部分；面子保护的部分使人想起受伤的人，您是一个有价值的同事，有时会犯错误，而不是一个白痴（或破坏者！）

最后，一些关于破坏建筑物的想法：

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

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

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

#6 楼

不要道歉应该责怪您的同事是因为您没有审核您的第一次提交，并且没有像持续集成服务器这样的构建快速反馈系统。就在下班并证明要中断之前，第二天就要为整个团队带来糖果/蛋糕/饮料。但是我们确实有持续的整合，这会警告我们白天的构建已损坏。而且该规则可能不适用于某人的第一次提交。

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

#7 楼

一个基本规则-当您输入错误时，请告知：-|
您不必费心道歉。
每个人都会犯错。专业人士承认。那是团队合作。
其他团队成员应该齐心协力，帮助您解决这个问题。我们可以从中学到吗？

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

如果某人没有偶尔犯错，他们没有用，
但是一个人没有学到的错误就是两个错误。

#8 楼

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

#9 楼

如果您的公司已经有一种方法可以测试您的构建更改，那么（A）您的更改要么失败（但无论如何您都对其进行了检查），要么（B）他们成功了（您需要构建一个新的测试用例）。 >
如果您的同事小心翼翼地测试他们的更改，并希望在夜间构建中发现中断，那么（C）您的过程很脆弱（您需要引入类似于极限编程的测试）。

（D）您的更改可能导致Bill的代码发生了无法预料的更改，这些更改是在您之前进行的，或者是在与您相同的版本上进行的更改。 ，我会根据具体情况道歉：


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

我肯定有一个（E）我还没有没想到。

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

#10 楼

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

至于那些跳过你的人...我很好奇他们是否曾经写过bug。

#11 楼

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

无论如何，这样的蠢事应伴随某种验尸，以：a）查明它是如何发生的，b）如何使它再次发生的可能性最小。

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

#12 楼

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

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

#13 楼

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

#14 楼

通常，我会说：

如果您的签入导致编译器错误，那么如果您在签入之前进行了“获取最新”操作，那么您会陷入困境，那么一个简单的“ w，我的坏”就是为了。 （尤其是如果您第二天早上10时漫步，而每个人都在决定要回滚到哪个变更集）

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

#15 楼

TEAM失败。

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

我只是看不到团队如何允许这种情况继续进行下去他们会进行审查并提供一些保证，确保您做事正确。 >
如果无法轻松撤消您的发行版，则该小组存在更大的问题。

#16 楼

我不明白为什么人们到处都是你。如果系统设置正确，他们应该可以梳理您的更改/快速修复它们。帮不上忙（顺便说一句，很难做到–在任何人质疑MS建立哲学之前，但时不时有人做到这一点-整个公司的质量检查将持续一天。） 。只需与您的经理聊天，让他了解您已从自己的工作中学到了。

#17 楼

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

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

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

#18 楼

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

就我个人而言，我认为破损的构建是一个机会。持续集成和构建过程正在发挥作用。这是一件好事，因为它可以验证您的流程。如果构建永不中断，我担心它有问题。
如果您以相当普遍的方式破坏了构建，并且碰巧经常以这种方式破坏，那么可能缺少某些内容从CI流程开始。这是一个改进流程的机会，以便可以更好地管理常见的故障情况。
如果您超出了职责范围，并且确实用一个晦涩的问题弄乱了构建，那么您就有机会了解一些可能足以对团队其他成员发出警告的重要新事物。

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

#19 楼

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

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

#20 楼

我公司的惯例是：


大喊“不是我！” （否则通常是CVS / SVN证明）
穿着T恤，上面写着“我的用户登录专家Schuld！” （是的，我们开发人员拥有的50％都是这样的衬衫）
声明它可以在本地sendbox中工作，并且所有测试都通过了很好的测试

我的公司也有很好的方法来处理这种情况“事件”：


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

#21 楼

我不会道歉。
我会怪我CI主管允许我提交损坏的版本。
应该有一个CI流程来阻止开发人员提交损坏的代码。
如果本地构建失败，则不应允许它进入构建服务器。

#22 楼

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

#23 楼

如果您正在开发一个开源项目，

只是说“对不起，我破坏了构建。可能是我太困了！”

并将其添加为github注释。

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