我应该告诉某人他们的提交导致了回归吗？

当您跟踪并修复回归时（即导致以前工作的代码停止工作的错误），版本控制使您完全可以查找谁提交了破坏它的更改。

值得这样做吗？向做出承诺的人指出这一点是否具有建设性？错误的性质（在对更改的代码的基本误解上没有引起注意），这是否是一个好主意？

如果告诉他们一个好主意，那么有什么好的方法可以做到而又不会引起进攻或引起他们的防守呢？

出于争论的考虑，假设该错误非常微妙，CI服务器的自动测试无法对其进行识别。

如果您只是让他们告诉他们他们犯了一个错误，那么除非您是世界上最好的外交官，否则听起来很难像“哈！-看您犯的这个错误！”。我们都是人类，批评很难接受。

另一方面，除非更改是完全无关紧要的，而且显然是错误的，否则我通常会发现与进行原始更改的人交谈是有益的，以此作为我调查的一部分，以确保我完全了解发生了什么事情，因此我通常会采用这种方式最终处理这些情况的方法是，与所述人员进行交谈，并进行如下对话：

我：我正在研究此错误，其中...错误摘要...而且我认为我已将问题归结为您所做的更改。您还记得此更改的目的吗？/您有时间解释这一变化吗？

然后：

他们：当然，那是要处理的...我当时不知道的情况...

或类似的东西：

他们：不，对不起，我不记得了，对我来说看起来很不对劲。

通过一起调查和研究变更/错误，原始提交者可以从错误中学习，而不会感到被批评*，而且您很有可能也会学到一些东西。

如果原始提交者不在身边或很忙，那么您可以将自己的问题彻底解决，我通常会发现与最初进行更改的人交谈会更快。

* 当然，只有在您真的对其他人的帮助感兴趣的情况下，这才起作用。如果您只是将其用作告诉别人他们犯了一个错误的轻描淡写的方法，那么这可能比仅仅公开谈论错误更糟。

要有主见而不要有侵略性。总是喜欢说类似于“这段代码不起作用”与“您的代码不起作用”之类的东西。批评代码，而不是编写代码的人。

更好的是，如果您能想到一个解决方案，请对其进行修复并推送给他们-假设您拥有分布式版本控制系统。然后询问他们您的修复程序是否对他们正在修复的错误有效。总体而言，请尝试增加您及其编程知识。但是，这样做可以避免您的自我阻碍。

当然，您应该愿意听取其他遇到相同问题的开发人员的意见，并按照自己的意愿行事。

是的，总是。作为程序员，从错误中学习是您的工作。

让他们知道自己犯的错误将有助于他们成为更好的编码人员，并减少将来犯错误的机会。但是要有礼貌并且不要花很多钱，我们每个人都经常创建错误。我发现礼貌的电子邮件是一种让人们知道的非常无聊的方式。

建设性的方法是查找错误，修复错误并采取措施以避免将来出现类似的错误。

如果涉及向人们解释如何不引入错误，那就去努力。

有一次，我在一个团队中工作，项目经理从未告诉过某个特定的开发人员他犯了一个错误：他与整个团队一起组织了一次会议，他解释说犯了一个错误，并且定义了一个新的流程来消除那样的错误。这样，没有人受到侮辱。

一般来说，是的。

如果您对此保持机智，谁也不会防御。一种简单的处理方法是要求他们仔细检查您的更改，然后再将其提交回主干（或与您的版本控制系统相关的任何内容）。如果您通过修复明显的错误为他们节省了几分钟的时间，人们将不胜感激，但如果您修复未破坏的东西并最终破坏了他们的代码，他们将不满意。给他们一个机会来查看您的更改将告诉他们您不想踩他们的脚趾，并给他们一个反对更改的机会。

如果这是一个很大的变化，而不仅仅是错别字，那么在您尝试解决此问题之前，请让作者有所提示是个好主意。“乔，我昨天在合并自己的东西，发现不确定自己是否理解。它看起来像是个错误，但是在弄乱您的代码之前，我想由您运行它。您能否看一下我？”

您与作者的关系是一个很大的因素。如果您不介意作者不告诉您修改代码，并且您确定这种感觉是相互的，那可能就不值得一提了。如果是具有更多经验/高级/状态的人员，则需要让他们知道您将要更改他们的代码。如果是少一些的人，请考虑这是他们需要听到的东西，以避免重蹈覆辙，否则可能会使他们不必要地感到尴尬。

永远记住，如果您可以找到谁签入了“错误”，那么他们也可以很容易地找到谁“修复了”他们的代码。如果您认为他们在事后发现自己的变化会感到沮丧/烦恼/尴尬，请务必事先告知他们。

另外，修复错误也不是您唯一的选择。您始终可以仅在问题跟踪器中报告错误。在此再次需要机密-报告错误可使整个团队更清楚地看到它，但它还为作者提供了修复自己的错误的机会。如果您不确定解决问题的最佳方法或只是没有时间解决问题，报告是最好的选择。

如果我提交的内容中包含错误，则最好告诉我。如果我发现您提交的内容中包含错误，我一定会告诉您。

我们只有在理解错误时才能有所改进。这就是我们将来产生更好的代码的方式。

您在这里得到了很好的答案。

当我犯错时，我只能添加一次从经理那里学到的技术。

我是博士学位的中年顾问。她是没有的年轻经理，因此可能会有一种威望梯度。无论如何，她显然对这种情况有经验，并且知道如何处理。

她以几乎道歉的口吻向我提到似乎存在问题，我是否有时间对此进行调查？

通常，错误是我的，她知道。那是技巧。

我认为这个问题还有更深层次的问题。是的，一定要使提交者知道其更改的后果，以便他们可以了解发生的事情，而不必再次做同样的事情。但是，问题的上下文表明您在原始提交者不知道他们甚至造成问题的情况下准备并提交了修复程序。其中存在着一个更深层次的问题：提交者为什么不了解回归，他们为什么不自行解决？您所描述的情况可能表明原始提交者缺乏责任心或警惕性，这可能与其整体表现和动机有关。

我的软件工程经验告诉我，在生产过程中，我不仅要拥有我负责的所有代码更改，而且要拥有所有的代码更改，这包括了解它们的影响，包括对构建系统和（显然）产品行为的影响。

如果某人的变更引起了问题，这并不意味着该人是一名糟糕的工程师，但通常他们应该负责并参与解决所有错误的工作。即使他们没有“过错”，例如，他们的代码暴露了已存在多年的代码库中的潜在错误，他们也应该是最早意识到其更改问题的人之一。即使原始提交者不是修复错误的合适人选，他们也应与更改的生命周期紧密联系。

对您的问题有很好的吸引力！所有人都告诉你该怎么做。你应该告诉吗？是！每当问题问到“我是否需要更多沟通？”时，答案几乎总是是！

但是要补充一点：您的前提存在缺陷。

一位同事所做的承诺并没有破坏CI，但会导致您发现问题。

恭喜！您发现了一个新的错误，而不是回归。认真地说，在提交时，您是否手动测试自动化（或标准化手册）测试未涵盖的所有方案和代码行？

一定要让您的同事参与此修复，并进行测试以确保它不会再次发生。你们都是英雄！但是，如果您在言辞或行动上不加指责，您就有责任使最严重的组织疾病之一永存：问责而不负责。

如果您真的需要找到一名平民，考虑一下犯了原始代码失败的家伙，并为毫无戒心的伙伴留下了陷阱（显然没有足够的测试范围）。希望那不是你！

总是把别人当作比你更好的人，总是看到别人的好品质，也总是知道我也会犯错误。

告诉他们只有你们两个的时间。

如果有人在您说他犯了一个错误时得罪了，那意味着他认为他是地球上最聪明的人，没有犯错。当受到批评时，他会感到，就像我们在波兰所说的那样，“皇冠从他的头'。

因此，您应该毫不犹豫地说某人犯了一个错误。这是正常的。每个人都会犯错误，即使是最好的也是！只有那些什么都不做的人才不会犯错误;）

除了其他人所说的，还要确保实际上是他们的提交导致了错误。当然，不要怪自己的错误。无论您以多高的机智接近他们，如果您将他们没有做的事情归咎于他们，您仍然会生气。（作为一个一直被指责为其他人的bug的人说话;有一次有人走到我面前说我做了一些非常愚蠢的事情，然后我提出了提交日志，发现最后碰到那行代码的人是怪我的人。他仍然似乎仍然认为这是我的错，因为我最初写的是台词。

为什么我在这里看不到一个反映该问题的最高票数评论的答案？

是的，绝对要告诉他们，但是不要在整个团队面前这样做

接近开发人员1：1并指出错误。没什么大不了的。我一直认为指出整个团队面前的错误是一个坏主意。它可能对某些开发人员有效，但并非对每个人都适用，并且可能产生负面影响。请记住，我们都曾在某个时候碰过他们，正​​如第二投票的最高答案所言，您可以从错误中学习

通常，当您开始赞美然后发现错误时，我通常会发现它工作得最好……诸如“您实施的修复效果很好，但x，y，z似乎坏了”或“感谢您做一个，b，c，但似乎导致x，y，z”

简单的答案：是的。

更长的答案：我的最后一个工作是在一家敏捷公司中，该公司将TDD与CI工具配合使用，以确保我们的SVN存储库中的内容始终有效。提交某些内容后，我们的TeamCity服务器将获得一份副本，进行编译并运行单元测试。它还每小时进行一次集成测试。如果提交的某些内容导致CI失败，那么每个人都会收到一封电子邮件，指出该构建基于特定人员的提交而被破坏。

并非总能抓住一切。我们有祸了，我们并没有强制执行的代码覆盖，即使什么东西覆盖单元或集成测试，他们可能不会行使充分的代码。发生这种情况时，负责解决已知问题（如果质量检查人员发现了问题）或缺陷（如果客户是dun-dun-dun的话）的人都会被“责备”（表明谁最后修改了某行的每一行）代码文件）并确定罪魁祸首。

召集某人签入破损的代码不一定是一件坏事。他们未能正确地完成工作，他们或其他人必须回过头来纠正错误。这事儿常常发生; 这应该有多大的麻烦，取决于修复的难易程度，错误是否表明该人甚至没有编译或运行相关代码以及整个公司文化。整个过程中重要的是，犯错的人会学到一些东西。如果构建因同一人一遍又一遍而中断，则该人存在一个更深层次的问题，必须解决。始终中断的构建表明团队的沟通或过程知识方面的问题。

是。要求对方查看您对代码所做的修复。有时，我发现别人的错误实际上是代码中的棘手部分，如果简单地修复该错误，则会带来其他一些看不见的后果。

有很多因素在起作用。

• 该漏洞有多严重？
• 您与断路器之间的资历关系是什么？
• 团队有多忙/压力？
• 断路器是在代码库的一部分中工作还是在您的代码库中工作？
• 您如何确定它确实是一个错误，以及您如何确定您的修复是正确的？

如果问题很小（错别字/ thinko /剪切和粘贴错误），并且断路器是忙碌的同伴，并且您对问题的评估充满信心，则可能无需引起他们的注意。（例如foo.x = bar.x; foo.y = bar.y, foo.z = bar.y）。

在大多数其他情况下，提一个问题是个好主意。在非严重的情况下，您不需要打扰他们在做什么；等待午餐时或在休息室进入他们的房间时做。

但是，如果错误的性质表明存在严重的误解（对实施平台，本地策略或项目规范），请尽快提出。

如果您不确定自己的评估，请要求他们审查您的修复程序，尤其是如果您不熟悉的代码中没有。（我强烈建议您的开发团队采用“代码伙伴”政策，无论如何，在签入之前，其他所有人均会审核所有更改。）

如果您不告诉他们会怎样？

缺点

他们可能在其他地方犯同样的错误，因为他们不知道这会导致问题。不仅如此，而且还会有多余的时间重复解决同一错误。您不会从自己没有意识到自己的错误中吸取教训。

第二，他们认为自己做得比以前更好。当人们没有意识到自己的问题时，很难以为自己在状况不佳时会表现出色。即使问题是一个粗心的错误，当人们意识到错误已被注意到时，人们也会做出更少的错误。

接下来，如果有人不问谁做的话，您怎么知道您是否有某个特别有问题的员工，要么总是粗心，要么对产品有基本的误解？负责任的人是否希望在与他或她相关联的团队中继续工作？

如果您确定并继续讨论而不进行讨论，那么您确定正确地对其进行了修正吗？有时，当需求改变时，测试也需要改变。如果这不是一个很小的错别字，您真的可以确定其中一个人有正确的解决方案吗？作为回报，您可能没有咨询就破坏了他的代码。

优点

人们不会因为指出自己的错误而感到尴尬或生气。

我想我不愿告诉他们，但要私下里很好地做。无需公开羞辱。如果此人反复犯同样的错误或犯了严重的错误，这些错误表明缺乏理解，那么还需要使主管有所了解。