Je pose cette question aux programmeurs C ++ parce que: a) Seul un programmeur C ++ peut juger des mérites techniques des exemples; b) Seul un programmeur aura une idée du tempérament d'un autre programmeur qui écrit du code comme celui-ci.
Les RH et les administrateurs sont conscients qu'il y a un problème simplement parce qu'ils voient des preuves sur le terrain. C'est mon appel si nous donnons plus de temps au programmeur en question. Beaucoup d'erreurs sont à un niveau très basique - ma question (aux programmeurs) est de savoir si quelqu'un qui prétend être un développeur C ++ senior devrait bénéficier d'un doute basé sur des exemples de leur code actuel. Les non-programmeurs - même les personnes en dehors de la programmation C ++ - ne peuvent pas porter de jugement à ce sujet.
Pour le fond, on m'a confié la tâche de gérer les développeurs pour une entreprise bien établie. Ils ont un seul développeur spécialisé dans tous leurs codages C ++ (depuis toujours), mais la qualité du travail est épouvantable. Les examens et les tests de code ont révélé de nombreux problèmes, l'un des pires étant les fuites de mémoire. Le développeur n'a jamais testé son code pour les fuites, et j'ai découvert que les applications pouvaient fuir de nombreux Mo avec seulement une minute d'utilisation. L'utilisateur signalait d'énormes ralentissements, et sa conclusion était: "cela n'a rien à voir avec moi - s'ils arrêtent et redémarrent, tout recommence."
Je lui ai donné des outils pour détecter et localiser les fuites, et je me suis assis avec lui pendant plusieurs heures pour montrer comment les outils sont utilisés, où les problèmes se produisent et ce qu'il faut faire pour les corriger. Nous sommes 6 mois plus tard, et je lui ai confié la rédaction d'un nouveau module. Je l'ai examiné avant qu'il ne soit intégré à notre base de code plus large, et j'ai été consterné de découvrir le même mauvais codage qu'auparavant. La partie que je trouve incompréhensible est qu'une partie du codage est pire que l'amateurisme. Par exemple, il voulait une classe (Foo) qui pourrait remplir un objet d'une autre classe (Bar). Il a décidé que Foo détiendrait une référence à Bar, par exemple:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
Mais (pour d'autres raisons), il avait également besoin d'un constructeur par défaut pour Foo et, plutôt que de remettre en question sa conception initiale, il a écrit ce joyau:
Foo::Foo() : m_bar(*(new Bar)) {}Ainsi, chaque fois que le constructeur par défaut est appelé, une barre est divulguée. Pour aggraver les choses, Foo alloue de la mémoire à partir du tas pour 2 autres objets, mais il n'a pas écrit de destructeur ou de constructeur de copie. Donc, chaque allocation de Foo fait réellement fuir 3 objets différents, et vous pouvez imaginer ce qui s'est passé quand un Foo a été copié. Et - ça ne fait que s'améliorer - il a répété le même schéma sur trois autres classes, donc ce n'est pas un glissement unique. L'ensemble du concept est erroné à tant de niveaux.
Je me sentirais plus compréhensif si cela venait d'un novice total. Mais ce gars fait cela depuis de nombreuses années et a reçu une formation et des conseils très ciblés au cours des derniers mois. Je me rends compte qu'il a travaillé sans mentorat ni examen par les pairs la plupart du temps, mais je commence à sentir qu'il ne peut pas changer. Donc ma question est, persisteriez-vous avec quelqu'un qui écrit un code aussi mauvais?