Sto mettendo questa domanda ai programmatori C ++ perché: a) Solo un programmatore C ++ può giudicare i meriti tecnici degli esempi; b) Solo un programmatore avrà un'idea del temperamento di un altro programmatore che scrive un codice come questo.
Le risorse umane e gli amministratori sono consapevoli che c'è un problema semplicemente perché vedono le prove sul campo. La mia chiamata è se diamo più tempo al programmatore in questione. Molti degli errori sono a un livello molto basilare - la mia domanda (ai programmatori) è se qualcuno che professa di essere uno sviluppatore C ++ di alto livello dovrebbe avere il beneficio di un dubbio sulla base di campioni del loro codice corrente. I non programmatori, anche persone esterne alla programmazione in C ++, non possono dare alcun giudizio su questo.
Per motivi di background, mi è stato assegnato il compito di gestire gli sviluppatori per un'azienda consolidata. Hanno un singolo sviluppatore specializzato in tutto il codice C ++ (da sempre), ma la qualità del lavoro è pessima. Le revisioni del codice e i test hanno rivelato molti problemi, uno dei peggiori dei quali è la perdita di memoria. Lo sviluppatore ha mai testato il suo codice per perdite, e ho scoperto che le applicazioni potevano perdere molti MB con solo un minuto di utilizzo. Gli utenti segnalavano enormi rallentamenti e la sua versione era "non ha niente a che fare con me - se smettono e ricominciano, va tutto bene di nuovo".
Gli ho dato strumenti per rilevare e rintracciare le perdite, e mi sono seduto con lui per molte ore per dimostrare come vengono utilizzati gli strumenti, dove si verificano i problemi e cosa fare per risolverli. Siamo 6 mesi in pista, e l'ho assegnato per scrivere un nuovo modulo. L'ho rivisto prima che fosse integrato nella nostra più ampia base di codice ed ero costernato nello scoprire la stessa cattiva codifica di prima. La parte che trovo incomprensibile è che alcuni dei codici sono peggiori di quelli amatoriali. Ad esempio, voleva una classe (Foo) che potesse popolare un oggetto di un'altra classe (Barra). Decise che Foo avrebbe tenuto un riferimento a Bar, ad esempio:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};
Ma (per altri motivi) ha anche bisogno di un costruttore predefinito per Foo e, piuttosto che mettere in discussione il suo progetto iniziale, ha scritto questo gioiello:
Foo::Foo() : m_bar(*(new Bar)) {}
Quindi ogni volta che viene chiamato il costruttore predefinito, viene fatta trapelare una barra. A peggiorare le cose, Foo alloca la memoria dall'heap per altri 2 oggetti, ma non ha scritto un distruttore o un costruttore di copie. Quindi ogni allocazione di Foo in realtà perde 3 oggetti diversi, e puoi immaginare cosa è successo quando è stato copiato un Foo. E - migliora solo - ha ripetuto lo stesso schema su altre tre classi, quindi non è una scivolata unica. L'intero concetto è sbagliato su così tanti livelli.
Mi sentirei più comprensivo se venisse da un principiante totale. Ma questo ragazzo lo fa da molti anni e negli ultimi mesi ha ricevuto una formazione e dei consigli molto mirati. Mi rendo conto che ha lavorato senza mentori o revisioni tra pari la maggior parte di quel tempo, ma sto iniziando a sentire che non può cambiare. Quindi la mia domanda è: vorresti insistere con qualcuno che sta scrivendo un codice così palesemente cattivo?