Um colega de trabalho deixou nossa empresa recentemente. Antes de sair, ele codificou um componente que tinha um vazamento de memória grave que causava uma interrupção OutOfMemoryErrorna produção ( em Java). O problema era essencialmente um HashMapque crescia e nunca removia entradas, e a solução era substituí-la HashMappor uma implementação de cache.

Do ponto de vista profissional, acho que devo informá-lo sobre o defeito para que ele possa aprender com o erro. Por outro lado, uma vez que as pessoas saem de uma empresa, muitas vezes não querem ouvir sobre projetos herdados que deixaram para trás para coisas maiores e melhores.

Qual é o protocolo geral para esse tipo de situação?

Você não procura um ex-colega para dizer que ele cometeu um erro. Você pode dizer ao seu amigo que ele cometeu um erro.

Se ele é um amigo ou um ex-colega, é com você.

Fazer nada.

1. Entrar em contato com alguém apenas para dizer a eles que eles estragaram tudo, mas nós o consertamos não é profissional e não importa o quanto você tente, é improvável que seja recebido positivamente.
2. Falar com profundidade suficiente para que uma conversa seja remotamente útil sobre código para não funcionários é ruim, independentemente de possíveis problemas da NDA.

Se você está sob um NDA, é um grande não-não-falar com alguém de fora da sua empresa sobre quaisquer problemas relacionados à IP, sejam eles ex-funcionários ou não.

Se você não estiver sob uma NDA, arriscaria dizer que ele / ela não se importará.

Além disso, essa pessoa estava descontente? Era algo que realmente poderia ter sido intencional?

Com um erro tão simples, as probabilidades são boas se isso incomodou o colega de trabalho, eles provavelmente perceberam o problema alguns dias depois, enquanto refletiam sobre isso. Eu sei que voltei para casa do trabalho e percebi ".... porcaria, esse algoritmo é totalmente defeituoso, vou ter que refazê-lo amanhã", enquanto desenrola e relembra o meu dia.

Este colega de trabalho é seu AMIGO, e você continua tendo um contato próximo após a partida? Se sim, fale sobre isso se / quando você estiver tomando cerveja no bar.

Caso contrário, por que se preocupar?

PS: Na questão da NDA, qual é o segredo aqui? O Sr. X é quem escreveu o código de qualquer maneira e, se a saída for recente, o software continuará no mesmo nível de divulgação.

As coisas seriam diferentes se essa conversa acontecesse três anos após a partida e você dissesse coisas que ele não precisaria saber, exceto você.

Depende de como essa pessoa foi embora e do seu relacionamento com ela.

Além disso, com o que você se importa? Vejo que você quer ajudá-lo a "aprender com o erro", mas você está mesmo? Você vai mostrar a ele os logs * e o rastreamento de pilha *? Você vai mostrar a ele as etapas que você tomou para diagnosticar o problema? Você vai mostrar a fonte * para que ele possa ver onde estava o problema?

Caso contrário, provavelmente você está desperdiçando o tempo dele e o seu.

* Você terá problemas por divulgar os ativos / dados da empresa a um não funcionário?

Se você decidir contar a ele, não deixe de contar a todos os revisores do código dele também! Eles são igualmente responsáveis! Para mim, parece que você não se deu bem com esse cara e quer se interessar por ele. Deixa pra lá, é improvável que ele se importe.

Provavelmente não

Parece principalmente inútil para mim, sejam amigos ou colegas. E, em algumas circunstâncias, possivelmente prejudicial a eles, a você e ao seu relacionamento com eles.

Todos cometemos erros ocasionais.

De fato, o único fator que me faria querer dizer aos colegas é o seguinte: é um erro que eu sei que eles normalmente não fazem / uma situação que eu sei que eles sabem como lidar?

Se a resposta for sim, não há necessidade de incomodá-los, pois provavelmente não há valor educacional para eles, então não vejo o dever de informá-los. Se você se deparar com eles um dia ou planeja tomar alguma bebida no último dia e tiver um bom relacionamento com eles como colegas e colegas profissionais, com certeza, você poderia mencionar isso, mais para alimentar algumas brincadeiras amigáveis ​​ou inofensivas do que qualquer outra coisa.

Se a resposta for não, pode haver uma obrigação (embora não a chame de "profissional") de estender a mão e ajudá-los a entender seu erro.

Keep it Civil

A maioria das pessoas não gosta de críticas sobre seu trabalho em geral, os desenvolvedores / programadores ainda menos, e os programadores que sairiam provavelmente teriam uma tolerância ainda mais baixa. Por que correr o risco de irritá-los e dar a impressão de que eles deixam uma nota ruim?

Claro, se eles eram maus funcionários o tempo todo, isso não se aplica, mas se eles fossem colegas programadores suficientemente habilidosos, não vejo por que me esforçaria para enfatizar seus erros, exceto se posso ter certeza de que ambos podem rir disso. Novamente, supondo que eles não aprendessem muito com isso e apenas ficassem mortificados por terem deixado isso para trás.

Legal?

De um ângulo de abordagem diferente, se eles deixaram a empresa, isso realmente depende do seu contrato e das políticas de segurança da sua empresa. Talvez você não tenha permissão para levar o código (ou outras coisas, nesse caso) para ex-colegas.

Pense positivo

Por fim, acho que as únicas situações em que entrei em contato com o ex-colega para discutir uma base de código que eles deixaram para trás foram:

• para solicitar uma confirmação de algo obscuro ao pesquisar uma área específica do código,
• parabenizá-los por um pouco de código que achei particularmente magistral e que teria piorado minha vida se não estivesse lá,
• para compartilhar as boas notícias de um lançamento bem-sucedido se eles saírem antes do ocorrido (ou grandes anúncios semelhantes relacionados a um produto em que costumavam trabalhar).

Aprenda com seus erros

O que você certamente pode fazer é apontar o erro para o restante da equipe, para garantir que ele não ocorra novamente com os membros restantes. Não há necessidade de apontar para o erro real no SCM ou para o autor, não é um jogo de culpa.

Está fora do escopo da pergunta, mas eu ainda gostaria de salientar que você deve corrigir o erro, documentar suas origens, impactos e resoluções e implementar um teste para que ele não apareça novamente, se possível.

Pode não ser legal contar a alguém. A menos que o código seja de código aberto, deixe os cães adormecidos mentirem.