Estou fazendo esta pergunta aos programadores de C ++ porque: a) Somente um programador de C ++ pode julgar os méritos técnicos dos exemplos; b) Somente um programador sentirá o temperamento de outro programador que escreve código como este.
O RH e os diretores estão cientes de que há um problema simplesmente porque veem evidências em campo. É minha decisão se damos mais tempo ao programador em questão. Muitos dos erros estão em um nível muito básico - minha pergunta (para programadores) é se alguém que professa ser um desenvolvedor sênior de C ++ deve receber o benefício de uma dúvida com base em exemplos de seu código atual. Não programadores - mesmo pessoas fora da programação C ++ - não podem julgar isso.
Como pano de fundo, me foi atribuída a tarefa de gerenciar desenvolvedores de uma empresa bem estabelecida. Eles têm um único desenvolvedor especializado em toda a sua codificação C ++ (desde sempre), mas a qualidade do trabalho é péssima. Revisões e testes de código revelaram muitos problemas, sendo um dos piores vazamentos de memória. O desenvolvedor nunca testou seu código quanto a vazamentos, e eu descobri que os aplicativos poderiam vazar muitos MBs com apenas um minuto de uso. Os usuários estavam relatando grandes lentidões, e sua opinião foi: "não tem nada a ver comigo - se eles pararem e reiniciarem, tudo ficará bem novamente".
Dei a ele ferramentas para detectar e rastrear os vazamentos e sentei-me com ele por muitas horas para demonstrar como as ferramentas são usadas, onde os problemas ocorrem e o que fazer para corrigi-los. Estamos 6 meses no caminho, e eu o designei para escrever um novo módulo. Eu a revisei antes de ser integrada à nossa base de código maior e fiquei consternada ao descobrir a mesma codificação incorreta de antes. A parte que considero incompreensível é que parte da codificação é pior que amador. Por exemplo, ele queria uma classe (Foo) que pudesse preencher um objeto de outra classe (Bar). Ele decidiu que Foo manteria uma referência a Bar, por exemplo:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
Mas (por outras razões) ele também precisava de um construtor padrão para Foo e, em vez de questionar seu design inicial, ele escreveu esta jóia:
Foo::Foo() : m_bar(*(new Bar)) {}Portanto, toda vez que o construtor padrão é chamado, uma barra vaza. Para piorar a situação, Foo aloca memória do heap para outros 2 objetos, mas ele não escreveu um destruidor ou construtor de cópias. Portanto, toda alocação de Foo realmente vaza 3 objetos diferentes, e você pode imaginar o que aconteceu quando um Foo foi copiado. E - só melhora - ele repetiu o mesmo padrão em três outras aulas, portanto não é um deslize único. Todo o conceito está errado em muitos níveis.
Eu sentiria mais compreensão se isso viesse de um novato total. Mas esse cara faz isso há muitos anos e tem recebido treinamento e conselhos muito focados nos últimos meses. Sei que ele trabalhou sem orientação ou avaliação por pares a maior parte do tempo, mas estou começando a achar que ele não pode mudar. Então, minha pergunta é: você persistiria com alguém que está escrevendo um código tão obviamente ruim?
fonte
Respostas:
Meu conselho seria confrontá-lo com esse exemplo em particular e ver o que ele diz. Se ele negar que haja algo ruim com o código, receio que haja pouco que você possa fazer. Se ele aceita que cometeu um erro (mesmo que seja defensivo), pelo menos há espaço para melhorias. Se você aceitar o tempo e o esforço para melhorá-lo, você ou um programador sênior precisará sentá-lo e codificar juntos até que todas essas tendências sejam achatadas (esteja preparado para dedicar essa pessoa por pelo menos 1 mês).
Um programador ruim, com quem normalmente posso trabalhar, mas um programador que não pode melhorar, eu não posso.
fonte
Não. Eu acionaria qualquer desenvolvedor profissional de C ++ que não tivesse o entendimento básico do gerenciamento de memória.
Se é alguém vindo de Java ou C # ou algo assim, eu daria a eles alguma latitude, mas isso é pura incompetência.
fonte
Não podemos responder à parte mais ampla da sua pergunta. Ou seja, você deve reter ou demitir esse funcionário. Demitir um funcionário é difícil, mas essa é uma decisão fora do alcance de uma comunidade como essa.
Você atualizou sua pergunta para restringir as respostas aos programadores de C ++. Para meus conhecimentos / qualificações: cortei os dentes em C e posso codificar em C ++, C # e Java. E eu gosto de perseguir as condições de corrida entre os tópicos porque acho divertido. Sim, eu "fico" mexendo um pouco.
Sua resposta e decisão envolvem isso: se alguém pode ou não mudar depende do indivíduo e se ele quer mudar.
Mas vamos começar com algumas perguntas suas:
Você precisa ter certeza de que pode dizer sim a todas essas perguntas. Caso contrário, ainda há um ônus da prova de sua parte por se comunicar com ele.
A resposta dele à sua revisão recente será a parte mais reveladora.
Se ele está tentando e mostra alguns sinais de progresso, talvez seja necessário revisar seu processo de orientação. Se for o caso, talvez você deva considerar emparelhá-lo com um programador mais experiente, para que ele possa obter um feedback imediato enquanto toma decisões de design. Não sou fã de programação em pares, mas pode ser muito útil em um caso como este. Enviá-lo continuamente para fazer mais e mais revisões no código antigo nem sempre é um caminho prático para o aprendizado.
Se ele não estava tentando, então você precisa entender melhor a motivação dele. Ele não entendeu que precisava se esforçar mais? Ele simplesmente não se importa? Existem outras áreas da equipe em que suas habilidades seriam mais adequadas e ele está mais interessado nisso? Se ele não quis tentar, então você precisa entender o porquê.
A partir daí, você saberá se ele quer mudar e se pode mudar. Nenhum desejo de mudar é equivalente a não ser capaz de mudar. Se houver desejo e um certo grau de progresso, considere fortemente mudar como você está tentando reabilitá-lo.
fonte
Receio que seu código incorreto não seja o único problema em sua equipe.
Você diz que ele está na empresa há um longo período de tempo. Demitir essa pessoa raramente é uma boa ideia (a menos que ele seja um funcionário do tipo Wally). O conhecimento deles sobre as necessidades dos clientes, produtos que você possui etc. geralmente é muito mais valioso do que o código que eles escrevem.
Soluções:
fonte
Tomar uma decisão de demitir alguém é uma decisão difícil para alguém. Sua situação é composta por vários fatores:
Dito isto, você passou os últimos 6 meses mostrando ao desenvolvedor o erro de suas maneiras e seu novo código ainda não melhorou.
Nesta fase, você realmente precisa iniciar um gerenciamento proativo para que, dentro de três meses, tenha
ou
Para fazer isso, embora você precise se sentar com o desenvolvedor, explique o que há de errado por escrito / e-mail, explique como o desenvolvedor pode melhorar e muito claramente afirme que, se a melhoria esperada não se concretizar, ele será encerrado em 3 meses.
Você também precisa deixar bem claro que a melhoria é esperada a partir deste momento para o resto de seu emprego na empresa e não apenas para o período de 3 meses!
Você também deve informar seu próprio gerente e o Departamento de RH (se houver).
Durante esse processo, você terá que gerenciar ativamente o desenvolvedor e revisar as tarefas / códigos a cada 1-2 dias e garantir que estejam atualizados, detalhando aqueles que não o são e explicando o que pode ser feito para melhorá-los.
fonte
Ou você não tem sido claro sobre a seriedade com a mão de obra dele (ou seja, é possível que ele veja quanto tempo você passou com ele como uma opção, se ele quer melhorar, em vez de uma necessidade absoluta), ou ele tem uma experiência incrivelmente ruim. atitude insustentável. Se ainda não está claro para esse desenvolvedor que você está considerando a posição dele sobre esse problema, ele precisa ser explicitado (supondo que sua liderança esteja de acordo com sua autoridade para terminar). Esperamos que o choque traga mudanças.
A decisão de emprego tem implicações muito mais amplas do que apenas esse cara; você precisa considerar o impacto sobre a equipe. Se for permitido que sua atitude prospere, ela pode ressentir-se dos outros ou fazer com que outros sintam que esse tipo de coisa também está bem. Do ponto de vista da equipe, é preciso que fique absolutamente claro que, se ele foi, foi pelas razões certas e teve ampla oportunidade de melhorar.
Uma jóia que eu peguei em um curso anos atrás é o fato de que pessoas com conhecimento técnico que outras pessoas não têm podem liderar o gerenciamento para dar folga. É ruim para o time. Você pode ter medo de perder o único desenvolvedor de c ++, mas eles podem ser substituídos. Obviamente, existem riscos inerentes se ele conhece bem os produtos lançados, mas muitas vezes vi pessoas com conhecimento técnico / produto aparentemente insubstituível serem substituídas com mais facilidade do que o previsto. Equipes e organizações geralmente podem preencher lacunas que inicialmente parecem difíceis de preencher. É claro que se ele não possui habilidades em c ++ ou conhecimento específico da organização que você acha que será difícil de substituir, há muito menos problema!
fonte
Claro que não deveria. Lembre-se, isso não é uma instituição de caridade, você está trocando dinheiro por trabalho. Se ele não está sustentando seu lado do acordo, como qualquer transação, eu pararia de pagar.
fonte
Se você quiser dar uma chance a ele, desenvolva um teste padronizado que reúna métricas sobre vazamento de memória. Monitore seu progresso semanalmente, insistindo em ver o código que ele mudou e procure melhorias. Se ele não conseguir, naquele momento, demitir o invectivo inútil.
fonte