Sto cercando un modo efficace, che non sia considerato un insulto, per introdurre i concetti OOP ai membri del team esistenti? I miei compagni di squadra non sono nuovi alle lingue OO. Abbiamo fatto C ++ / C # per 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 quello che stiamo producendo sia il codice C che si trova all'interno delle classi. Non c'è quasi alcun uso di principi di responsabilità singola, astrazioni o tentativi di minimizzare l'accoppiamento, solo per citarne alcuni. Ho visto classi che non hanno un costruttore ma ottengono memset a 0 ogni volta che vengono istanziati.
Ma ogni volta che apro OOP, tutti annuiscono e fanno sembrare che sappiano esattamente di cosa sto parlando. Conoscere i concetti è buono, ma noi (alcuni più di altri) sembrano averli molto difficili da applicare quando si tratta di fornire un lavoro reale.
Le recensioni di codice sono state molto utili, ma il problema con le revisioni del codice è che si verificano solo dopo il fatto, così a qualcuno sembra che finiamo per riscrivere (è per lo più refactoring, ma richiede ancora molto tempo) il codice appena scritto. Anche le revisioni del codice danno solo feedback ad un singolo ingegnere, non all'intero team.
Sto giocando con l'idea di fare una presentazione (o una serie) e provare a far apparire di nuovo OOP insieme ad alcuni esempi di codice esistente che avrebbe potuto essere scritto meglio e potrebbe essere refactored. Potrei usare alcuni progetti davvero vecchi che nessuno possiede più quindi almeno quella parte non dovrebbe essere un problema delicato. Tuttavia, funzionerà? Come ho detto molte persone hanno fatto C ++ per molto tempo quindi la mia ipotesi è che a) si siederanno lì pensando perché sto dicendo loro cose che già conoscono o b) potrebbero effettivamente prenderlo come un insulto perché io sono dicendo loro che non sanno come fare il lavoro che stanno facendo da anni se non da decenni.
Esiste un altro approccio che raggiungerebbe un pubblico più ampio rispetto a una revisione del codice, ma allo stesso tempo non sembrerebbe una lezione di punizione?
Non sono un bambino appena uscito dal college che ha degli 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 di una persona che in realtà aveva un design decente di alto livello su carta. Tuttavia, se visualizzi le classi: A - > B - > C - > D, nel codice B, C e D tutti implementano quasi la stessa interfaccia pubblica e B / C ha una funzione di linea in modo che la massima classe A stia facendo tutto il lavoro (fino alla gestione della memoria, analisi delle stringhe, negoziazione delle impostazioni. ..) principalmente in 4 metodi mongo e, a tutti gli effetti, chiama quasi direttamente in D.
Aggiornamento: sono un lead tecnologico (6 mesi in questo ruolo) e ho il pieno supporto del group manager. Stiamo lavorando a un prodotto molto maturo e i costi di manutenzione si stanno definitivamente facendo conoscere.