Come convinco la mia squadra a utilizzare classi / metodi più piccoli?

Hai il vantaggio di visualizzare il codice con occhi nuovi. prendi appunti per documentare ciò che scopri di cattive pratiche. Poi, mentre ti stai sistemando con la squadra, tira fuori le tue note al momento opportuno, come quando è il momento di refactoring.

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

Potresti comprare una copia del libro e mostrare al tuo pari alcuni studi ... le statistiche (anche se si trovano tutte le volte) tendono a convincere la gente.

Disclaimer: I'm a new comer (this is my third day of work), and most of my team are more experienced than me.

Potresti voler rallentare un po ', ascoltare e imparare dalla tua squadra prima di andare a suggerire troppe modifiche. Potrebbero esserci o no dei buoni motivi per cui il codice è strutturato come è, ma in ogni caso il tempo di ascoltare e imparare prima può solo aiutare.

Dopo che tutti i suggerimenti che potresti fare saranno sicuramente considerati più positivamente e incontrati con meno resistenza.

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

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 drastiche revisioni. La maggior parte del codice funziona per una ragione :) non importa quanto sia spazzatura, ea volte le drastiche revisioni rendono ancora più brutti quei noiosi casi d'angolo.

Penso che la leva più semplice per scrivere codice più piccolo sarebbe chiedere agli sviluppatori di concentrarsi su test dell'unità . Nulla forza codice conciso come se fosse richiesto a test ; è incredibile come gli sviluppatori abbiano improvvisamente un'avversione alle strutture di dati globali, passando troppi oggetti in profondità, quando sanno di dover scrivere test per tutto questo.

Non sono un grande fan del TDD, ma io faccio amo il fatto che costringa gli sviluppatori a considerare come scrivere test. E che spesso è il motivo per cui il codice è migliore, non un po 'di magia sul fatto che abbia i test. (Anche se è sicuramente utile quando apporti modifiche in seguito.)

Buona fortuna.

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

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

In caso contrario, sarai comunque più produttivo e il tuo duro lavoro finirà per portarti in una posizione più alta dove puoi iniziare ad applicare alcune di queste regole.

E sì, con tutti i mezzi, mostrare materiale da Code Complete a tutti.

Ecco un paio di trucchi:

• Scopri lo stato attuale e la cronologia del team: sembra che abbiano un mentore, quanta influenza ha il mentore? Inoltre, quanto è nuovo il mentore e c'è stato un lungo periodo senza un mentore? Quando inizia il codice problema? Criticare il bambino della squadra attuale può essere molto diverso dal criticare un vecchio codice che nessuno ricorda effettivamente della scrittura.

• Una cosa alla volta - non lasciare cadere la bomba su tutti i tuoi pensieri durante una riunione di gruppo. Inizia con alcune domande provvisorie che vengono dalla tua prospettiva specifica. Ad esempio: "Ehi, come nuovo ragazzo, ho notato che alcune delle classi di utilità sono veramente grandi, c'è una ragione per questo?"

• Suggerisci piccoli passi: non è quasi mai possibile effettuare una revisione totale immediata, quindi cerca di capire come procedere nel caso in cui tutti siano d'accordo sul fatto che questo è un buon piano.

• Suggerisci i meccanismi di prevenzione futuri: ad esempio, il team potrebbe accettare un obiettivo che non aggiungerà mai alle prime classi più importanti, ma sarà un refactoring quando è necessario svilupparli ulteriormente.

• Ascolta le preoccupazioni sul rischio. Se questo è veramente 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 vai piano. Stai sollevando un problema in un codice base con cui non hai avuto molta esperienza. Adesso hai una nuova finestra per i ragazzi, dove puoi fare alcune domande ingenue e ottenere risposte utili, e puoi usare quelle domande per sondare il team in modo da prendere in considerazione le proprie scelte progettuali. Ma va in entrambe le direzioni - come il nuovo ragazzo, anche tu non hai ancora un sacco di "cred", quindi vai piano e sii consapevole delle facce chiuse o delle posture. Se le persone iniziano a spegnersi, suggerisci un modo per posticipare le decisioni e cercare modi per conquistarle.

Posso dire come manager e membro del team, sono stato contento per New Guy Insights. Non ho accettato ogni singolo commento costruttivo che un nuovo membro del team mi ha dato, ma ero generalmente disposto ad ascoltare se le critiche fossero espresse come onesta preoccupazione e curiosità e non venissero fornite come una lezione. Il marchio di rispetto per il nuovo ragazzo va quando può dare l'intuizione e poi fare un passo indietro e gestire qualsiasi cosa arrivi - è facile sentirsi bene quando le tue decisioni vengono ascoltate e riprese, è più difficile quando la squadra ti dice "no". Potresti avere ancora ragione, il trucco è capire cosa fare dopo ... di solito aspettando un po 'e in cerca di ulteriori informazioni è un buon passo successivo in questi casi.

How do I convince my team to use smaller classes/methods?

Non.

Comprati una licenza Resharper e guidi con l'esempio. [Applica pesantemente al refactoring Extract Method .]

Col tempo, gli altri dovrebbero venire ad apprezzare il tuo codice più leggibile e essere persuasi a fare altrettanto. *

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

IMO - Le tue sillabe non valgono la pena di 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 è possibile utilizzare la logica per escludere qualcuno dalla posizione in cui non hanno utilizzato la logica per entrare in primo piano.

Questa sembra più una questione di gestione che una questione tecnica. Tutto ciò che hai detto è valido, ciò di cui il tuo team ha veramente bisogno è un buon architetto che possa assicurarsi che tutti si adattino a un singolo modello di progettazione e applicarlo, il team deve essere costantemente e regolarmente refactoring del 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 il tuo team ha bisogno di ricostruire il tutto o ricostruirne una parte, accumula un documento di cattive pratiche e problemi prima di eseguire la codifica.

Alcuni team non fanno alcun tipo di 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.

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

Anche tenere dei registri è una buona idea. Se i membri del team esprimono verbalmente ciò che deve essere fatto, la gente è destinata a dimenticare. Gli umani hanno ricordi molto fragili! =)

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

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

Seguo il consiglio dello zio Bob di lasciare sempre il codice meglio di come l'hai trovato. Quindi, se abbiamo bug da correggere o piccoli miglioramenti, mi auguro che stavamo facendo un po 'di pulizia allora.

Ma così com'è, l'azienda osserva veramente è denaro. Dovrei spiegare loro che il refactoring li avvantaggia abbastanza da permettere loro di dedicare tempo e risorse alla mia squadra. Non ti piace il modo in cui il codice appare non è sufficiente.

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

Ora nuovo codice, è diverso. Dovrebbe essere un buon codice.

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

Due dei tuoi problemi possono essere risolti con strumenti esterni :

• Linee guida per la denominazione un po 'incoerenti
• Le proprietà non sono contrassegnate come readonly quando possibile

In C # Resharper può controllare entrambi i problemi. I nomi che non seguono le tue linee guida sono contrassegnati come errori. Le proprietà non contrassegnate come readonly mostrano anche errori. FxCop potrebbe anche essere un aiuto.

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

Non so che le classi grandi siano sempre così male se sono strutturate bene con metodi ben definiti. Io uso Eclipse come IDE quindi ha qualcosa chiamato la vista "outline", che è qualcosa che tutti gli IDE hanno solo con un nome diverso, molto probabilmente, che fornisce il nome e il link a ciascun metodo all'interno della classe, puoi ordinarlo alfabeticamente , ecc. Usando questo è facile navigare in una classe di grandi dimensioni, è più che avere metodi veramente lunghi sarebbe male, penso perché è più difficile navigare in modo intelligente all'interno di quel metodo, a meno che non si abbia familiarità con esso. Non sto sostenendo lezioni lunghe ma penso che in alcuni casi siano gestibili e non debbano necessariamente essere suddivise in più classi.

Porta l'argomento con alcuni 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 la compagnia, o quella parte era un lavoro urgente e ora hanno assunto qualcuno con il tempo per refactarlo;)

Sei ancora il nuovo ragazzo. Costruisci un po 'di reputazione affrontando compiti impegnativi e completandoli rapidamente e senza errori. Se provi a iniziare a cambiare le cose prima di guadagnare il rispetto dei tuoi coetanei, potresti avere un tempo molto più difficile per comprare (e forse 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 portano a soluzioni più solide, potresti persino vederli venire a vedere come hai ottenuto questo.

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 per ottenere una comprensione del codice base. Puoi venderlo al tuo team / manager come un'opportunità di apprendimento per te e riceverai feedback dai tuoi colleghi quando guarderanno le tue modifiche che ti guideranno nel tuo approccio migliore per affrontare il problema del design scadente.