Come convincere il vostro compagno di sviluppatori di scrivere i metodi brevi?

https://stackoverflow.com/questions/881871

22-08-2019
|

Domanda

metodi lunghi sono male per diversi motivi:

Sono difficili da capire
Sono difficili da modificare
Sono difficili da riutilizzare
Sono difficili da testare
Hanno bassa coesione
Possono avere accoppiamento alto
Essi tendono ad essere eccessivamente complesso

Come convincere il vostro compagno di sviluppatori di scrivere i metodi brevi? (Armi sono proibite =)

Soluzione

Hai fatto un elenco di inconvenienti. Provate a fare una lista di ciò che si guadagna utilizzando metodi brevi. Esempi concreti. Quindi provare a convincerlo di nuovo.

Altri suggerimenti

Chiedetegli di scrivere unit test per i metodi.

che dipende dalla vostra definizione di "corta" e "lungo".

Quando sento qualcuno dire "scrivere metodi brevi", ho subito reagire male perché ho incontrato troppo gli spaghetti scritti da persone che pensano che il metodo ideale è di due linee lungo: Una linea di fare il più piccolo unità possibile di lavoro seguita da una linea di chiamare un altro metodo. (Lei dice metodi lunghi sono il male, perché "sono difficili da capire"? Provate a camminare in un progetto in cui ogni azione banale genera uno stack di chiamate 50 metodi profondo e cercando di capire quale di queste 50 strati è quello che è necessario modificare ...)

D'altra parte, se, da "corto", vuol dire "self-contained e limitato a una singola funzione concettuale", allora sono tutti per esso. Ma ricordate che questo non può essere misurata semplicemente righe di codice.

E, come tydok sottolineato, si cattura più mosche con il miele che con l'aceto. Provate a dire loro perché la tua strada è buona, invece del motivo per cui la loro strada è male. Se si può fare questo senza fare paragoni palesi o riferimenti ad essi o le loro pratiche (a meno che non specificamente chiedono come le vostre idee potrebbero riguardare qualcosa che stanno facendo), funzionerà ancora meglio.

ho letto questa citazione da qualche parte:

Scrivi il codice come se la persona che deve mantenere è una violenta psico, chissà dove vivi.

Nella mia esperienza il modo migliore per convincere un peer in questi casi è l'esempio. Basta trovare opportunità di mostrare loro il codice e discutere con loro i vantaggi di brevi funzioni vs. funzioni lunghi. Alla fine si accorgeranno cosa c'è di meglio spontaneamente, senza la necessità di farli sentire i programmatori "cattivi".

Codice recensioni!

Vi suggerisco di provare e ottenere alcune revisioni del codice in corso. In questo modo si potrebbe avere un piccolo laboratorio sulle migliori pratiche e qualunque sia la formattazione del aderisce liberamente aziendali per. Questo aggiunge il contesto che i metodi brevi è un modo per rendere il codice più leggibile e più facile da capire e anche compatibile con lo SRP.

Se hai provato a spiegare il buon design e la gente non sono sempre, o sono solo rifiutano di farlo, quindi smettere di cercare. Non vale la pena. Tutto quello che ottiene è una cattiva reputazione per te stesso. Alcune persone sono semplicemente senza speranza.

Fondamentalmente ciò che si riduce a è che alcuni programmatori semplicemente non sono tagliati per lo sviluppo. Possono capire il codice che è già scritto, ma non possono creare da soli.

Queste persone dovrebbero essere guidato verso un ruolo di supporto, ma non dovrebbero essere autorizzati a lavorare su qualcosa di nuovo. Il supporto è un buon posto per vedere un sacco di codice diverso, quindi forse dopo qualche anno verranno a vedere i benefici di un buon design.

Mi piace l'idea di codice recensioni che qualcun altro ha suggerito. Questi programmatori Sloppy dovrebbero non solo avere il proprio codice di recensione, dovrebbero assistere a recensioni di buon codice pure. Che darà loro la possibilità di vedere ciò che è buon codice. Forse hanno appena mai visto buon codice.

di estendere la risposta di rvanider, eseguire l'analisi di complessità ciclomatica sul codice ha fatto miracoli per attirare l'attenzione al grande problema metodo; convincere la gente a cambiare era ancora in lavorazione, quando ho lasciato (troppo slancio verso grandi metodi).

Il punto di svolta è stato quando abbiamo iniziato che collega la complessità ciclomatica al database dei bug. Una CC di oltre il 20 che non era una fabbrica è stato garantito per avere diverse voci nel database dei bug e spesso quei bug aveva una "linea di sangue" (fix per bug A Bug B causato; fissare a Bug B causata Bug C; ecc). Abbiamo avuto tre CC di oltre 100 (max 275) e questi metodi hanno rappresentato il 40% dei casi nel nostro database dei bug - "sai, forse 5000 funzione di linea non è una buona idea ..."

E 'stato più evidente nel progetto ho guidato quando ho iniziato lì. L'obiettivo era di mantenere CC più basso possibile (97% erano sotto 10) ed il risultato finale è un prodotto che fondamentalmente smesso di supporto perché i 20 insetti avevo erano non vale fissaggio.

software libero-Bug non sta per accadere a causa di metodi brevi (e questo può essere un argomento dovrete affrontare), ma le correzioni di bug sono molto veloci e sono spesso privo di effetti collaterali quando si lavora con brevi, concisi metodi.

Anche se scrittura di unit test sarebbe probabilmente curarle di metodi lunghi, la vostra azienda probabilmente non fa uso di test di unità. Retorica va solo finora e lavora a sviluppatori che sono bloccati nei loro modi di rado; mostrare loro numeri su come questi metodi stanno creando più lavoro e buggy software.

Trovare il giusto mix tra la lunghezza funzionalità e semplicità può essere complessa. Provate ad applicare una metrica come complessità ciclomatica per dimostrare la difficoltà di mantenendo il codice nella sua forma attuale. Niente batte una misura non personali che si basa su fattori di test, come filiali e di decisione conteggi.

Non so dove questo grande citazione proviene, ma:

"Il debugging è due volte più duro come la scrittura del codice, in primo luogo. Pertanto, se si scrive il codice come abilmente possibile, si è, per definizione, non abbastanza intelligente per eseguire il debug"

lo costringono a leggere codice completo da Steve McConnell. Dire che ogni buon sviluppatore deve leggere questo.

farlo ubriacare? : -)

Il punto serio da questa risposta è la domanda: "Perché ho sempre scrivo funzioni brevi, e odio me stesso quando non lo faccio?"

Il motivo è che ho difficoltà a comprendere codice complesso, sia le funzioni che a lungo, le cose che mantengono e manipolano un sacco di stato o cose del genere. Ho notato che molti anni fa che ci sono un discreto numero di persone là fuori che sono significativamente migliori a trattare con questo tipo di complessità di me. Ironia della sorte, è probabilmente a causa di quella che io tendo a essere un programmatore migliore di molti di loro:. i miei limiti mi costringono a confrontarsi e ripulire quella sorta di codice

Mi dispiace non posso dare una risposta reale qui, ma forse questo può fornire una certa comprensione per aiutarci portare ad una risposta.

costringerli a leggere il libro "Codice Clean", ci sono molti altri ma questo è nuovo, buono e di facile lettura.

chiedendo loro di scrivere unit test per il codice complesso è una buona strada da prendere. Questa persona ha bisogno di vedere per se stesso ciò che il debito che la complessità porta durante la manutenzione o l'analisi.

La domanda che mi chiedo sempre la mia squadra è: "E '23:00 e si deve leggere questo codice - si può fare si capisce sotto pressione Si può, al telefono, non login remoto, condurli alla sezione in cui? essi possono correggere un errore?" Se la risposta è no, il follow-up è "Riesci a isolare alcune delle complessità?"

Se si ottiene un argomento in cambio, si tratta di una causa persa. Gettare qualcosa allora.

Vorrei dare loro 100 righe di codice tutti sotto 1 metodo e poi altri 100 righe di codice divisi tra diversi metodi e chiedere loro di scrivere una spiegazione di ciò che ciascuno fa.

Ora quanto tempo ci vuole a scrivere entrambi i paragrafi e poi mostrare loro il risultato.

... Assicurati di scegliere il codice che avrà due o tre volte più a lungo per capire se fosse tutto sotto lo stesso metodo - Main () -

Non c'è niente di meglio che imparare da esempio.

a breve ea lungo sono termini che possono essere interpretati in modo diverso. Per una breve è un metodo a 2 linee, mentre alcuni altro penserà che il metodo con non più di 100 righe di codice sono piuttosto breve. Penso che sarebbe meglio affermare che un singolo metodo non dovrebbe fare più di una cosa allo stesso tempo, il che significa che dovrebbe avere un solo responsabilità. Forse si potrebbe lasciare che i tuoi colleghi sviluppatori di leggere qualcosa su come mettere in pratica i principi solidi.

mi piacerebbe normalmente mostrare loro progetti precedenti che hanno metodi ben scritti. Vorrei quindi passare in rassegna questi metodi mentre spiega le ragioni per cui abbiamo sviluppato in quel modo.

Speriamo che quando guardando il quadro più ampio, avrebbero capito le ragioni di questo.

ps. Inoltre, questo esercizio potrebbe essere utilizzato in congiunzione come un trasferimento di conoscenze mini su progetti più grandi.

fargli vedere quanto facile è quello di testare i metodi brevi. Dimostrare che la scrittura metodi brevi renderà più facile e più veloce per lui a scrivere i test per i suoi metodi (ha testing questi metodi, giusto?)
lo porta su cui si stanno rivedendo il suo codice. "Questo metodo è piuttosto lungo, complicato, e sembra fare quattro cose distinte. Estrarre il metodo qui , qui e qui ".

Metodi lunghi di solito significa che il modello a oggetti è imperfetto, cioè una classe ha troppe responsabilità. Le probabilità sono che non si vuole solo più funzioni, ognuno più breve, nella stessa classe, ma quelle responsibilies correttamente assegnati a classi diverse.

Non serve insegnare a un maiale a cantare. Spreca il vostro tempo e infastidisce il maiale.

Basta mettere in ombra una persona.

Quando arriva il momento di correggere un bug nel 5000 la linea di routine, allora avrai una routine di dieci righe, e una routine di 4990-line. Fate questo lentamente, e nessuno si accorga di un cambiamento improvviso, tranne che le cose iniziano a lavorare meglio e lentamente la grande palla di fango evapora.

Si potrebbe voler dire loro che egli potrebbe avere davvero una buona memoria, ma non è così. Alcune persone sono in grado di gestire i metodi molto più a lungo rispetto ad altri. Se sia necessario essere in grado di mantenere il codice, può essere fatto solo se i metodi sono più piccoli.

Solo farlo se non ha un complesso di superiorità

[modifica] perché questo raccogliendo punteggi negativi?

Si potrebbe iniziare il refactoring ogni singolo metodo che ha scritto in più metodi, anche quando stanno attualmente lavorando su di loro. Assegnare il tempo in più per il vostro programma per "refactoring di altri metodi per rendere il codice maintanable". Farlo come si pensa che dovrebbe essere fatto, e - qui viene la parte educativa - quando si lamentano, dire loro che non avrebbe dovuto refactoring i metodi se avrebbero fatto bene la prima volta. In questo modo, il vostro capo viene a sapere che si deve correggere la pigrizia di altri, e vostri collaboratori imparare che dovrebbero renderlo diverso.

Questo è almeno un po 'di teoria.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow