Come convincere i "vecchi" collaboratori nel merito di OO per determinate applicazioni [chiuso]

Penso che la tua domanda vada oltre una qualche spiegazione magica sul perché OO sia migliore. In realtà, questa domanda è già stata posta su questo sito.

Hai commesso un errore di gestione. Non puoi prendere un argomento complesso, fare un po 'di allenamento minimo senza follow-up o management buy-in e pensare che farai cambiare la gente nel modo in cui fanno le cose quando non ci sono incentivi immediati.

Ci saranno revisioni del codice che hanno il supporto della gestione per iniziare a fornire conseguenze negative per non rispettare? A che punto sarà inaccettabile controllare il codice che non viene eseguito in OOP quando appropriato?

Sarà offerta una formazione aggiuntiva? Sarà offerto più tempo per completare alcune attività? Uno dei vantaggi di OOP è quello di aiutare a mantenere un codice complesso. Ci vorrà più tempo per scrivere. Chi è disposto a rallentare lo sviluppo attuale nella speranza di limitare il debito tecnico?

Mi piace imparare cose nuove, ma richiedono tempo e non vengono immediatamente visualizzate nel codice di produzione per il mio lavoro. Ci sono occasioni in cui posso fare un passo indietro e valutare quello che sto facendo e progettare una soluzione migliore. A volte, c'è qualcuno che guarda costantemente dietro le tue spalle per spegnere un incendio e le ultime novità più belle devono stare nella scatola.

Non arrenderti! Concentrati su alcuni dei primi utenti. Trova un nuovo pezzo di codice per scrivere e fare squadra con tutti e vedere se puoi progettarlo in modo diverso. Non preoccuparti se non entrerà mai in produzione, stanno imparando.

Alla fine, saranno costretti a rivisitare il codice progettato con più principi OOP e potranno finalmente vedere quanto è più facile lavorare, eseguire il debug e espandere. Ci vorrà tempo e tempo è molto prezioso.

Sono sicuro che questo non è ciò che vuoi sentire, ma non puoi . Il meglio che puoi fare è scrivere il tuo codice in modo OO (quando è appropriato) e rifattorizzare il codice in qualcosa OO (di nuovo, se necessario). Alcuni di loro ti vedranno muovere più velocemente e diventare interessati; la maggior parte non lo farà. Scrivi il miglior codice che puoi e concentrati sulla formazione di nuovi assunti. I vecchi temporizzatori andranno in pensione o, in caso contrario, verranno espulsi.

Considerando che l'anno è il 2016, e questi ragazzi non sono ancora passati alla programmazione orientata agli oggetti, ci sono due possibilità: o non vogliono cambiare, o c'è qualche motivo tecnico che non sai di questo impedisce loro di cambiare.

In ogni caso, tu non puoi convincerli.

Si dovrebbe chiedere se hanno obiezioni contro il nuovo codice scritto come codice orientato agli oggetti. Può esserci la ragione tecnica per cui è difficile o impossibile mescolare oggetti orientati agli oggetti e non orientati agli oggetti.

Questo è simile alle altre risposte, ma quello che ho visto è che fondamentalmente ci sono due tipi di sviluppatori: gli sviluppatori che continuano ad apprendere nuovi strumenti e valutano come potrebbero essere utili e gli sviluppatori che apprendono un approccio e lo seguono. Il motivo per cui questo sembra essere correlato all'età è che i nuovi sviluppatori in genere impareranno lo stato attuale dell'arte indipendentemente da quale di queste due categorie rientrino. La chiave è cosa succede dopo. In 2, 5, 10 anni stanno ancora usando gli stessi strumenti e approcci? L'altro fattore legato all'età è che gli sviluppatori che rientrano nel primo campo spesso hanno l'opportunità di trasferirsi in altri ruoli dove non lo sono quelli del secondo campo. Ci sono alcuni sviluppatori che continuano a imparare e scelgono di seguire lo sviluppo. Se sei un nuovo sviluppatore e hai la fortuna di lavorare con queste persone, prova a farle da mentore.

Probabilmente ci sono molte persone che non cambieranno il modo in cui fanno le cose, non importa cosa. Hanno investito molto tempo diventando esperti negli strumenti che usano. Passare a un nuovo strumento non familiare li mette in svantaggio e al di sotto del livello dei ragazzi mocciosi che hanno lavorato per un anno. Alcuni potrebbero essere aperti se puoi dimostrare come queste tecniche li aiutano. Se non aiutano, è perfettamente razionale non cambiare. Ci sono state molte nuove idee "calde" che sono andate e venute nella mia carriera e sono abbastanza felice di averle ignorate.

Quindi il risultato è che dovresti provare a loro e a te stesso che queste tecniche sono effettivamente superiori. Questo è ciò che fa un professionista serio.