Sto cercando un modo efficiente, che non venga considerato un insulto, per introdurre concetti OOP ai membri del team esistenti? I miei compagni di squadra non sono nuovi alle lingue OO. Facciamo C ++ / C # da molto tempo, quindi la tecnologia stessa è familiare.
Tuttavia, mi guardo intorno e senza una grande infusione di sforzi (principalmente sotto forma di revisioni del codice), sembra che ciò che stiamo producendo sia il codice C che si trova all'interno delle classi. Non c'è quasi alcun uso del principio di responsabilità singola, delle astrazioni o dei tentativi di minimizzare l'accoppiamento, solo per citarne alcuni. Ho visto classi che non hanno un costruttore ma ottengono memset su 0 ogni volta che vengono istanziate.
Ma ogni volta che faccio apparire OOP, tutti annuiscono sempre e fanno sembrare che sappiano esattamente di cosa sto parlando. Conoscere i concetti è buono, ma noi (alcuni più di altri) sembra che ci sia molto difficile applicarli quando si tratta di consegnare il lavoro reale.
Le revisioni del codice sono state molto utili, ma il problema con le revisioni del codice è che si verificano solo dopo il fatto, quindi ad alcuni sembra che finiamo per riscrivere (è principalmente refactoring, ma richiede ancora molto tempo) il codice che è stato appena scritto. Anche le revisioni del codice forniscono feedback solo a un singolo ingegnere, non all'intero team.
Sto giocando con l'idea di fare una presentazione (o una serie) e provo a richiamare OOP insieme ad alcuni esempi di codice esistente che potrebbero essere stati scritti meglio e potrebbero essere refactored. Potrei usare alcuni progetti molto vecchi che nessuno possiede più, quindi almeno quella parte non dovrebbe essere un problema delicato. Tuttavia, funzionerà? Come ho detto la maggior parte delle persone ha fatto C ++ per molto tempo, quindi la mia ipotesi è che a) si siederanno lì a pensare perché sto dicendo loro cose che già sanno eb) potrebbero effettivamente prenderlo come un insulto perché sono dicendo loro che non sanno come svolgere il lavoro che svolgono da anni se non da decenni.
Esiste un altro approccio che raggiungerebbe un pubblico più ampio rispetto a una recensione di codice, ma allo stesso tempo non sembrerebbe una lezione di punizione?
Non sono un ragazzo fuori dal college che ha ideali utopici di codice perfettamente progettato e non me lo aspetto da nessuno. Il motivo per cui sto scrivendo questo è perché ho appena fatto una recensione a una persona che in realtà aveva un design decente di alto livello su carta. Tuttavia, se immagini le classi: A -> B -> C -> D, nel codice B, C e D tutte implementano quasi la stessa interfaccia pubblica e B / C hanno una funzione di rivestimento in modo che la classe A più alta stia facendo assolutamente tutto il lavoro (fino alla gestione della memoria, analisi delle stringhe, negoziazioni di installazione ...) principalmente in 4 metodi mongo e, a tutti gli effetti, chiama quasi direttamente in D.
Aggiornamento: sono un capo tecnico (6 mesi in questo ruolo) e ho il pieno supporto del gestore del gruppo. Stiamo lavorando su un prodotto molto maturo e i costi di manutenzione si stanno sicuramente facendo conoscere.