Perché scrivere un codice pulito e refactored? [duplicare]

Ne vale la pena, e dovrebbe essere fatto da tutta la squadra. "Quando puzza, cambialo" funziona per neonati e amp; codice (grazie, Kent Beck).

Alcuni hanno detto che per un piccolo progetto a breve termine, non vale la pena farlo. Non sono d'accordo In primo luogo, raramente sappiamo quanto a breve termine sarà un progetto, ma in secondo luogo - quando lo fa schifo, cambialo. Se è puzzolente, o perché l'hai scritto maleodorante in primo luogo - e la tua squadra dovrebbe lavorare sulle sue capacità di codifica generale, e il refactoring è un buon allenamento per questo - o (più frequentemente) è stato malamente corretto e riproposto nel tempo. In tal caso - ovviamente non è un progetto a brevissimo termine. Se hai avuto il tempo di stopparlo, prenditi il tempo di cambiarlo.

Il refactoring - mantenere il tuo codice da una puzza - non è responsabilità di una persona designata nella tua squadra, e non è responsabilità di chi lo ha fatto puzzare. È tua responsabilità e responsabilità di tutti i membri del tuo team. Quando puzza, cambialo.

La domanda è simile al perché dovremmo mangiare cibo pulito . Punti semplici su cui puoi giocare la rete:

1. Maintainability
2. La leggibilità
3. Facile da estendere in seguito.
4. Mostra il carattere dello sviluppatore:)

Ma la "vale la pena" la domanda è un po 'complicata. Decidendo su questo, dovresti prendere in considerazione:

1. Per quanto tempo in futuro questo progetto potrebbe essere eseguito
2. Come si prevede che verranno aggiunte nuove funzionalità a lungo termine.
3. Fattore di rischio; Se è in prod, quanto è rischioso cambiare (pauroso)
4. Disponi di risorse sufficienti per "sprecare" (?) su di esso.

Dico ai miei studenti che questo è l'ordine in cui mi aspetto che venga scritto il codice (ciò che mi interessa di più o meno):

1. Documentazione - se non so cosa deve fare, come faccio a sapere se lo fa correttamente o no?
2. Formattazione e convenzioni - se non riesco a leggerlo, come faccio a sapere che cosa sta tentando di fare? Come potrò modificarlo se necessario ed è un casino?
3. Correggere - nessun punto nell'avere un programma che produce il risultato sbagliato
4. Veloce (un quarto lontano) - non c'è molto da dire qui

In parole semplici, il codice è scritto molto meno di quanto non sia letto. Non seguire le convenzioni (stile) e scrivere codice veloce e sporco rende molto più difficile leggere. La lettura SINGE è l'attività principale che consente di risparmiare tempo complessivo nel caso in cui il codice sia chiaro.

In realtà stai facendo diverse domande qui.

Why write clean, refactored code?

Si dovrebbe fare questo perché rende più facile la manutenzione e la verifica dei risultati. Se nessuno, a parte te, può capire come funziona il tuo codice senza un enorme spreco di tempo, allora può solo crederti sulla parola che sta facendo effettivamente ciò che dovrebbe. Se non sei disponibile quando viene rilevato un problema critico, è probabile che venga reso peggiore come fisso.

Mirare alla manutenibilità è stato uno dei comandamenti dell'ingegneria del software sin dalla notte dei tempi.

it's giving the desired results so what's the point of cleaning?

A seconda del tempo previsto del tuo progetto, potrebbe non esserlo. Se il tuo progetto durerà solo sei mesi in un lasso di tempo molto preciso, puoi probabilmente farla franca lasciando le cose come un disastro. I clienti in genere non si preoccupano di cosa sta succedendo sotto il cofano, vogliono solo che suoni e tweet al momento giusto.

Tuttavia, se siete a lungo termine, la manutenibilità diventerà un fattore importante. In media, puoi aspettarti e pianificare di perdere personale chiave se ti trovi in un periodo di oltre sei mesi.

In team projects, should there be someone specifically to refactor and check for clean code?

No, direi di no. La persona che "refactoring" il codice dovrebbe essere la persona che originariamente lo ha scritto, o ci saranno malintesi. Molto simile alle regole della normalizzazione del database, se passi un po 'di tempo a pensare e refactoring mentre vai (le opportunità per farlo dovrebbero essere ovvie mentre lavori sul codice), quindi non ci dovrebbe essere un sacco di codice disordinato in giro per te.

Certamente, non lasciarlo fino a dopo la completa funzionalità del codice , dal momento che dal punto di vista degli sviluppatori il loro lavoro è stato eseguito, la funzione è stata effettuata e possono chiudere il ticket.

Ridurre la qualità interna rallenta.

Se riduci la qualità interna, la produzione dei risultati desiderati in futuro richiederà sempre più tempo, con un rischio crescente.

Se scegli per prima cosa la cosa giusta - prima di tutto per ottenere il massimo - allora secondo me vale quasi sempre la pena di fare la cosa giusta.

Dai anche un'occhiata all'eccellente articolo di Martin Fowler: link

(citazione parafrasata: non appena la qualità interna viene inquadrata come commerciabile, gli sviluppatori, la gestione ei loro clienti hanno già perso).

Il codice sporco fa male quando devi lavorarci sopra. Lavorare con esso significa correggere un bug relativo al codice o aggiungere una funzionalità attorno al codice sporco. Non penso che ci sia molto valore nell'entrare e nel refactoring del codice arbitrariamente; il codice dovrebbe essere refactored quando lo si tocca per correggere un bug o aggiungere una funzionalità. In generale, adoro il libro del codice pulito l'idea di mettere in relazione ciò che dicono gli scout: lascia il campo più pulito di come l'hai trovato!

Se ciò viene seguito, la pulizia generale (e la qualità) miglioreranno gli straordinari, mentre i rischi (senza alcun motivo che non sia la pulizia) di modificare il codice attualmente funzionante saranno ridotti al minimo.

Non penso che le recensioni fatte dopo il test per assicurarsi che il codice sia pulito funzionerà, e avere una persona che esclusivamente refactors non funzionerà. Come sviluppatore penso che dovremmo tutti mangiare il nostro cibo. Quindi dovremmo essere responsabili per fare del buon cibo.

Se qualcuno continua a portare mele sfregiate al potluck, il resto è destinato a farlo cambiare oa farlo andare ... nessuno vuole mangiare mele marce. Dovremmo tutti portare cibo fantastico alla fortuna del piatto.

Penso che dipenda molto dal tuo progetto. Se si tratta di un progetto a prezzo fisso fatto da una persona durante 1 settimana, scrivere il codice come si desidera.

Ma se il team è più grande e lo sviluppo del progetto richiede più tempo, richiederà sicuramente una sorta di ri-factoring e cooperazione tra i membri del team durante lo sviluppo. Questi sono i punti in cui inizierai a goderti un design migliore e un codice più pulito.

La mia opinione:

Dipende! - Se il codice è inteso come una volta nello stile di fuoco una volta e dimentica ... quindi direi ... no, non vale la pena di refactoring. - Se il codice è destinato a durare a lungo e viene riutilizzato, direi: scrivi test unitari e refactoring passo dopo passo, non appena è necessario modificare / migliorare il codice o che utilizza quella parte di codici sporca.

Devi trovare il giusto equilibrio tra il rischio di rottura del codice di lavoro e i benefici in termini di costi di manutenzione e di prestazioni causati dal clean-up.

Il tuo codice verrà utilizzato da altri sviluppatori. Ancora di più, userete il vostro codice in futuro. Quindi, se investirai un po 'di tempo nella scrittura di codice pulito all'inizio, altri (e tu) risparmieranno molto più tempo in futuro durante il debug o la modifica del tuo codice.

Metterei i punti positivi sollevati da altre risposte in un modo leggermente diverso.

it's giving the desired results so what's the point of cleaning?

In altre parole "se non è rotto, non aggiustarlo". Che suona corretto, tuttavia non tiene conto del fatto che il codice può essere rotto in diversi modi - può essere:

• funzionalmente rotto (il più ovvio): non fa quello che dovrebbe fare,
• incomprensibile : è difficile da leggere e capire, quindi non è nemmeno chiaro cosa sia supposto fare,
• non testabile : è difficile o impossibile testarlo unitamente,
• non mantenibile : è difficile mantenerlo ed estenderlo - questo di solito è una conseguenza ravvicinata del fatto che sia difficile da leggere e / o unit test.

Ognuno di questi può ostacolare o addirittura uccidere un progetto a lungo termine.

Tutti hanno già risposto bene alla domanda. Ma il punto decisivo per decidere se ne vale la pena o meno dipende in larga misura dal fatto che l'app cambierà più nel tempo. Come tutti gli altri hanno detto, se funziona e non ha bisogno di cambiare, passare a cose con priorità più alta. Ma se hai intenzione di dover continuare a cambiarlo, quindi non refactoring per la pulizia e l'efficienza causerà problemi lungo la strada.

Ho lavorato su un'app veramente marcia una volta che, quando scritto in origine, era piccolo e abbastanza facile da gestire. Poiché anni di funzionalità aggiuntive e hack e correzioni scadenti hanno continuato a sommarsi, l'analista del team ha commentato una volta: "Quello che trovo più difficile per l'app ora è quanto tempo ci vuole per cambiarlo". Anche fare analisi di impatto per un nuovo cambiamento potrebbe essere costoso.

Tuttavia, la risposta alla tua domanda, in particolare quando si considera la parte di motivazione, sarà diversa a seconda di chi chiedi. Per un'app IT interna, in cui il costo è pagato dalle ore di straordinario gratuite, gli sviluppatori vorrebbero migliorare gli interni mentre pochi manager sarebbero interessati a modificarli. Per un negozio in cui la velocità di evoluzione è importante nel tempo del mercato, la qualità potrebbe fornire un vantaggio strategico, se si avesse una gestione che riteneva che la velocità di modifica di un'app ben sviluppata abbia superato la velocità di hacking di una nuova funzionalità. E purtroppo, anche in alcuni veri negozi di software, ho la sensazione che molti manager decidano che gli hack sono più veloci. Forse lo sono, ma, di nuovo, il dolore in corso è solitamente avvertito dagli sviluppatori e non da altri nell'organizzazione.

Dal punto di vista del business non ho grosse obiezioni per il codice sporco one-off se funziona. C'è un sacco di software scadenti che fanno soldi per gli affari.

Ma le buone abitudini e le capacità di programmazione non arrivano dal nulla, devono essere sviluppate. Scrivere un buon codice è un ottimo esercizio per scrivere un buon codice. Più scrittore di codice buono scrive, più diventa facile da fare. È abbastanza naturale scrivere un buon codice, non è più difficile o più lento di scrivere codice sporco, questa è solo un'esperienza + buone abitudini e questa esperienza e abitudini non possono essere ottenute scrivendo codice sporco o semplicemente leggendo libri. Quindi non scrivere codice sporco e non lasciare che sia il tuo team a farlo e sarai uno sviluppatore migliore con un team migliore in un dato momento. Le attività e le scadenze aziendali vanno, le competenze rimangono.

Il codice di riscrittura per renderlo "pulito" o "pulito" non dovrebbe essere intrapreso alla leggera. A meno che non si abbia il tempo di conoscere veramente il codice, prima è possibile commettere errori che possono essere molto difficili da catturare, ma rendere parti di un sistema che hanno funzionato in modo affidabile per anni falliscono in modi misteriosi.

Anch'io sto lavorando a un compito simile, dove le cose sono andate troppo in là (classe anti-modello di Dio, chiunque, massiccia programmazione di copia-incolla, ecc.). Lì ho avuto il tempo, e ancora ho fatto solo una piccola parte di quello che mi sarebbe piaciuto davvero fare perché non sono sicuro di fare tutto, le modifiche necessarie per rendere davvero il codice di qualità sarebbe troppo grande e sarebbe efficace significa una riscrittura che è fuori dalla portata di questo progetto (quello che ho fatto è rendere il codice un po 'più facile da leggere in modo da trovare i luoghi che dovevo apportare alle modifiche per il progetto e centralizzare quelle modifiche piuttosto che spruzzarle loro dappertutto) E anche un cambiamento così limitato (limitato, come nel ridurre la classe di linea 9500 esistente a 8100 linee, un vero refactoring lo dividerebbe in diverse dozzine di altre classi e probabilmente introdurre un quadro di accesso al database completo come iBatis) ha dei rischi ad che richiede un nuovo test dell'intera applicazione che potrebbe produrre problemi introdotti dal cambiamento. L'ho fatto solo perché era già stato richiesto un nuovo test per l'impatto delle modifiche molto minori che ho apportato alla funzionalità (piuttosto che all'implementazione tecnica) del sistema.

Vedo due motivi principali:

Maintainability

Perché la persona che dovrà mantenere il codice potrebbe essere uno psicopatico che sa dove vivi. O peggio , potresti essere tu a mantenerlo e per allora, avrai dimenticato tutto su come è strutturato internamente.

Più facile da eseguire il debug

Aiuta ad avere solide fondamenta su cui basare quando è necessario aggiungere più funzionalità, in questo modo è più rapido identificare dove provengono i bug.

È essenzialmente una questione di soldi.

Migliore è il codice, più facile (e più economico ) da mantenere. Sia per gli altri, ma anche per coloro che lo hanno originariamente scritto.

Sfortunatamente, questa esperienza non può essere comunicata correttamente senza effettivamente provarla, il che significa che può esserci una base di codice molto ampia che ha bisogno di molto lavoro per entrare in uno stato ragionevole, il che significa che non è più il più economico da fare è giusto perché potresti dover ricostruire troppo. Questo è il vicolo cieco, molte esperienze.

Se hai bisogno di spiegarlo a persone non tecniche, confrontalo con una casa. Se le stampe blu di base non sono valide, dovrai fare un sacco di lavoro extra e hai ancora una casa di livello inferiore.

Considera le implicazioni degli esempi di FizzBuzz in questo articolo . Le due versioni e le loro modifiche danno gli stessi rispettivi output, ma quale vorresti mantenere, specialmente in un ambiente con requisiti in costante cambiamento?

Il mio consiglio: quando i vincoli di programmazione sono stretti, se il codice non è rotto non risolverlo. Quando gli orari diventano più flessibili e le scadenze non si profilano più, prenditi il tempo necessario per correggere il codice più problematico o meno modulare, ma sempre all'interno delle linee guida dell'architettura generale del sistema.

Inizi su un progetto con una serie iniziale di requisiti. Mentre il progetto si sposta, il requisito continua a cambiare ed è necessario estendere il codice.

Quando iniziamo a scrivere il codice, cerchiamo di farlo funzionare secondo i requisiti che abbiamo attualmente e quelli che indoviniamo che potrebbero apparire.

Se non rifatti il tuo codice, c'è il rischio che non sia facile estenderlo o essere leggibile da altri.

Il refactoring del codice mostra in più la chiarezza di ciò che hai fatto e ti dà l'opportunità di correggere potenziali bug.

Per me, in pratica, questa domanda si traduce in "Perché scrivere un codice più piccolo?", perché in pratica blocchi di codice più piccoli e più unitari invitano la possibilità di un design più bello e pulito. Manipolare questi blocchi più piccoli diventa molto più facile di quelli grandi, e sono più invitanti per essere rifattorizzati secondo necessità.

Ora, la mia risposta :

dopo aver rimuginato su alcuni refactoring legacy del codice legacy significativamente decenti, è stata la mia esperienza, che grandi blocchi di codice (classi, funzioni, ecc.) invitano più codice. Più codice applicato indiscriminatamente rompe le cose come il principio di responsabilità e altre buone pratiche.

Quindi la mia risposta è perché scrivere un codice più piccolo?

• ti costringe a pensare di più alla struttura del codice e al layout, evitando nel contempo la mentalità (e talvolta la necessità) di "facciamo più cose in questo blocco di codice". Dico necessità, perché quando si incontra un blocco enorme, potrebbe essere necessario far funzionare le cose ora, piuttosto che prendere tempo per il refactoring, a causa delle pressioni temporali.

• È più facile eseguire lavori di refactoring su una serie di pezzi di codice autonomi più piccoli, anche se sono brutti, piuttosto che lavorare su una rottura di enormi e brutti metodi ingarbugliati.

• aiuta i futuri programmatori che lavoreranno sulla tua base di codice per capire cosa stavi facendo. Anche se non sempre sono vere, le unità di codice più piccole che hanno il loro scopo e che sono ragionevolmente autonome, ti aiuteranno a costruire un modello mentale più veloce del lungo ambiguo codice di tutto il codice.

• impedisce ai futuri programmatori di attuare ciò che [heck] dovrebbe fare questo codice? e perché questo o quel pezzo di codice fa queste cose in questo modo particolare e particolare ?, poiché i grandi blocchi di codice tendono a nascondere cattive pratiche e vari bug ed errori logici.