No.
Risolvi il problema mentre ci lavori:
La mia opinione personale: è assolutamente richiesto per il 90% dei progetti.
In particolare per i progetti che sono strongmente guidati dalle vendite, di solito c'è una grande spinta per includere nuove funzionalità in ogni versione, e inevitabilmente si finisce per dover compromettere i propri istinti migliori e introdurre alcuni kludge / hack qua e là.
Alla fine hai accumulato abbastanza "debito tecnico" attraverso questi piccoli compromessi che finisci per spendere una discreta quantità di tempo per aggirare i difetti della base di codice, e non sei in grado di utilizzarlo per il suo pieno potenziale.
Di solito ci sono due tipi di problemi generati in questo modo:
In genere cerco di riservare il tempo per un puro ciclo refactorring / bug-fixing ogni 3 o 4 cicli. Chiedo sempre ai miei sviluppatori di dirmi quando si sentono frustrati anche con la base di codice. Non tutti gli sviluppatori devono lavorare sullo sforzo di pulizia: di solito (ma non sempre) riescono a scaglionare un po 'le squadre, quindi solo una squadra sta lavorando alla pulizia in qualsiasi momento.
I miei sviluppatori hanno messo in ordine il loro codice prima di effettuare il checkin (Subversion) o di unirsi al ramo di sviluppo principale (Git).
Li ho fatti come segue:
Per i progetti più grandi, il codice viene esaminato formalmente prima di unire dal ramo di sviluppo al ramo principale.
Penso che "dedicare il tempo" significherà che è qualcosa che potrebbe essere differito, o rimandare a causa della quantità di lavoro coinvolto. Avendo sviluppatori che lo fanno su un check-in (che equivale a una richiesta / problema di modifica in JIRA) è molto più gestibile.
Non secondo me. Se si lascia passare troppo tempo quando si incontra il debito tecnologico e quando lo si aggiusta, si perde il contesto di quale sia il problema. Ci vuole più tempo per sistemare e tende a peggiorare. Ancora più importante, le persone lasciano le finestre rotte perché non è una "settimana di pulizia".
Personalmente, negozo 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 che il refactoring sia più semplice. Impedisce l'accumulo di debiti tecnici. E aiuta a spingere gli sviluppatori dallo schiaffeggiare qualcosa insieme, perché li farò fare proprio al prossimo sprint (quindi potrebbe anche farlo bene in primo luogo).
Direi di sì sì, con una riserva: dovrebbe essere fatto spesso, preferibilmente su base settimanale. Credo che una regolare revisione periodica del codice unita all'effettiva azione sugli elementi che escono dalla revisione del codice si ripaga molto rapidamente. Vedi la risposta di p.s.w.g.
1 settimana ogni 2 mesi non è sicuramente abbastanza spesso. Questo parla alla maggior parte delle altre risposte che hanno risposto con "No" alla tua domanda. Il succo 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 sistemare / ripulire / refactare.
Non è chiaro se si intendesse di tanto in tanto un ulteriore esercizio di pulizia del codice. In questo senso, sì. Quali sono le pratiche che seguiamo, si verificano sempre alcuni casi di degrado.
Non dovresti usarlo come scusa per non fare la cosa giusta [applicazione di principi SOLID, test unitari rilevanti, ispezioni ecc.] in primo luogo.
Penso che le attuali due popolari "No" risposte "Sì" siano due aspetti della stessa verità. Ricorda che l'OP sta parlando di un gruppo che sta gestendo, non solo se stesso come individuo. Non possiamo assumere 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 stile agile. Inoltre, anche con i migliori sforzi delle persone, le loro differenze nello stile significheranno che potrebbero scrivere codice che sarebbe considerato pulito quando separato, ma impuro se considerato insieme alle altre (per non parlare delle interfacce scricchiolanti).
D'altra parte, il "aggiustarlo mentre ci lavori" è a mio parere un ideale da cui aspirare. Puoi rendere il tuo codice ancora più "fisso" di
Ora, se la squadra dell'OP adotta quanto sopra, e se incoraggia i suoi subordinati - ad es. durante le revisioni del codice e durante le sessioni periodiche di pulizia del codice, per cercare di anticipare le insidie ed evitare bruttezze in anticipo, nel tempo sperano di aver bisogno di meno tempo per la 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 la pianificazione dei tempi regolari sia ottima se si tratta di un compito in un normale progetto in stile cascata o di storie agili. Avere un tempo prestabilito potrebbe non essere così prezioso come solo lavorando nel tuo programma. Ciò ti consente di farlo funzionare 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, lavorarci regolarmente era la chiave per far funzionare le cose senza intoppi. Alcune delle nostre cose erano grandi, altre erano piccole.
Dopo alcuni mesi di questo tipo di lavoro, il nostro team operativo mi ha detto che tutto andava liscio.
Ogni articolo potrebbe non sembrare molto, ma proprio come tutto il debito, si pubblicizza.
La risposta ideale è No, perché fai i passi necessari per evitare di renderlo necessario (ripulisci mentre procedete per diversi motivi già indicati).
Questo può essere l'obiettivo alla fine, ma potresti avere una squadra che è lontana dal metterla in pratica.
I manager devono assumersi delle responsabilità Non è sempre colpa dello sviluppatore. I manager possono dire una cosa, ma iniziano a spingere affinché i progetti finiscano e danno suggerimenti che promuovono le cattive pratiche. Potrebbero letteralmente dire "lo puliremo più tardi" o se funziona, è abbastanza buono.
Potrebbe essere necessario iniziare dedicando un particolare momento per mostrare che è importante. Una volta che sai che la tua squadra è in grado di ripulire il loro codice (non un dato), puoi provare a incorporarlo più frequentemente.
Alla fine, non dovresti impostare un'ora.
Personnamente, faccio fatica a risolvere un nuovo problema e a farlo funzionare mentre cerco di tenere le cose in ordine. Sto migliorando, ma spesso prendo una pausa deliberata e pulisco le cose. È una mentalità diversa per me. Alla fine, le solide pratiche diventano abitudine.
No, dovresti farlo mentre stai codificando. Questo è chiamato refactoring se stai usando TDD. Il problema quando aspetti un mese o due per risolvere e pulire il tuo codice è che potresti modificare il comportamento del codice perché non ricordi ogni parte del tuo codice.
Suggerisco il refactoring che si basa sulla codifica prima del codice necessario per far funzionare qualcosa, e non appena funziona ridisegnarlo, ottimizzarlo e renderlo carino.
Leggi altre domande sui tag project-management refactoring programming-practices maintenance