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

#1 楼

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

另一方面，除非更改是完全无关紧要的，而且显然是错误的，否则我通常会发现与最初更改的人交谈是有益的我的调查只是为了确保我完全了解正在发生的事情，因此，我通常最终处理这些情况的方式是转到所述人员并进行类似于以下的对话：


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


然后：


他们：好的，那就可以处理……情况我没意识到...


或者类似的东西：


他们：不，对不起，我不记得了，看起来对我来说是错误的。


通过一起调查变更/错误，原始提交者可以从错误中学习，而不会感到被批评*，而且

如果原始提交者不在身边或很忙，那么您可以自己摸索并自己弄清楚这一切，我通常会发现与最初进行更改的人更快。

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

#2 楼

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

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

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

#3 楼

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

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

#4 楼

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

如果涉及向人们解释如何不引入错误，请继续尝试。

我曾经在一个团队中工作，项目经理从未告诉过某个特定的开发人员他犯了一个错误：他与整个团队一起组织了一次会议，在会议上他解释说犯了一个错误并且已经建立了新的流程为了抑制这种错误而定义。这样，没人会受到侮辱。

#5 楼

一般来说，是的。

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

如果这是一个很大的变化，而不仅仅是错别字，这是一个好主意，让您在尝试修复它之前先引起注意。 “乔，我昨天正在合并自己的东西，发现不确定自己是否理解。看起来像是个错误，但是在弄乱您的代码之前，我想由您运行它。您能否看一下我？”

您与作者的关系是一个很大的因素。如果您不介意作者不告诉您修改代码，并且您确定这种感觉是相互的，那可能就不值得一提了。如果是具有更多经验/高级/状态的人员，则需要让他们知道您将要更改他们的代码。如果是少一些的人，请考虑这是他们需要听到的东西，以避免重蹈覆辙，否则可能会使他们不必要地感到尴尬。 “错误”，他们可以轻松地找出谁“修复”了他们的代码。如果您认为他们在事后发现自己的变化会感到沮丧/烦恼/尴尬，请务必事先告知他们。

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

#6 楼

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

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

#7 楼

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

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

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

她

通常情况下，错误是我的，她也知道。
那是技巧。

#8 楼

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

我的软件工程经验告诉我如何拥有我所有的代码更改，而不仅仅是我负责的项目，一直到生产，包括意识到它们的影响，包括对您的构建系统和（显然）产品行为的影响。

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

#9 楼

很好的牵引您的问题！所有人都告诉你该怎么做。你应该告诉吗？是！每当问题问“我需要更多交流吗？”时，答案几乎总是肯定的！

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


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


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

一定要让您的同事参与到此修复中，并进行测试以确保它不可能再次发生。你们都是英雄！但是，如果您在言语或行动上不加任何责备，则您有责任使最严重的组织疾病之一永存：问责而不负责。提交了破坏了原始代码的代码，并给您毫无戒心的伙伴留下了陷阱（显然没有足够的测试范围）。希望不是你！

#10 楼

总是把别人视为比你更好的人，总是看到别人的良好品格，也总是知道我也会犯错。

当只有你们两个时，告诉他们。

#11 楼

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

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

#12 楼

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

#13 楼

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

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

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

我通常发现，从恭维开始，效果最佳然后发现错误...类似“您实施的修复效果很好，但似乎x，y，z损坏了”，或“感谢您进行a，b，c，但似乎导致了x ，y，z“

#14 楼

简单的答案：是的。

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

并不总能抓住一切；对我们来说很糟糕，我们没有执行代码覆盖范围，即使单元测试或集成测试涵盖了某些内容，他们也可能无法充分利用该代码。当发生这种情况时，负责解决已知问题（如果质量检查人员发现了问题）或缺陷（如果客户是dun-dun-dun的话）的任何人都将受到“指责”（显示谁最后修改了某行的每一行）代码文件）并确定罪魁祸首。

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

#15 楼

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

#16 楼

有很多因素在起作用。


该错误严重程度如何？
您和断路器之间的资历关系是什么？
团队有多忙/压力？
断路器是在代码库的一部分中工作还是在您的代码库中工作？
您如何确定这确实是一个错误，以及您如何确定自己的修复正确？ >如果问题很小（错别字/ thinko /剪切和粘贴错误），并且断路器是忙碌的同伴，并且您对问题的评估充满信心，则可能无需引起他们的注意。 （例如foo.x = bar.x; foo.y = bar.y, foo.z = bar.y）。

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

如果错误的性质表明存在严重的误解（对实施平台，本地政策或项目规范），但是，请尽快对其进行修正。 （我强烈建议您的开发团队采用“代码伙伴”政策，无论如何，所有更改都必须在签到之前由其他人进行审核。）

#17 楼

如果您不告诉他们怎么办？

缺点

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

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

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

如果您不讨论而进行固定和继续操作，确定会正确吗？有时，当需求改变时，需要改变测试。如果这不是一个非常小的错别字，您真的可以确定其中一个人有正确的解决方案吗？您可能会在没有咨询的情况下破坏他的代码。

专业人士

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

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