In riferimento a finestre rotte , ci sono momenti in cui è meglio lasciare il refactoring per un futuro attività?
Ad esempio, se un progetto per aggiungere alcune nuove funzionalità a un sistema interno esistente viene assegnato a un team che non ha lavorato con il sistema fino ad ora e riceve una breve tabella temporale con cui lavorare, può essere sempre essere giustificabile a rinviare i principali refactoring al codice esistente al fine di rendere la scadenza in questo scenario?
Il refactoring è - e dovrebbe essere - un processo in corso. Non è sufficiente soddisfare semplicemente i requisiti con un'implementazione funzionante e testata che è ancora un po 'incompleta.
"Make it work, then make it work better".
Non riesco a ricordare dove ho letto quella citazione, ma questa è la chiave per applicare bene il refactoring, e considero poco professionale fare altrimenti.
Il refactoring continuo è come pulire le fuoriuscite durante la cottura e pulire i piatti dopo aver mangiato il pasto. Il refactoring mirato è come trovare una cucina sporca, ma solo avere il tempo di lavare un bicchiere sporco o due. Preferiresti vivere con una cucina continuamente sporca, o preferiresti mantenere le cose pulite mentre vai avanti?
Ottieni il codice per funzionare, quindi ti rifatti il codice per assicurarti di avere la migliore implementazione che tu possa usare. Se stai facendo qualcosa di familiare, potrebbe essere che tu implementi il codice migliore per la prima volta, tuttavia ci vorrà un momento per ricontrollare il tuo lavoro per essere sicuro. Se sembra che tu possa migliorare il tuo codice, prova a fare il refactoring per assicurarti che il tuo codice sia per lo meno snello e pulito come puoi farlo. Ciò significa che stai riducendo la quantità di debito tecnico che hai lasciato e rendi più facile la lettura e il refactoring la prossima volta che il codice deve essere trattato. Questo è il valore fondamentale alla base del mantra TDD "Red-Green-Refactor", tranne per il fatto che in TDD si refactoring principalmente per rimuovere la duplicazione, si paga anche per rivedere altri elementi che potrebbero essere refactored, come grandi classi, metodi lunghi e altri "odori di codice" che spesso possono contribuire al debito tecnico.
Se ti trovi di fronte a una riprogettazione importante, allora forse puoi rimandare per un po ', specialmente se stai andando molto in basso nel tuo programma. Ciò tuttavia è previsto non compromettendo la funzionalità del codice e purché l'implementazione continui a soddisfare i requisiti. Questo tipo di situazione dovrebbe essere un evento raro e puoi contribuire a garantire che sia ancora più raro se continui a refactoring mentre vai avanti. Ancora più importante, tuttavia, è che non si può rischiare di lasciare le modifiche importanti per troppo tempo, altrimenti si finirà per creare un carico di lavoro ancora più grande in seguito, che potrebbe essere molto più costoso da risolvere, o potrebbe finire per risultare ancora più costoso fallimento del progetto.
Ho l'impressione che molte persone tendano a confondere le definizioni di Refactoring e Re-engineering . I due termini descrivono le strategie per gestire situazioni molto diverse. Se desideri riprogettare, ti stai impegnando a fare un cambiamento drastico che altererà il comportamento di un sistema. Ciò annullerà alcuni test e richiederà anche nuovi test. Quando sei Refactor, stai assicurando che il tuo sistema continui a comportarsi esattamente come prima della modifica, tuttavia stai anche assicurando che il tuo codice abbia una longevità e che sia più facile mantenere nel tempo. Non stai "sfruttando" il tuo codice per l'inferno, ti stai impegnando per uno standard professionale di codice pulito che ridurrà il rischio di insuccesso e garantirai che il tuo codice rimarrà un piacere con cui lavorare e di uno standard professionale .
Tornando all'analogia delle finestre rotte, se rompi la finestra dovresti ripararla subito. Se non hai notato che una finestra è rotta, devi decidere il costo per te se lasci la finestra rotta. Ora, ripeti le due frasi precedenti, ma sostituisci Bug per window . Finisci per aver bisogno di una strategia diversa. Se hai creato un bug durante la codifica, lo risolvi subito o vedi se le modifiche richiedono uno sforzo di reingegnerizzazione e prendi una decisione commerciale su quando è meglio risolvere il problema. Quindi non ti rifattori per risolvere un problema, ti rifatti per assicurarti che sia più facile trovare e risolvere i problemi. Non mi importa di quanto pensi sia sorprendente il tuo codice, i sistemi complessi avranno sempre problemi che dovranno essere affrontati nel tempo. Questo è il problema del debito tecnico e perché il refactoring deve essere un processo continuo mentre implementa il tuo codice e non essere lasciato per un tempo arbitrario futuro.
In breve, la risposta è che in rare occasioni può essere accettabile rinviare importanti modifiche al codice al fine di rispettare una scadenza, tuttavia non dovrebbe essere considerata una pratica normale per trattare il refactoring come un esercizio indipendente dal tuo lavoro quotidiano di implementazione , e certamente non è mai stato usato come scusa da gruppi non familiari con la base di codice come opzione per evitare di garantire che la loro implementazione sia snella e pulita come è possibile farlo nelle circostanze.
Alcuni sviluppatori dicono che stanno "Riparando le finestre rotte" quando in realtà "stanno riorganizzando le sedie a sdraio sul Titanic". Il codice di refactoring che funziona ma offende il tuo senso dell'olfatto è relativamente facile. Se trovi che continui a tornare a quel tipo di compito invece di aggiungere nuove funzionalità per i tuoi utenti o rendere l'app più utilizzabile per loro (il significato dell'ottimizzazione che rende l'applicazione più veloce è buono qui, l'ottimizzazione significa rendere il codice più leggibile è diverso) allora forse stai riordinando troppo. Non perché il riordino sia cattivo, ma perché l'azienda paga per lo sviluppo per ottenere qualcosa di sviluppato. Non vogliono una soluzione fragile, difficile da leggere e scarsamente architettata, ma non vogliono nemmeno una mezza soluzione lucida e bella.
Fai ordine quando devi fare qualcosa di semplice "andare avanti", o quando aspetti che un'altra squadra ti dica se il tuo problema è in realtà colpa loro o quando aspetti una decisione. Ci saranno molte opportunità. Se hai la possibilità di spostare l'intera app in avanti, prendila, a meno che tu non stia iniziando a sentire che tutto è diventato fragile. Probabilmente no. Avrai la possibilità di refactoring - non devi preoccuparti di questo.
Per tornare alla seconda metà della tua domanda, uno sprint per aggiungere feature di fronte a una timeline breve, sarebbe sbagliato dire "e non faremo alcun refactoring, non c'è tempo." Sarebbe anche sbagliato dire "So che sono passate 6 settimane e sembra esattamente lo stesso per gli utenti, ma queste finestre rotte hanno davvero bisogno di essere corrette". Adatta il refactoring nelle lacune che si verificano in qualsiasi progetto. Non prendere rifugio nel riordinare a scapito del raggiungimento dell'obiettivo del progetto.
Da un punto di vista del business, il refactoring è un investimento speculativo - investendo tempo e sforzi (denaro) ora, nella speranza che risparmierà più tempo e sforzi (denaro) in futuro.
Senza entrare nel dibattito su quanto lo sforzo per il refactore salverà in futuro (dipende da troppe variabili per essere una discussione maligna qui), è chiaro che il momento del refactoring è quando la "rete" valore attuale "del costo che lascia eccedere il costo del fare ora.
È facile, a meno che tu non abbia idea di quanto costerebbe l'allevamento. È inoltre necessario tenere conto di tutte le normali idee di pianificazione finanziaria come il ritorno sull'investimento, la gestione del rischio (valore del marchio, responsabilità legale, rischio assicurabile vs non assicurabile), costo dell'oppertibilità ecc.
Nella maggior parte dei casi, decidere quando è il refattore è meglio lasciare alle persone che gestiscono il business. Nonostante ciò che molti posters su questo vocalize del forum, i manager di solito sanno più lontano di gestire un'azienda rispetto ai programmatori. Hanno in mente un quadro più ampio che include la massimizzazione del ritorno all'azionista. È raro che la correzione di cose non interrotte contribuisca a questo, il codice non fa eccezione.
Modifica: ho letto un interessante articolo sui programmi di manutenzione sull'infrastruttura critica. L'essenziale è che il movimento è lontano dalla routine di mantenimento (refactor) per riparare quando necessario (correggere i bug). La principale differenza sono i livelli di monitoraggio - ad esempio una centrale nucleare monitora in modo molto dettagliato e si ripara quando "rotto" ma ben prima del fallimento. Ciò che è stato scoperto è che la fissazione a un programma di manutenzione non solo costa di più, ma è meno affidabile a causa di interruzioni causate dal programma di manutenzione. Un'idea simile è richiesta per il software - refactoring i bit che stanno per rompersi - che puoi conoscere solo tramite misurazione.
È accettabile quando il danno all'azienda risolvendolo è maggiore che non risolvendolo.
Le situazioni in cui ciò potrebbe accadere potrebbero essere:
E queste situazioni si verificano - le situazioni commerciali spesso escogitano scadenze artificiali che devono essere soddisfatte laddove è passata l'opportunità di negoziare e i requisiti che hanno una componente temporale - ad esempio una modifica della legislazione o delle norme fiscali che vengono in vigore di una data specifica - esistono.
Il trucco consiste nell'identificare queste situazioni e valutarle correttamente. Il codice che è programmato per essere ritirato rimarrà spesso per anni. Potrebbe essere necessario rispettare le scadenze artificiali, ma possono spesso essere soddisfatte in diversi modi (ad esempio, i software possono essere presentati, dimostrati e "lanciati" in una determinata data senza che la versione finale sia necessariamente completata fino a tardi).
Quando viene presentato questo genere di cose devi avvicinarti con una mente aperta, ma chiedi sempre che cosa appare? Le ipotesi sono realistiche? Esiste un altro modo per raggiungere l'obiettivo senza la spedizione di un codice substandard? Se non c'è, come posso usare al meglio il tempo che ho a disposizione?
E se non esiste un'alternativa sempre valida, ma quando ripareremo?
Perché dovrebbe quasi, quasi, essere quasi sempre quando , non if .
Se i manager decidono che vogliono creare debito tecnico . Questa è una decisione giusta da fare se, ad esempio, si desidera solo un prototipo iniziale per alcuni clienti iniziali per ottenere un feedback iniziale.
Puoi pensarci nello stesso modo in cui chiedi il credito. Va bene prendere in prestito denaro per investire in X a breve termine e pagarlo a lungo termine? Non esiste una risposta definitiva, può essere nel migliore interesse dell'organizzazione (ad esempio per soddisfare le attuali aspettative del cliente), oppure può essere un disastro se fatto in modo irresponsabile.
Tutto si riduce alle priorità, e il management dovrebbe essere consapevole del fatto che, sebbene la priorità numero uno sia rendere il "codice funzionante", implementare nuove funzionalità e soddisfare le aspettative del cliente, ogni volta che si lasciano finestre rotte si sta facendo quel numero una priorità più lenta, più difficile e richiede maggiori investimenti in risorse. Inoltre, il 99% delle volte non è fattibile smettere di sviluppare nuove funzionalità e concentrare ogni sforzo per "riparare la base di codici".
In conclusione, sì, è accettabile lasciare a volte finestre rotte, proprio come è accettabile chiedere un prestito ... ricorda solo che in realtà devi davvero pagarlo per il futuro. E in futuro, il tempo per farlo probabilmente non sarà molto più grande del tempo che hai ora.
Normalmente, quando si è in grado di farlo, si dovrebbe risolvere il problema, in modo da evitare potenziali perdite di tempo per la manutenzione. Tuttavia, alcune pratiche barbariche non agili tendono a lasciare lo status quo finché è funzionante. Alcuni manager temono gli "effetti imprevisti" del cambiamento.
Il mio intento è di lasciarlo solo se funziona come dovrebbe (rotto solo dall'ottimizzazione ma non dalla funzionalità) e ti manca il tempo per testarlo, se fai qualche refactoring. Tuttavia, dovresti tenere presente che dovrebbe essere risolto in un secondo momento il più presto possibile.
Se la sua funzionalità è spezzata e le nuove funzionalità dipendono da essa, sarebbe meglio correggerla al più presto.
La maggior parte dei programmatori è nel business di fare soldi per il proprio datore di lavoro. Quindi, quando dovrebbe accadere il refactoring: quando fa soldi solidi. Il refactoring è il tempo impiegato non speso per altri progetti e il tempo risparmiato in futuro su questo progetto.
Che ne valga la pena dipende principalmente dal tuo manager.
I programmatori dovrebbero consentire all'azienda di conoscere l'entità del debito tecnico, in modo che possano prendere una decisione informata. Se la necessità di arrivare sul mercato prima supera il rischio del tuo codice, non hai molta scelta. La mancanza di flusso di cassa supererà molte decisioni tecniche.
Per mettere alcuni dei problemi in una prospettiva non tecnica, indica il tempo prolungato per correggere i bug e aggiungere nuove funzionalità. Se la direzione ha un background di vendite e marketing, potrebbe capirlo. Detestano dover dire ai clienti che queste cose impiegheranno più tempo.
Se stai pensando di espandere la tua squadra, questo potrebbe essere un buon momento per assumere uno sviluppatore junior. La copertura del test sarà un enorme salvatore in questo caso. Impareranno di più facendo piuttosto che leggendo la documentazione.
can it be ever be justifiable to defer major refactorings to existing code for the sake of making the deadline in this scenario?
Tuttavia, se stai parlando di rielaborare codice funzionante, allora prenderei in considerazione quanto segue:
Se dipendesse dai nostri sviluppatori senior o dal direttore tecnico di quanto non avremmo mai rilasciato alcun software. Rifichiamo sempre e puntiamo al perfezionismo.
Se il ri-factoring avrà un impatto negativo sulla redditività delle attività, dovrebbe essere riprogrammato.
Se la tua azienda ha promesso di fornire determinate funzionalità entro una determinata data, allora ti rifatterò più tardi. Pensa all'organizzazione benefica Red Nose Day: ogni anno possono raccogliere donazioni per un periodo di 24 o 48 ore. Non c'è modo che possano ridimensionare la loro base di codice se pensassero che potrebbe impedire loro di fare donazioni in quel tempo. Inoltre, se c'è una finestra rotta, ma non influenzerà la loro capacità di prendere donazioni, allora è molto probabile che sceglieranno di non ridimensionare.
Troverai sempre un modo migliore di fare qualcosa. È un processo naturale ed è molto importante essere in grado di tracciare una linea.
In risposta alla tua domanda riguardante il refactoring, direi "sì". Come ha sottolineato qualcun altro nelle risposte di cui sopra, il refactoring è un processo in corso, e alcune volte ci sono decisioni tattiche e aziendali che superano la necessità di riscrivere il codice che sta già funzionando (anche se forse in modo klugey).
Riguardo a "finestre rotte": ho sentito questo termine per la prima volta nel contesto dello sviluppo del software, circa 10 anni fa. Ma a quel tempo, era usato per descrivere il permesso di test unitari . Stava descrivendo lo scenario in cui le persone hanno la tentazione di non correggere i test unitari rotti, perché sembra più opportuno ricordare solo quali test sono "okay to fail", invece di correggere i test non funzionanti (che sono stati validamente interrotti a causa dell'interfaccia o dei requisiti) modifiche, per esempio).
Penso che applicare la metafora della finestra rotta ai test unitari rotti sia più appropriato e più descrittivo del pericolo di consentire "finestre rotte" nel vicinato del software. A mio parere, se si parlasse di test unitari guasti (come finestre rotte), la risposta sarebbe: mai ok. (Nella misura in cui possiamo mai dire mai ...)
Se è veramente rotto, dovrebbe essere corretto.
Ma è davvero rotto? Sei sicuro di non stare equiparando "non bello" a rotto.
Devi applicare un calcolo del valore "affondato" prima di ridimensionare il codice di lavoro perché non ti piace lo stile, o, perché pensi che causerà problemi in futuro.
Per il codice di ri-factoring che hai scritto la settimana scorsa hai perso il costo è il tempo che hai speso per codificarlo la scorsa settimana, non vale davvero la pena di preoccuparti se il codice è sostanzialmente migliorato.
Codice di ri-factoring che è stato sottoposto a test unitario. Ora non hai solo bisogno di riscrivere, devi ridefinire e rieseguire tutti i test fatti finora, questo sta iniziando a sembrare costoso.
Codice di ri-factoring che è andato in produzione. Ancora più test da eseguire, oltre a un roll out per gli utenti e il rischio di fornire qualcosa che non funziona come la vecchia versione. Devi giustificarlo e chiarirlo con il grande capo prima di andare avanti.
Codice di re-factoring che è stato in produzione per un po 'e che è stato sottoposto a diverse versioni e correzioni di bug. A meno che tu non sappia che il software smetterà di funzionare, non ci andrai nemmeno!
È stata la mia esperienza che la scadenza è la cosa più importante per il business. Dipende davvero da chi utilizzerà la tua applicazione. Nel mio caso si trattava di software per sistemi operativi per telefoni cellulari ... le scadenze perse significavano obiettivi di vendita mancati e hit sui prezzi delle azioni.
Ci siamo imbattuti in molti momenti del WTF guardando al codice che abbiamo ereditato e chiaramente necessario cambiare. Tuttavia, poiché questo codice ha funzionato "quasi" (l'asincronicità è poco conosciuta) non c'era alcun incentivo per il management a consentire effettivamente il refactoring mentre c'erano impegni in sospeso da consegnare. Non è stato fino a quando un bug è stato visto "in the wild" che ci sarebbe stato permesso di cambiare qualcosa, anche se potessimo romperlo facilmente attraverso oscuri casi limite. Una volta ho rifattorizzato circa 10.000 righe di codice nel mio tempo e ho finito per doverlo buttare via. Il tempo necessario per i test e per altri la revisione ecc. Non poteva essere giustificato.
Leggi altre domande sui tag project-management refactoring maintenance