Come convincere il mio team a utilizzare classi / metodi più piccoli?

Disclaimer: sono un nuovo arrivato (questo è il mio terzo giorno di lavoro) e la maggior parte dei miei compagni di squadra ha più esperienza di me.

Quando guardo il nostro codice, vedo alcuni odori di codice e cattive pratiche ingegneristiche, come il seguente:

• Linee guida per la denominazione alquanto incoerenti
• Proprietà non contrassegnate come di sola lettura quando possibile
• Grandi classi: ho notato una classe di utilità che consisteva in centinaia di metodi di estensione (per molti tipi). Era lungo più di 2500 linee!
• Metodi di grandi dimensioni: sto cercando di riformattare un metodo lungo 150 righe.

Gli ultimi due sembrano essere un vero problema. Voglio convincere i miei compagni di squadra a usare classi e metodi più piccoli. Ma dovrei farlo? Se sì, allora come?

La mia squadra ha ricevuto un mentore dalla squadra principale (siamo una squadra satellite). Prima dovrei andare da lui?

AGGIORNAMENTO : poiché alcune risposte hanno chiesto del progetto, si prega di sapere che si tratta di un progetto funzionante. E IMHO, enormi classi / metodi di quella dimensione sono sempre cattivi.

Comunque, non voglio mai incazzare la mia squadra. Ecco perché ho chiesto: dovrei farlo, e se sì, come lo faccio delicatamente?

AGGIORNAMENTO : Ho deciso di fare qualcosa in base alla risposta accettata: perché sono un nuovo arrivato, quindi vedo tutto in "occhi nuovi" Prenderò nota di tutti gli odori di codice che ho trovato (posizione, perché è cattivo, come possiamo farlo meglio, ...), ma al momento, cerco solo di ottenere i rispetti dal mio team: scrivere "codice migliore", conoscere le persone, sapere perché l'abbiamo fatto ... Quando sarà il momento, proverò per chiedere al mio team alcune nuove politiche di codice (linee guida per la denominazione, classi più piccole, metodi più piccoli, ...) e, se possibile, refactoring del vecchio codice. Dovrebbe funzionare, IMHO.

Grazie.

Hai il vantaggio di visualizzare il codice con occhi nuovi. Prendi appunti per documentare ciò che scopri delle cattive pratiche. Quindi, mentre ti stai sistemando con la squadra, tira fuori i tuoi appunti in un momento opportuno, come quando è il momento del refactoring.

Code Complete, di Steve McConnell, ha tonnellate di buone statistiche sull'argomento stesso di cui stai parlando. Non ricordo tutti i numeri, ma parla di come aumentano i numeri di bug con metodi / classi più lunghi, quanto tempo ci vuole per il debug, ecc.

Potresti comprare una copia del libro e mostrare al tuo collega alcuni degli studi ... le statistiche (anche se mentono sempre) tendono a convincere la gente.

Disclaimer: sono un nuovo arrivato (questo è il mio terzo giorno di lavoro) e la maggior parte del mio team ha più esperienza di me.

Potresti voler rallentare un po ', ascoltare e imparare dalla tua squadra prima di andare a suggerire troppi cambiamenti. Potrebbero esserci o meno buone ragioni per cui il codice è strutturato così com'è, ma in entrambi i casi prendere il tempo per ascoltare e imparare prima può solo aiutare.

Dopodiché, qualsiasi suggerimento che potresti dare sarà sicuramente visto in modo più positivo e incontrato meno resistenza.

Le tue possibilità di introdurre con successo il cambiamento sono notevolmente migliorate se guadagni il rispetto, o almeno non perdi il rispetto, dei tuoi colleghi prima.

Come va? "Misura due volte una volta .." Qualcosa del genere.

A meno che tu non sia stato assunto con l'intenzione specifica di revisionare il modo in cui il tuo team scrive il codice, potresti voler moderare il tuo entusiasmo per le revisioni drastiche. La maggior parte del codice di lavoro funziona per un motivo :) non importa quanto sia spazzatura, e talvolta drastiche revisioni rendono ancora più brutti quei fastidiosi casi angolari.

Penso che la leva più semplice per scrivere codice più piccolo sarebbe chiedere agli sviluppatori di concentrarsi sui test unitari . Nulla forza il codice conciso come essere invitato a testarlo ; è sorprendente come gli sviluppatori abbiano improvvisamente un'avversione per le strutture di dati globali, passando troppi oggetti in profondità e troppi strati, quando sanno che devono scrivere test per tutto questo.

Io non sono un grande fan di TDD, ma io non piace il fatto che costringe gli sviluppatori a prendere in considerazione il modo in cui avrei scritto test. E che spesso è il motivo per cui il codice è meglio, non è qualcosa di magico circa in realtà avere i test. (Anche se sicuramente tornerà utile quando si apportano modifiche in seguito.)

Buona fortuna.

Non dovresti convincere la tua squadra. Come nuovo arrivato, non verrai preso sul serio, quindi perderai tempo.

Invece, vai avanti e scrivi tu stesso un codice compatto e pulito. Quindi, si spera, dopo un po 'e alcune revisioni del codice, alcuni compagni di squadra potrebbero iniziare a imitare il tuo stile.

Altrimenti, sarai ancora più produttivo e il tuo duro lavoro alla fine ti porterà in una posizione più elevata dove puoi iniziare a far rispettare alcune di queste regole.

E sì, mostra a tutti i contenuti di Code Complete.

Ecco un paio di trucchi:

• Scopri lo stato e la storia attuali del team: sembra che abbiano un mentore, quanta influenza ha il mentore? Inoltre, quanto è nuovo il mentore ed è passato molto tempo senza mentore? Quando ha origine il codice problema? Criticare il bambino della squadra attuale può essere molto diverso dal criticare un vecchio codice che nessuno ricorda in realtà di aver scritto.

• Una cosa alla volta: non far cadere la bomba su tutti i tuoi pensieri in una riunione di squadra. Inizia con alcune domande provvisorie che provengono dalla tua prospettiva specifica. Ad esempio: "Ehi, come nuovo ragazzo, ho notato che alcune delle classi di utilità sono davvero grandi, c'è un motivo per questo?"

• Suggerisci piccoli passi: non è quasi mai possibile effettuare una revisione totale immediata, quindi cerca di capire alcuni passi iniziali nel caso in cui tutti concordino sul fatto che questo è un buon piano.

• Suggerisci futuri meccanismi di prevenzione - ad esempio, il team potrebbe concordare un obiettivo che non si aggiungerà mai alle prime classi più grandi, ma si rifatterà quando sarà necessario svilupparle ulteriormente.

• Ascolta le preoccupazioni sul rischio. Se questo è davvero un codice legacy, potrebbero esserci abbastanza incognite e dipendenze che il refactoring è estremamente rischioso. Questo potrebbe non essere un motivo per evitare il refactoring, ma potrebbe significare che hai bisogno di strategie di test migliori o di un altro modo per ridurre il rischio prima di affrontare la vera rielaborazione.

• Sii consapevole del linguaggio del corpo e procedi lentamente. Stai sollevando un problema in una base di codice con cui non hai molta esperienza. Hai una nuova finestra per ragazzi in questo momento, dove puoi fare alcune domande ingenue e ottenere risposte utili e puoi usare quelle domande per sondare il team a considerare le proprie scelte di design. Ma va in entrambi i modi - come il nuovo ragazzo, anche tu non hai ancora un sacco di "cred", quindi vai piano e sii consapevole di facce o posture chiuse. Se le persone iniziano a chiudere, suggerisci un modo per ritardare qualsiasi decisione e cercare modi per conquistarle.

Posso dire che come manager e membro del team sono stato contento di New Guy Insights. Non ho accettato ogni singolo commento costruttivo che mi ha dato un nuovo membro del team, ma ero generalmente disposto ad ascoltare se la critica fosse espressa come onesta preoccupazione e curiosità e non fosse pronunciata come una lezione. Il segno di rispetto per il nuovo ragazzo va quando può fornire la visione e poi fare un passo indietro e gestire qualsiasi cosa accada: è facile sentirsi bene quando le tue decisioni vengono ascoltate e prese, è più difficile quando la squadra ti dice "no". Potresti ancora avere ragione, il trucco è capire cosa fare dopo ... di solito aspettare un po 'e cercare maggiori informazioni è un buon passo successivo in quei casi.

Come convincere il mio team a utilizzare classi / metodi più piccoli?

Non farlo.

Comprati una licenza Resharper e conduci con l'esempio. [Appoggiarsi pesantemente al refactoring " Metodo di estrazione ".]

Nel tempo, gli altri dovrebbero apprezzare il tuo codice più leggibile ed essere persuasi a fare altrettanto. *

• Sì - C'è la possibilità che non vengano persuasi; ma è comunque la soluzione migliore.

IMO - Non vale la pena che le tue sillabe provino a convincere i tuoi compagni di squadra a diventare programmatori migliori, leggi ' Codice completo ', segui @Uncle Bob. I principi SOLIDI e diventare programmatori migliori se non sono già persuasi.

Ricorda: non puoi usare la logica per argomentare qualcuno da una posizione in cui non ha usato la logica per entrare.

Questa sembra essere più una questione di gestione che una questione tecnica. Tutto ciò che hai detto è valido, ciò di cui il tuo team ha davvero bisogno è un buon architetto che può assicurarsi che tutti si adattino a un singolo modello di progettazione e lo applichino, il team deve costantemente e regolarmente refactoring il codice.

Tuttavia, c'è un altro principio "non ne avrai bisogno", se ciò che è mai esistito funziona per un tempo abbastanza lungo, non importa quanto sia brutto, cambiarlo non è sempre una buona idea. Invece, se la tua squadra ha bisogno di ricostruire l'intera cosa o ricostruirne una parte, accumula un documento di cattive pratiche e problemi prima di eseguire la codifica.

Alcuni team non eseguono alcun controllo di qualità per il codice perché non conoscono gli strumenti giusti per farlo. Ci sono molti strumenti che possono aiutare meglio un codice di squadra.

Visual Studio ha "Analisi del codice" che può aiutare con le convenzioni di denominazione.

Anche le metriche del codice potrebbero essere utilizzate, come la complessità ciclomatica. Questo aiuta a sottolineare classi e metodi che sono troppo complessi.

Tenere una documentazione è anche una buona idea. Se i membri del team esprimono verbalmente ciò che deve essere fatto, le persone sono tenute a dimenticare. Gli umani hanno ricordi molto fragili! =)

Non farei molto rumore su questo ... Il team di sviluppo di un programmatore è come la sua stessa famiglia ... Se fai notare errori, le persone possono arrabbiarsi con te. Questo tipo di cambiamento culturale non richiede solo molta codifica, ma richiede anche un tocco delicato con gli esseri umani.

Come manager voglio solo aggiungere che voglio che il mio team scriva un buon codice la prima volta. Revisioni del codice, TDD e tutto il resto. Ma una volta che è in produzione e funziona, dovresti fare un valido caso per farci tornare indietro.

Seguo il consiglio di zio Bob di lasciare sempre il codice migliore di quello che hai trovato. Quindi, se avessimo dei bug da correggere o piccoli miglioramenti, spero che avremmo fatto un po 'di pulizia allora.

Ma così com'è, l'azienda osserva davvero i suoi soldi. Dovrei far valere loro che il refactoring li avvantaggia abbastanza da consentire loro di dedicare tempo e risorse al mio team. Non mi piace l'aspetto del codice non è sufficiente.

Quindi, se funziona, per quanto tu possa odiarlo, potresti doverlo lasciare da solo.

Ora nuovo codice, è diverso. Questo dovrebbe essere un buon codice.

Metodi che sono 150 righe ... Ho visto metodi con 10.000 righe di codice.

Due dei tuoi problemi possono essere risolti con strumenti esterni :

• Linee guida per la denominazione alquanto incoerenti
• Le proprietà non sono contrassegnate come di sola lettura quando possibile

In C # Resharper può controllare entrambi i problemi. I nomi che non seguono le linee guida sono contrassegnati come errori. Le proprietà non contrassegnate come di sola lettura vengono visualizzate anche come errori. FxCop potrebbe anche essere di aiuto.

Questi strumenti possono anche aiutare a dividere enormi metodi in più piccoli più piccoli grazie al suo refactoring.

Non so che le grandi classi sono sempre così brutte se sono strutturate bene con metodi ben definiti. Uso Eclipse come IDE in modo che abbia qualcosa chiamato vista "struttura", che è qualcosa che tutti gli IDE hanno solo con un nome diverso, molto probabilmente, che fornisce il nome e il collegamento a ciascun metodo all'interno della classe, puoi ordinarlo in ordine alfabetico , ecc. Quando si usa questo è facile navigare in una grande classe, è più che avere metodi molto lunghi sarebbe male, penso perché è più difficile navigare in modo intelligente all'interno di quel metodo a meno che tu non ti sia veramente familiare. Non sto sostenendo le lezioni lunghe, ma penso che in alcuni casi siano gestibili e non debbano necessariamente essere suddivise in più classi.

Mostra l'argomento con alcuni dei membri del tuo team e ottieni la loro opinione sulla dimensione dei metodi. Potresti essere sorpreso di scoprire che sono d'accordo con te. Quello che stai vedendo potrebbe essere il risultato di cattive pratiche precedenti, ex sviluppatori non più con l'azienda, o quella parte era un lavoro urgente e ora hanno assunto qualcuno con il tempo di riformattarlo;)

Sei ancora il nuovo ragazzo. Costruisci una certa reputazione assumendo compiti impegnativi e completandoli rapidamente e senza bug. Se provi a iniziare a cambiare le cose prima di guadagnare il rispetto dei tuoi colleghi, potresti avere un momento molto più difficile ottenere acquisti (e possibilmente alienare i tuoi colleghi).

Se riesci a trovare modi per introdurre le migliori abitudini di codifica nel tuo lavoro che dimostrano in modo efficace come riducono i tempi di sviluppo e danno luogo a soluzioni più solide, potresti persino farle venire da te per vedere come hai raggiunto questo obiettivo.

Oltre a tutte le altre grandi risposte, forse puoi uccidere due piccioni con una fava e fare un po 'di pulizia del codice come progetto finalizzato a comprendere meglio la base di codice. Puoi venderlo al tuo team / manager come opportunità di apprendimento per te e riceverai feedback dai tuoi colleghi quando esamineranno le tue modifiche che ti guideranno nel tuo miglior approccio per affrontare il problema della cattiva progettazione.