Quando è accettabile NON riparare le finestre rotte?

In riferimento alle finestre rotte , ci sono momenti in cui è meglio lasciare il refactoring per un'attività futura?

Ad esempio, se un progetto per aggiungere alcune nuove funzionalità a un sistema interno esistente è assegnato a un team che non ha lavorato con il sistema fino ad ora e che ha una breve sequenza temporale in cui lavorare - può mai essere giustificabile rinviare importanti rifattorizzazioni al codice esistente al fine di rispettare 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.

"Fallo funzionare, poi fallo funzionare meglio" .

Non ricordo dove ho letto quella citazione, ma questa è la chiave per applicare bene il refactoring, e lo considero non professionale per fare diversamente.

Il refactoring continuo è come pulire le perdite mentre cucini e pulire i tuoi piatti dopo aver mangiato. Il refactoring mirato è come trovare una cucina sporca, ma avere solo il tempo di lavare un bicchiere o due sporchi. Preferiresti vivere con una cucina costantemente sporca o preferiresti mantenere le cose pulite mentre vai avanti?

Fai in modo che il codice funzioni, quindi rifletti il ​​tuo codice per assicurarti di avere la migliore implementazione che puoi eventualmente usare. Se stai facendo qualcosa di familiare, è possibile che tu abbia implementato il codice migliore per la prima volta, tuttavia è necessario attendere qualche istante per ricontrollare il tuo lavoro per essere sicuri. Se sembra che tu possa migliorare il tuo codice, allora provi a refactoring per assicurarti che il tuo codice sia almeno snello e pulito come puoi farlo. Ciò significa che stai riducendo la quantità di debito tecnico che ti lasci alle spalle e rendi più semplice la lettura e il refactoring la prossima volta che il codice deve essere gestito. Questo è il valore fondamentale alla base del mantra TDD "Red-Green-Refactor", tranne per il fatto che in TDD si esegue il refactoring principalmente per rimuovere la duplicazione, vale la pena di rivedere anche altri elementi che potrebbero essere sottoposti a refactoring, come classi di grandi dimensioni, metodi lunghi,

Se ti trovi ad affrontare una riprogettazione importante, forse puoi rimandare per un po ', in particolare se stai scadendo molto nei tempi previsti. Ciò viene tuttavia fornito a condizione che la funzionalità del codice non venga compromessa e che l'implementazione continui a soddisfare i requisiti. Questo tipo di situazione dovrebbe essere un evento raro e puoi aiutare ad assicurarti che sia ancora più raro se stai continuamente refactoring mentre procedi. Ancora più importante, tuttavia, è che non puoi rischiare di lasciare i tuoi cambiamenti importanti per troppo tempo, altrimenti finirai per creare un carico di lavoro ancora più grande in seguito che potrebbe essere molto più costoso da riparare o potrebbe finire con un risultato ancora più costoso fallimento del progetto.

Ho l'impressione che molte persone tendano a confondere le definizioni di refactoring e reingegnerizzazione . I due termini descrivono strategie per gestire situazioni molto diverse. Se desideri riprogettare, ti impegni a fare un cambiamento drastico che cambierà il comportamento di un sistema. Ciò invaliderà alcuni test e richiederà anche nuovi test. Quando Refactor, stai assicurando che il tuo sistema continui a comportarsi esattamentelo stesso che ha fatto prima della modifica, tuttavia stai anche assicurando che il tuo codice avrà longevità e che sarà più facile da mantenere nel tempo. Non stai "sfruttando" il tuo codice per l'inferno, stai impegnando in uno standard professionale di codice pulito che ridurrà il rischio di fallimento e assicurerà che il tuo codice rimanga un piacere lavorare con, e di uno standard professionale .

Tornando all'analogia delle finestre rotte, se rompi la finestra dovresti ripararla immediatamente. Se non hai notato che una finestra è rotta, devi decidere il costo se lasci la finestra rotta. Ora, ripeti le due frasi precedenti, ma sostituisci Bug per window. Alla fine hai bisogno di una strategia diversa. Se hai creato un bug durante la codifica, lo risolvi immediatamente o vedi se le modifiche richiederanno uno sforzo di reingegnerizzazione e prendi una decisione commerciale su quando sarà meglio risolvere il problema. Quindi non si esegue il refactoring per risolvere un problema, si esegue il refactoring per assicurarsi che sia più facile trovare e risolvere i problemi. Non mi interessa quanto pensi sia fantastico il tuo codice, i sistemi complessi avranno sempre problemi che dovranno essere affrontati nel tempo. Questo è ciò che riguarda il debito tecnico e perché il refactoring deve essere un processo in corso quando si implementa il codice e non deve essere lasciato per un tempo arbitrario futuro.

Quindi, in breve, la risposta che in rari momenti può essere accettabile rinviare importanti modifiche al codice al fine di fissare una scadenza, tuttavia non dovrebbe essere considerata una pratica normale trattare il refactoring come un esercizio indipendente dal lavoro quotidiano di implementazione, e certamente mai usato come una scusa da parte di team che non hanno familiarità con la base di codice come opzione per evitare che la loro implementazione sia snella e pulita come possono eventualmente farcela in queste circostanze.

Alcuni sviluppatori affermano 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 l'olfatto è relativamente semplice. Se scopri che continui a tornare a quel tipo di attività invece di aggiungere nuove funzionalità per i tuoi utenti o rendere l'app più utilizzabile per loro (l'ottimizzazione significa che rendere più veloce l'app funziona qui, l'ottimizzazione significa rendere il codice più leggibile è diverso) allora forse stai riordinando troppo. Non perché mettere in ordine è un male, ma perché la società sta pagando per lo sviluppo al fine di ottenere qualcosa di sviluppato. Non vogliono una soluzione fragile, difficile da leggere, scarsamente progettata, per essere sicuri, ma non vogliono nemmeno una mezza soluzione lucida e bella.

Metti in ordine quando devi fare qualcosa di semplice "per iniziare" o quando stai aspettando che un'altra squadra ti dica se il tuo problema è in realtà colpa sua o quando stai aspettando una decisione. Ci saranno molte opportunità. Se hai la possibilità di spostare l'intera app in avanti, prendila, a meno che non inizi a sentire che l'intera cosa è diventata fragile. Probabilmente no. Avrai la possibilità di refactoring - non devi preoccuparti di questo.

Per tornare alla seconda metà della domanda, uno sprint per aggiungere funzionalità che affrontano una breve sequenza temporale, 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 dovevano davvero essere riparate". Adatta il refactoring alle lacune che si verificano in qualsiasi progetto. Non rifugiarti a mettere in ordine a spese del raggiungimento dell'obiettivo del progetto.

Dal punto di vista commerciale, il refactoring è un investimento speculativo: investire tempo e fatica (denaro) ora, nella speranza che risparmierà più tempo e fatica (denaro) in futuro.

Senza entrare nel dibattito su quanto lo sforzo di refactoring salverà nel futuro (questo dipende da troppe variabili per essere una discussione significativa qui), è chiaro che il tempo di refactoring è quando il "valore attuale netto" del costo lasciandolo supera il costo di fare ora.

È facile, tranne che non hai idea di quanto costerà il furture. È inoltre necessario tenere conto di tutte le normali idee di pianificazione finanziaria come ritorno sull'investimento, gestione del rischio (valore del marchio, responsabilità legale, rischio assicurabile vs rischio non assicurabile), costo opposto, ecc.

Nella maggior parte dei casi, decidere quando effettuare il refactoring è meglio lasciare alle persone che gestiscono l'attività. Nonostante ciò che molti poster di questo forum esprimono, i manager di solito sanno molto di più sulla gestione di un'azienda rispetto ai programmatori. Hanno in mente un quadro più ampio che include la massimizzazione del rendimento per l'azionista. È raro che la correzione di cose che non si rompano contribuisca a ciò, il codice non fa eccezione.

Modifica: ho letto un articolo interessante sui programmi di manutenzione su infrastrutture critiche. L'essenza è che il movimento è lontano dalla manutenzione ordinaria (refactor) per riparare quando necessario (correggere bug). La differenza principale è i livelli di monitoraggio - ad esempio una centrale nucleare controlla in modo molto dettagliato e corregge quando viene "rotta" ma ben prima del fallimento. Ciò che è stato riscontrato è che il fissaggio a uno schema di manutenzione non solo costa di più, ma è meno affidabile a causa di interruzioni causate dal programma di manutenzione. Un'idea simile è necessaria per il software, ovvero il refactoring dei bit che stanno per rompersi, che si può conoscere solo con la misurazione.

È accettabile quando il danno all'azienda, riparandoli, è maggiore rispetto al non ripararli.

Le situazioni in cui ciò si verifica potrebbero essere:

• dove una scadenza o un'opportunità commerciale potrebbero essere perse a causa del tempo necessario per la correzione
• dove un pezzo di codice è programmato (in modo genuino) per essere ritirato in una scala temporale molto breve, quindi non c'è quasi alcun vantaggio nel rifattorizzarlo.

E queste situazioni si verificano - le situazioni commerciali spesso escogitano scadenze artificiali che devono essere rispettate laddove è passata l'opportunità di negoziarle e requisiti che hanno una componente temporale - ad esempio un cambiamento nella legislazione o nelle norme fiscali che entrano in vigore di una data specifica - esistono.

Il trucco sta nell'identificare queste situazioni e nel valutarle correttamente. Il codice che dovrebbe essere ritirato rimarrà spesso in circolazione per anni. Potrebbe essere necessario rispettare le scadenze artificiali, ma spesso possono essere rispettate in diversi modi (ad esempio, il software può essere presentato, demo-ed e "lanciato" in una determinata data senza che la versione finale sia necessariamente terminata fino a dopo).

Quando ti viene presentato questo genere di cose, devi affrontarlo con una mente aperta, ma chiedi sempre: come appare? Le ipotesi coinvolte sono realistiche? Esiste un altro modo per raggiungere l'obiettivo senza spedire un codice scadente? In caso contrario, come posso utilizzare al meglio il tempo disponibile?

E se non ci sono alternative sempre bene, ma quando lo ripareremo?

Perché dovrebbe quasi, quasi, quasi sempre essere quando , non se .

Se i gestori decidono di voler accumulare debiti tecnici . Questa è una decisione giusta da prendere se, ad esempio, si desidera solo un prototipo iniziale ad alcuni clienti iniziali per ottenere un feedback iniziale.

Puoi pensarlo allo stesso modo di chiedere credito. È giusto 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 es. Per soddisfare le aspettative dei clienti attuali) o può essere un disastro se fatto in modo irresponsabile.

Tutto dipende dalle priorità e il management dovrebbe essere consapevole del fatto che sebbene la priorità numero uno sia far funzionare il "codice", implementare nuove funzionalità e soddisfare le aspettative del cliente, ogni volta che lasci finestre rotte stai rallentando quella priorità numero uno , più difficile e richiede maggiori investimenti di risorse. Inoltre, il 99% delle volte non è possibile smettere di sviluppare nuove funzionalità e concentrare ogni sforzo nel "fissare la base di codice".

In conclusione, sì, è accettabile lasciare le finestre rotte a volte, proprio come è accettabile chiedere un prestito ... ricorda solo che devi davvero, davvero pagare in futuro. E in futuro, il tempo per farlo molto probabilmente non sarà molto più grande del tempo che hai ora.

Normalmente, quando puoi, dovresti risolverlo, Ciò eviterà il tempo potenziale impiegato per la manutenzione. Tuttavia, alcune pratiche barbariche non agili tendono a lasciare lo status quo per tutto il tempo in cui funziona. Alcuni manager hanno paura degli "effetti imprevisti" del cambiamento.

La mia opinione è di lasciarlo solo se funziona come dovrebbe (rotto solo dall'ottimizzazione ma non dalla funzionalità) e non hai il tempo di provarlo, se fai del refactoring. Tuttavia, dovresti notare che dovrebbe essere riparato il prima possibile.

Se è rotto dalla funzionalità e le nuove funzionalità dipendono da esso, sarebbe meglio ripararlo anche al più presto.

La maggior parte dei programmatori si occupa di fare soldi per il proprio datore di lavoro. Quindi, quando dovrebbe avvenire il refactoring: quando fa soldi fermi. Il refactoring è il tempo speso non speso per altri progetti e il tempo risparmiato in futuro per questo progetto.

Se ne valga la pena, dipende principalmente dal tuo manager.

I programmatori dovrebbero far conoscere all'entità aziendale l'entità del debito tecnico, in modo da poter 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 vincerà molte decisioni tecniche.

Per mettere alcuni dei problemi in una prospettiva non tecnica, sottolinea il tempo esteso per correggere i bug e aggiungere nuove funzionalità. Se il management ha un background di vendite e marketing, potrebbe capirlo. Odiano dover dire ai clienti che queste cose richiederanno più tempo.

Se stai pensando di espandere la tua squadra, potrebbe essere un buon momento per assumere uno sviluppatore junior. La copertura del test sarà un grande salvatore in questo caso. Impareranno di più facendo che leggendo la documentazione.

può mai essere giustificabile rinviare importanti rifatturazioni al codice esistente al fine di fissare la scadenza in questo scenario?

• Se qualcosa è rotto, molto probabilmente no. Non guideresti una macchina con freni parzialmente funzionanti, vero? (A meno che il rischio di non arrivare da qualche parte in tempo sia maggiore del rischio di crash a causa di freni difettosi.) Lungi dall'essere la soluzione ideale, ma sfortunatamente succede.

Tuttavia, se stai parlando di ricodificare il codice di lavoro, considererei quanto segue:

• Se dipendesse dai nostri sviluppatori senior o dal direttore tecnico di quanto non avremmo mai rilasciato alcun software. Riflettiamo sempre e puntiamo al perfezionismo.

• Se il re-factoring avrà un impatto negativo sulla redditività del business, dovrebbe essere riprogrammato.

• Se la tua azienda ha promesso di fornire determinate funzionalità entro una determinata data, rifatterai in seguito. Pensa alla beneficenza del Red Nose Day: ogni anno possono raccogliere donazioni per un periodo di 24 o 48 ore. Non c'è modo che possano ricodificare la loro base di codice se pensassero che potrebbe impedire loro di fare donazioni in quel lasso di tempo. Inoltre, se c'è una finestra rotta, ma ciò non influirà sulla loro capacità di ricevere donazioni, allora è molto probabile che sceglieranno di non ricodificare.

• Troverai sempre un modo migliore per fare qualcosa. È un processo naturale ed è molto importante essere in grado di tracciare una linea.

In risposta alla tua domanda sul refactoring, direi "sì". Come qualcun altro ha sottolineato nelle risposte sopra, il refactoring è un processo in corso e alcune volte ci sono decisioni tattiche e commerciali che sostituiscono 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 rotti . Questo stava descrivendo lo scenario in cui le persone hanno la tentazione di non riparare i test unitari rotti, perché sembra più opportuno solo ricordare quali test sono "okay fallire", invece di riparare i test interrotti (che sono stati validamente rotti a causa di interfaccia o requisiti modifiche, ad 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. Secondo me, se stavi parlando di unit test rotti (come finestre rotte), la risposta sarebbe che non va mai bene. (Nella misura in cui potremo mai dire mai ...)

Se è veramente rotto, allora dovrebbe essere riparato.

Ma è davvero rotto? Sei sicuro di non solo equiparare "non bello" a rotto.

Devi applicare un calcolo del "valore sommerso" prima di ricodificare il codice di lavoro perché non ti piace lo stile o perché pensi che causerà problemi in futuro.

Per il codice di factoring che hai scritto la scorsa settimana, il costo sommerso è il tempo che hai impiegato per codificarlo la scorsa settimana, non vale la pena preoccuparti se il codice è sostanzialmente migliorato.

Codice di factoring che è stato sottoposto a unit test. Ora non devi solo riscrivere, devi ridefinire ed eseguire nuovamente tutti i test effettuati finora, questo inizia a sembrare costoso.

Codice di re-factoring che è andato in produzione. Ancora più test da fare, oltre a un roll-out per gli utenti e il rischio di fornire qualcosa che non funziona così come la vecchia versione. Devi giustificarlo e cancellarlo con il grande capo prima di andare avanti.

Codice di ri-factoring che è stato in produzione da un po 'di tempo ed è stato sottoposto a diverse versioni e correzioni di bug. A meno che tu non sappia che il software smetterà di funzionare, non andarci nemmeno!

È stata la mia esperienza che la scadenza è la cosa più importante per l'azienda. Dipende davvero da chi utilizzerà l'applicazione. Nel mio caso era per il software del sistema operativo del telefono cellulare ... scadenze mancate significavano obiettivi di vendita mancati e colpi di prezzo delle azioni.

Ci siamo imbattuti in molti momenti WTF quando abbiamo visto il codice che abbiamo ereditato e che era chiaramente necessario modificare. Tuttavia, poiché questo codice ha funzionato "quasi" (l'asincronicità è scarsamente compresa), non vi è stato alcun incentivo per il management a consentire effettivamente il refactoring mentre vi erano impegni da liquidare. Fu solo quando un insetto fu visto "allo stato brado" che ci sarebbe stato permesso di cambiare qualsiasi cosa, anche se avremmo potuto spezzarlo facilmente attraverso casi oscuri. Una volta ho refactored circa 10k righe di codice nel mio tempo e ho finito per doverlo buttare via. Il tempo necessario per i test e altre revisioni ecc. Non potrebbe essere giustificato.