È una buona idea pianificare un orario regolare per ripulire il codice? [chiuso]

Sto gestendo un piccolo team di sviluppatori. Ogni tanto decidiamo che passeremo un giorno o due a ripulire il nostro codice.

Sarebbe una buona idea programmare un orario regolare, diciamo 1 settimana ogni 2 mesi, per ripulire il nostro codice?

No.

Risolvilo mentre ci stai lavorando:

• Se aspetti di rifattorizzare la parte su cui stai lavorando, te ne dimenticherai molto e dovrai dedicare del tempo per familiarizzarti di nuovo.
• Non finirai con il codice di "doratura" che non verrà mai utilizzato perché i requisiti sono cambiati

La mia opinione personale: è assolutamente necessario per il 90% dei progetti.

Soprattutto per i progetti che sono fortemente guidati dalle vendite, di solito c'è una grande spinta per includere nuove funzionalità in ogni versione, e inevitabilmente finisci per dover compromettere i tuoi migliori istinti e introdurre qualche clamore / hack qua e là.

Alla fine hai accumulato abbastanza "debito tecnico" attraverso questi piccoli compromessi che finisci per passare un bel po 'di tempo a risolvere i difetti della base di codice e non sei in grado di sfruttare al massimo il suo potenziale.

Di solito ci sono due tipi di problemi generati in questo modo:

• Quelli di piccole dimensioni che possono essere facilmente risolti ma possono essere sistemici, ad es. Parametri con nomi errati, gestione degli errori incompleta, ecc. In genere avranno un impatto minimo al di fuori del blocco di codice in cui vengono visualizzati. Il modo migliore per gestirli è la revisione del codice e la verifica del codice mentre viene scritto / modificato. Come altri hanno già affermato, non è necessario mettere da parte uno speciale ciclo di rifattori per correggere questi errori.
• Quelli grandi che potrebbero essere nati da specifiche incomplete o decisioni di progettazione sbagliate all'inizio o due sviluppatori / team che hanno creato due diverse soluzioni allo stesso problema. Questi sono generalmente molto più difficili da risolvere e richiedono uno sforzo concertato per risolvere. Di conseguenza, di solito vengono differiti, fino a diventare un fastidio perpetuo. Questi tipi di problemi richiedono un periodo di tempo dedicato da risolvere.

In genere cerco di riservare del tempo per un ciclo di refactorring / correzione di bug puro ogni 3-4 cicli. Chiedo sempre ai miei sviluppatori di dirmi quando si sentono frustrati anche dalla base di codice. Non tutti gli sviluppatori devono lavorare allo sforzo di pulizia, in genere è possibile (ma non sempre) scaglionare un po 'i team, quindi solo un team sta lavorando alla pulizia in un determinato momento.

Ho i miei sviluppatori a riordinare il loro codice prima di fare il check-in (Subversion) o di unirmi al ramo di sviluppo principale (Git).

Li faccio fare quanto segue:

• Rimuovi commenti irrilevanti
• Assicurati che i loro metodi, argomenti e variabili siano opportunamente nominati
• Assicurati che ci sia una struttura nelle loro classi e che gli oggetti siano incapsulati come dovrebbero essere
• Rifattore per migliorare la leggibilità e ridurre gli odori di codice

Per i progetti più grandi, il codice viene rivisto formalmente prima della fusione dal ramo di sviluppo al ramo principale.

Penso che "dedicare tempo" significherà che è qualcosa che potrebbe essere rinviato o rimandato a causa della quantità di lavoro coinvolto. Avendo gli sviluppatori fare un check-in (che equivale a una richiesta di modifica / problema in JIRA) è molto più gestibile.

Non secondo me. Se lasci passare troppo tempo tra l'incontro con il debito tecnologico e quando lo risolvi, perdi il contesto di quale sia il problema. Richiede più tempo per risolvere e tende a risolversi peggio. Soprattutto, le persone lasciano le finestre rotte perché non è "settimana di pulizia".

Personalmente, negoziando per la pulizia del debito tecnico ogni sprint se so che ne abbiamo creati alcuni nello sprint prima. Mantiene il debito fresco nelle menti delle persone. Limita la quantità di codice utilizzando il codice problema in modo da semplificare il refactoring. Previene l'accumulo del debito tecnico. E aiuta a spingere gli sviluppatori a schiaffeggiare qualcosa insieme, perché ho intenzione di farli fare proprio nel prossimo sprint (quindi potrebbe anche farlo proprio in primo luogo).

Direi sicuramente di sì, con una condizione: dovrebbe essere fatto spesso, preferibilmente su base settimanale. Credo che una revisione periodica programmata del codice unita all'effettiva azione sugli articoli che escono dalla revisione del codice ripaghi molto rapidamente. Vedi la risposta di pswg

1 settimana ogni 2 mesi non è assolutamente abbastanza frequente. Questo parla alla maggior parte delle altre risposte che hanno risposto con "No" alla tua domanda. L'essenza della maggior parte di queste risposte è che se aspetti troppo a lungo non sarai più in contatto con il codice e di solito ci vuole molto più tempo per riparare / pulire / refactoring.

Non è così chiaro se ogni tanto intendevi un ulteriore esercizio di pulizia del codice. In questo senso, sì. Qualunque pratica seguiamo, si verifica sempre un certo degrado.

Non dovresti usarlo come scusa per non fare la cosa giusta [Applicazione dei principi SOLID, test unitari pertinenti, ispezioni ecc.] In primo luogo.

Penso che attualmente le due popolari risposte "No" "Sì" siano due aspetti della stessa verità. Ricorda che l'OP parla di un gruppo che gestisce, non solo di se stesso come individuo. Non possiamo presumere che tutti gli sviluppatori del gruppo siano abbastanza disciplinati da scrivere codice pulito e facilmente leggibile; e c'è il problema della pressione esterna e delle metodologie di tipo agile. Inoltre, anche con i migliori sforzi delle persone, le loro differenze di stile significheranno che potrebbero scrivere codice che sarebbe considerato pulito se separato, ma impuro se considerato insieme ad altre persone (per non parlare delle interfacce scricchiolanti).

D'altra parte, il "aggiustalo mentre ci lavori" è secondo me un ideale per cui aspirare. Puoi rendere il tuo codice ancora più "risolto" da

• attento scrutinio tra pari
• scrivere unit test insieme al codice stesso
• adottando le linee guida di codifica
• utilizzando formattatori e linter automatici (ma YMMV)
• eccetera.

Ora, se il team del PO adotta quanto sopra e se incoraggia i suoi subordinati - ad esempio durante le revisioni del codice e durante le sessioni periodiche di pulizia del codice - a cercare di anticipare le insidie ​​ed evitare bruttezza in anticipo, nel tempo avrà probabilmente bisogno di meno tempo di pulizia. (E poi potrebbero dedicare quel tempo alla documentazione, al refactoring più profondo e alla condivisione della conoscenza di ciò che hanno scritto e consolidato.)

Penso che programmare l'orario regolare sia molto buono sia che si tratti di un compito in un normale progetto a cascata, sia di storie in uno agile. Avere un tempo prestabilito potrebbe non essere prezioso come solo lavorarlo nel tuo programma. Questo ti consente di farlo come parte del programma rispetto all'annullamento del giorno di pulizia perché sei indietro nel progetto.

Avendo gestito un progetto che aveva un'enorme quantità di debito in codice, lavorarli su base regolare era la chiave per far funzionare le cose senza problemi. Alcune delle nostre cose erano grandi, altre piccole.

Dopo alcuni mesi di questo tipo di lavoro, il nostro team operativo mi ha detto quanto tutto andava liscio.

Ogni articolo potrebbe non sembrare molto, ma proprio come tutti i debiti, è pubblicizzato.

La risposta ideale è No, perché prendi le misure necessarie per evitare di renderlo una necessità (pulisci mentre procedi per diversi motivi già indicati).

Questo potrebbe essere l'obiettivo alla fine, ma potresti avere una squadra che è ben lungi dal metterlo in pratica.

I manager devono assumersi alcune responsabilità Non è sempre colpa dello sviluppatore. I manager possono dire una cosa, ma iniziano a spingere affinché i progetti finiscano e formulino suggerimenti che promuovono cattive pratiche. Potrebbero letteralmente dire "lo ripuliremo più tardi" o, se funziona, va bene.

Potrebbe essere necessario dedicare un determinato momento per dimostrare che questo è importante. Una volta che sai che il tuo team è in grado di ripulire il loro codice (non un dato), puoi provare a incorporarlo più frequentemente.

Alla fine, non dovresti impostare un orario.

Personalmente, faccio fatica a risolvere un nuovo problema e farlo funzionare mentre cerco di mantenere le cose in ordine. Sto migliorando, ma spesso faccio una pausa deliberata e pulisco le cose. È una mentalità diversa per me. Alla fine, le pratiche solide diventano un'abitudine.

No, dovresti farlo mentre stai programmando. Questo si chiama refactoring se si utilizza TDD. Il problema quando aspetti un mese o due per correggere e pulire il tuo codice è che puoi modificare il comportamento del codice perché non ricordi ogni parte del tuo codice.

Suggerisco il refactoring che si basa innanzitutto sulla codifica del codice necessario per far funzionare qualcosa, e non appena funziona riprogettalo, ottimizzalo e rendilo carino.