我有一个同事最近离开我们公司。在离开之前，他对一个具有严重内存泄漏并导致生产中断的组件进行了编码（OutOfMemoryError使用Java）。问题本质上是一个HashMap增长且从未删除条目的问题，解决方案是将其替换HashMap为缓存实现。

从专业的角度来看，我认为我应该让他知道缺陷，以便他可以从错误中学习。另一方面，人们离开公司后，他们通常不想听到遗留在更大，更好的事情上的遗留项目。

这种情况的一般协议是什么？

您不会追捕一位前同事来告诉他他错了。您可以告诉您的朋友他犯了一个错误。

他是朋友还是以前的同事都取决于您。

没做什么。

1. 纯粹与某人联系以告诉他们他们搞砸了，但我们已解决，这是不专业的，无论您多么努力，都不太可能得到积极的回应。
2. 不管潜在的NDA问题如何，进行足够深入的讨论以使对话对于非雇员而言都对代码有用，这是不好的。

如果您在NDA之下，那么与公司外部的某个人就任何与IP相关的问题进行交谈是很大的禁忌，无论他们是否曾担任过员工。

如果您不在NDA之下，我敢说他/她不在乎。

除此之外，那个人是否不满？它实际上可能是故意的吗？

犯了一个简单的错误，即打扰同事的可能性很大，他们可能在几天后意识到这个问题时就意识到了这个问题。我知道我已经下班回家，意识到“ ....废话，该算法完全有缺陷，明天我将不得不重做”，同时放松并回想起我的一天。

这位同事是您的朋友，您离开后继续保持密切联系吗？如果是，请在酒吧喝啤酒时谈谈。

否则，何必呢？

PS .：关于NDA，这里的秘密是什么？X先生仍然是编写代码的人，如果离开的时间是最近的，则该软件将继续进行相同程度的披露。

如果这次谈话在离开后三年后发生，情况会有所不同，而你告诉他除了你他不需要知道的事情...

这取决于此人如何离开以及您与他/她的关系。

另外，您在乎什么？我看到您想帮助他“从错误中学习”，但是您真的吗？您要向他显示日志*和堆栈跟踪*吗？您要向他展示诊断问题的步骤吗？您要向他展示来源*，以便他看到问题出在哪里吗？

如果没有，那么您可能正在浪费他和您的时间。

*您是否会因为向非雇员披露公司资产/数据而遇到麻烦？

如果您决定告诉他，请确保也将他的代码告诉所有审阅者！他们同样负责！对我来说，听起来好像你没有和这个家伙相处，而是想向他挖个洞。随它去吧，他不太可能在乎。

可能不会

对我来说，无论是朋友还是同事，对我来说似乎都是毫无意义的。而且，在某些情况下，可能对他们，您以及您与他们的关系有害。

我们都会偶尔犯错误。

实际上，让我想告诉同事的唯一因素是：这是我知道他们通常不会做的错误/我知道他们会如何处理的情况吗？

如果答案是肯定的，则无需对它们进行调试，因为它们可能没有任何教育价值，因此我认为没有义务告知他们。如果您有一天碰到他们，或者计划在他们的最后一天喝酒，并且您与他们作为同龄人和专业人士之间保持着融洽的关系，那么可以肯定的是，您可以提一下，这比起其他任何事来养活一些友好或无害的玩笑。

如果答案是否定的，则可能有义务（虽然不会称其为“专业”）来帮助他们理解错误。

保持文明

一般而言，大多数人不喜欢批评他们的工作，开发人员/程序员更是如此，而离职的程序员的容忍度甚至更低。为什么要冒使他们烦恼的风险，给他们留下差劲的印象呢？

当然，如果他们一直都是糟糕的员工，那将不适用，但如果他们是其他技能娴熟的同伴，我不明白为什么我会竭力强调他们的错误，除非我可以确定都可以笑了。再一次，假设他们不会从中学到很多东西，只是因为丢下了他们而感到mort愧。

法律？

从不同的角度来看，如果他们离开了公司，那实际上取决于您的合同和公司的安全策略。您可能不被允许将代码（或其他事情）带给以前的同事。

往正面想

最后，我认为我与前同事讨论他们留下的代码库的唯一情况是：

• 在研究代码的特定区域时要求对某些不可靠的内容进行确认，
• 祝贺他们一些我精通的代码，如果没有，那会使我的生活变得更糟，
• 与他们分享成功发布的好消息（如果他们在事件发生之前就离开了）（或与他们曾经使用过的产品相关的类似重大公告）。

从错误中学习

您肯定可以做的是向团队其他成员指出错误，以确保其余成员不会再次发生此错误。无需指出SCM中的实际错误或作者，这不是怪罪游戏。

这超出了问题的范围，但是我仍然要指出，您应该确保纠正错误，记录错误的起因，影响和解决方案，并进行测试，以使其尽可能不再次出现。

告诉某人可能不合法。除非代码是开源的，否则请让无聊的狗撒谎。