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?