Suggerimenti su come diffondere pratiche orientate agli oggetti [chiuso]

Lavoro per una media azienda che ha circa 250 sviluppatori. Sfortunatamente, molti di loro sono bloccati in un modo di pensare procedurale e alcuni team forniscono costantemente grandi applicazioni di script transazionali , quando in realtà l'applicazione contiene una ricca logica. Inoltre non riescono a gestire le dipendenze di progettazione e finiscono con servizi che dipendono da un altro gran numero di servizi (un chiaro esempio di Big Ball of Mud ).

La mia domanda è: puoi suggerire come diffondere questo tipo di conoscenza?

So che la superficie del problema è che queste applicazioni hanno un'architettura e un design scadenti. Un altro problema è che ci sono alcuni sviluppatori che sono contrari a scrivere qualsiasi tipo di test.

Alcune cose che sto facendo per cambiarlo (ma sto fallendo o il cambiamento è troppo piccolo lo sono)

• Esecuzione di presentazioni sui principi di progettazione (SOLID, codice pulito, ecc.).
• Workshop su TDD e BDD.
• Coaching team (questo include l'utilizzo di sonar, findbugs, jdepend e altri strumenti).
• Colloqui IDE e refactoring.

Alcune cose che sto pensando di fare in futuro (ma sono preoccupato che potrebbero non essere buone)

• Formare un team di evangelisti OO, che diffondono un modo di pensare OO in team diversi (queste persone dovrebbero cambiare team ogni pochi mesi).
• Esecuzione di sessioni di revisione del design, per criticare il design e suggerire miglioramenti (anche se i miglioramenti non vengono apportati a causa di vincoli di tempo, penso che ciò potrebbe essere utile)

.

Qualcosa che ho trovato con le squadre che alleno, è che non appena le lascio, tornano alle vecchie pratiche. So di non passare molto tempo con loro, di solito solo un mese. Quindi qualunque cosa stia facendo, non si attacca.

Mi dispiace che questa domanda sia macchiata di frustrazione, ma l'alternativa per scrivere questo è stato di colpire la mia testa sul muro fino a quando non sono svenuto.

Non provare a spingere OOP, non farà che peggiorare le cose. Non perché OOP sia una cattiva idea in generale: non lo è. Ma perché sembra che chiunque sia responsabile di quel codice hairball non solo non abbia gli strumenti per evitare questi problemi, ma anche l'esperienza e, soprattutto, la motivazione.

Le persone che hanno il desiderio di scrivere codice pulito lo faranno in ogni dato paradigma, sia OOP, procedurale, funzionale, ecc. Ma non tutti i programmatori sono così, e se spingi qualsiasi strumento di codice pulito su persone che non lo fanno capire la necessità, finirai con questi strumenti abusati proprio come gli strumenti che sono già lì. Vedrai metodi non correlati raggruppati in una classe, classi che ereditano da classi non correlate, set di visibilità dei metodi basato sul debug di tentativi ed errori piuttosto che sulla progettazione consapevole, metodi statici che non dovrebbero essere metodi statici e non statici che dovrebbero, in breve , perderai tempo.

Invece, vedi se riesci a investire nell'aumentare la consapevolezza per la manutenibilità e l'eleganza. Dopotutto, gli obiettivi principali di OOP non sono diversi da qualsiasi altra strategia di gestione della complessità (che è ciò su cui si basano realmente i paradigmi di programmazione): incapsulamento, modulatizzazione, accoppiamento lento, basso grado di interdipendenza, mantenimento dello stato mutevole e il suo scopo di un minimo, ecc. ecc. OOP non è certamente l'unico paradigma che ti offre gli strumenti di cui hai bisogno per raggiungere questo obiettivo.

Il che mi porta all'ultimo punto: OOP è un'ottima idea, e funziona bene per alcuni tipi di problemi, ma (e sto parlando sia dalla mia stessa esperienza che parafrasando l'opinione di alcune grandi menti qui) per molti tipi di problemi, è completamente inadatto. Quando sei nuovo in OOP, e il codice spaghetti semi-procedurale è l'unica alternativa che conosci, OOP appare naturalmente come un dono dal cielo (e in un modo relativo, lo è), e probabilmente ti avvicinerai tutti i problemi come chiodi per il tuo martello OOP. È solo naturale e guidare OOP verso (e oltre) i suoi limiti è un buon modo per sviluppare le tue abilità OOP, quindi non è tutto negativo. Ma forse (solo forse) questo particolare codebase non ha bisogno di OOP dopo tutto. Forse trarrebbe molto più beneficio da un'architettura procedurale,

TL; DR: Se vuoi evangelizzare qualcosa, lascia che siano buone pratiche di codifica (indipendente dalla piattaforma), non alcun particolare paradigma o metodologia.

Non puoi far cambiare nessuno a chi non vuole già cambiare. Ecco perché le squadre che hai allenato sono tornate ai loro vecchi modi.

Quindi davvero, la tua domanda dovrebbe essere "come faccio a far sì che gli sviluppatori vogliano cambiare agli approcci OO?"

Inizia in modo semplice, inizia in piccolo, lascia che le cose si costruiscano da lì. Mostra i vantaggi per il singolo sviluppatore anziché i vantaggi astratti o filosofici per il codice, altri sviluppatori o l'azienda.

Mostra come le varie tecniche OO porteranno a meno codice che devono scrivere e a tempi di sviluppo più rapidi. Quasi tutti gli sviluppatori ascolteranno una proposta che renderà il loro lavoro più semplice.

Quindi iniziare a dimostrare come le tecniche OO porteranno a un codice più facilmente gestibile. Tutti in quel tipo di ambiente vivono nella paura di fare " il cambiamento " che cancella un terzo dell'applicazione di produzione. L'incapsulamento è la chiave per evitare questo rischio e consente a ciascun livello (che sarà presto) dell'applicazione di mantenere il proprio contratto con gli altri livelli.

Vorrei vedere come vengono trasmessi i dati. Se è una lunga lista di variabili ogni volta, considera di racchiuderne alcune all'interno di una struttura (o boccheggiare! Una classe !!!) come passaggio preliminare. Il semplice avvolgimento dei dati all'interno di un oggetto è l'inizio dei contratti tra i livelli.

A un livello più ampio - considera di ottenere il buy-in della gestione per questo sforzo se non l'hai già fatto. Il management ha bisogno di vedere i benefici concreti di una diminuzione dei difetti e un minor rischio di apportare modifiche. Alla fine, il processo di refactoring dovrebbe portare a tempi di sviluppo più rapidi, ma questo è un vantaggio a lungo termine.

Le tue idee di gruppi di revisione ed evangelisti OO sono buone. Deve essere più di te che stai promuovendo questo programma.

La mia esperienza è che il passaggio dalla mentalità procedurale alla mentalità OO è un grosso ostacolo. Richiede perseveranza che molti sviluppatori non riescono a sopportare. Ciò è dovuto principalmente al fatto che i fondamenti di OO vengono controllati.

Formare un team di evangelisti OO, che diffondono un modo di pensare OO in team diversi (queste persone dovrebbero cambiare team ogni pochi mesi).

è una buona idea. Questo dovrebbe essere approfondito e OO dovrebbe essere discusso da zero. Quando stavo imparando OO, gli aneddoti storici mi hanno aiutato molto.

Vorrei anche suggerire,

• Poiché la motivazione è la chiave, motivali nel dettaglio come OO può migliorare il loro lavoro, in particolare la manutenibilità del codice.
• Esamina il codice e mostra come refactoring applicare composizione, eredità, polimorfismo e schemi.
• Introduci un buon processo come SCRUM e coinvolgi gli sviluppatori.
• Rendi obbligatoria la lettura di libri come "Refactoring" e "Refactoring to Patterns".

Sono d'accordo con Shuvo Naser. È un grosso ostacolo, quindi trattalo più come una scalata. Imparare a progettare un'intera applicazione usando OOP richiederà del tempo.

1. Identifica quelli che comprendono OOP e avvicinali a team leader, formatori, designer, revisori del codice, ecc.
2. Utilizzare un progetto esistente come riferimento per la formazione. Forse quelli nel numero 1 facevano parte di quella squadra.
3. Rifattorizzare alcuni progetti esistenti. Questo può aiutare alcune persone a costruire un ponte tra il loro codice procedurale e il codice OO. Inizia con le basi. Devono vedere quando, dove e perché usi questi principi.
4. Coinvolgili in sessioni di progettazione con persone che sanno cosa stanno facendo.
5. Mettili in team di sviluppo con qualcuno che sia in grado di fornire indicazioni di progettazione e assicurati che il progetto rispetti i principi OO (Supponendo che il motivo per cui vuoi farlo in primo luogo sia perché migliorerà lo sviluppo.).

L'adozione raramente precede la visione dei benefici. Stiamo parlando di un design complesso e di non utilizzare i fogli di copertura del rapporto TPS .

Hai già buone idee

Le idee che descrivi nella tua domanda suonano eccellenti. È una grande sorpresa che non trovi successo. È il 2012 e la rivoluzione orientata agli oggetti è passata da tempo dallo stato dell'arte allo stato dell'arte. Sembra che a meno che tu non abbia un turn over molto basso e un ingaggio molto ridotto, faresti fatica a non ottenere diverse dozzine o addirittura un centinaio di buoni programmatori orientati agli oggetti solidi.

Agile o orientato agli oggetti?

Hai citato alcune tecnologie Agile come TDD e alcuni concetti più recenti, quindi non essere troppo duro con le persone per non abbracciare qualcosa che è ancora attivamente combattuto da alcuni team di gestione. Alcuni sostengono di abbracciare Agile, ma quando ne parlano, significa che cosa significano. L'organizzazione non è caratterizzata da team che prendono decisioni e si adattano, ma invece da un forte controllo gerarchico in stile contratto.

Ma torniamo agli oggetti orientati. Non menzioni l'analisi o la progettazione orientata agli oggetti e non sono del tutto sicuro di quale linguaggio di programmazione stia cedendo il passo a quale linguaggio di programmazione orientato agli oggetti. So che UML sta avendo problemi di popolarità tra molti programmatori orientati agli oggetti. Dopo aver studiato a fondo OOAD, credo che potrebbe essere come imparare la cultura e la storia di un paese di cui vuoi imparare la lingua naturale. Ad esempio, se volessi imparare il greco, potrei imparare l'alfabeto, il vocabolario e la grammatica, ma se ignorassi la ricca storia e cultura, mi perderei molto. In ogni caso, se impari tutto su un linguaggio di programmazione orientato agli oggetti, ma nulla su OOAD, penso che sia stata persa un'importante opportunità.

Problemi da superare?

Bridge troppo lontano? Se chiedi alle persone di imparare una piccola cosa a settimana, in un anno, tra le persone che partecipano, ci saranno molti cambiamenti. Se chiedi loro di cambiare tutto ciò che sanno, sarà accolto da alcuni, difficile per molti e impossibile per altri. Alcune modifiche come il controllo del codice sorgente sono localizzate. Passi dal non farlo prima, avevi un allenamento che non stava sottolineando i limiti della memoria, qualcuno ti ha attraversato per la prima volta, e poi il quotidiano era abbastanza facile.

Altre modifiche sono pervasive. Ad esempio, il dumping C e il passaggio a Java richiedono una formazione, un'impostazione e grandi cambiamenti significativi nel giorno per adottare un nuovo IDE, un nuovo compilatore, una nuova lingua, una nuova API, un nuovo modello di distribuzione, ecc. Questo è il tipo di ciò che accade più spesso in combinazione con un programma pilota o una ristrutturazione aziendale.

Guidare una rivoluzione? Se le persone che attualmente svolgono il lavoro hanno una storia di ricompense e l'azienda non sembra in pericolo di fallimento, qual è la loro motivazione per il cambiamento? Se sembri un estraneo che vuole indicare la direzione e lasciarli responsabili dei risultati che non possono prevedere, può sembrare un rischio, nessuna ricompensa.

Posizione Potere o Idea Leadership? Molte organizzazioni operano in base al potere di posizione. Se manchi di supporto visibile da manager, direttori di sezione, direttori e vicepresidenti, sei semplicemente un leader dell'idea. Alcune persone sono nella pericolosa posizione di avere un'idea e non essere in grado di intrattenerne una seconda. Se riesci a mostrarli invece di dirglielo, ciò farà molto per calmare gli scettici e per interessare gli alleati di talento.

Base di supporto troppo piccola? Fai un triage tra quelle 250 persone e ordinale in tre categorie: pronto ad abbracciare, disposto ad imparare e riluttante ad imparare. Hai buone ragioni per essere frustrato con alcune persone che non hanno interesse a fare un cambiamento. Potresti anche spingere una corda. Questo è uno sforzo sprecato. Se hai un'idea di chi sostiene il cambiamento, puoi scoprire cosa li interessa.

A differenza di un triage medico in cui la scelta etica e pratica è quella di aiutare il gruppo di mezzo che può farlo con l'aiuto, puoi investire la tua energia e il tuo tempo in base al tuo giudizio e alle tue preferenze. Per il tuo successo, perché non coltivare il gruppo che è pronto ad abbracciare nuove idee? Potrebbero essere pochi i primi, ma come una palla di neve, la tua visibilità e credibilità come avvocato cresceranno. Presto le persone ti chiederanno quando sarà il prossimo allenamento.

In esso a lungo termine? Fino a quando coltivi un campione per portare cose dopo di te, dovresti aspettarti di investire tempo nella costruzione di relazioni. Potrebbe essere necessario rimanere con le squadre che alleni per più di un mese. Fino a quando il team non possiede proprietà migliorate per se stesso, sei solo un poliziotto di tecnologia o metodologia. Il mentoring è un processo che può richiedere anni. Ci sono molte cose che i tuoi sviluppatori non vogliono fare e che ritieni importanti (penso che tu abbia menzionato specificamente i test unitari). Potrebbe volerci un po 'di tempo per costruire una visione condivisa del valore che questo comporta. Lo so per esperienza perché una volta ho sostenuto uno strumento di copertura del codice presso un'azienda Fortune 500 che aveva una grande reputazione per la qualità, ma manager e colleghi allo stesso modo erano cauti nel impegnarsi.

Esperto o di base? Molto più veloce del tutoraggio sarebbe favorire il supporto di base che proviene da ciascun membro del team. A partire da un team di dieci specialisti di software, se avessi la mia scelta di avere una persona che lavorasse sul processo per tutto il tempo o dieci persone che lavorassero sul processo il dieci percento delle volte, sceglierei la seconda. Il processo di base consente ai sostenitori di sentire l'impatto dell'approccio e di personalizzare l'approccio per risolvere al meglio i problemi della squadra proprietaria del lavoro.

Vedi la Freedom Line? Parte dell'introduzione delle "Best Practices" è di indurre le persone a rinunciare alla libertà di fare le cose in modo comune. Rinunciare alla discrezione del programmatore sarà più appetibile se cerchi opportunità per lasciare molte scelte agli sviluppatori. Ciò che scelgono è delineato da ciò che è richiesto da una partizione che possiamo chiamare la linea di libertà. Potrebbero essere necessarie divisioni simili, ben giustificate, relative a pratiche organizzative, regionali / specifiche del sito, del team e personali.

Questo avrebbe dovuto essere un commento, ma dal momento che apparentemente non sono ancora in grado di commentare cose, potrebbe anche essere una risposta.

La cosa più importante di sempre in questo tipo di scoperte (sia che si tratti di OOP o di qualsiasi altro cambio di paradigma, diciamo, di programmazione funzionale o di qualsiasi altra cosa venga fuori nel prossimo anno) è FARE RECENSIONI DEL CODICE E PROGRAMMAZIONE PEER . Accompagnali, accompagna le squadre in un modo diverso di fare cose che li aiuteranno.

Il mio percorso personale verso la programmazione orientata agli oggetti è iniziato quando alcuni asshat casuali che facevano revisioni del codice mi hanno castigato per aver fatto cose in modo modulare e mantenendo lo stato senza andare in C ++ OO completo; pensa come un codice

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(notare che il client_totale può essere totalmente ridondante, essendo un esempio particolarmente mal pianificato)

E ho finito per farlo solo quando un collega più anziano ha appena indicato il mio schermo e ha detto "guarda, se scrivi la stessa cosa più di una volta, usa una procedura o una funzione e la chiami ripetutamente".

I discorsi, le riunioni e le pratiche opzionali non li faranno cambiare il paradigma o introdurre una nuova pratica, dal momento che non esiste un vero impulso per farlo oltre alla pura curiosità. D'altra parte, rendere non male o semplicemente disapprovare la cosa aumenta davvero il tasso di adozione.

Preparati allo sviluppo piagnucoloso e orientato alla classe che ne conseguirà fino a quando non incorporeranno il design appropriato in quello che stanno facendo. Vedrai un sacco di cose che ti faranno morire un po 'dentro, ma è così che appare il percorso di apprendimento.