Rifattore o concentrazione sul completamento dell'app

Rifatterai la tua app mentre procedi o ti concentri sul completamento dell'app prima? Il refactoring comporterà un rallentamento dei progressi dell'app dell'app.

Completare l'app significherà che potresti avere un'app molto difficile da mantenere in seguito?

L'app è un progetto personale. Non so davvero come rispondere a "Ciò che guida la funzionalità e il design", ma immagino che sia per risolvere le inefficienze del software attuale là fuori. Mi piace anche il software minimale facile da usare. Quindi sto rimuovendo alcune funzionalità e aggiungo alcune che ritengo possano aiutare.

Fallo funzionare. Quindi fallo veloce. Infine, rendilo bellissimo.

Se hai una buona separazione tra il tuo codice (presentazione, business e livelli dati) usando le interfacce e non è un progetto monolitico, il refactoring non dovrebbe essere così difficile.

Se stai riscontrando così tante difficoltà nel refactoring, è probabilmente un odore di codice - ti suggerisco di guardare Solid Principles

Penso che il punto essenziale sia mantenere pulite le interfacce . Puoi sempre refactoring o persino riscrivere modulo / classe / qualunque implementazione in seguito, purché i livelli di comunicazione tra loro siano sani. Passa un po 'di tempo a capire cosa è facile cambiare in seguito e cosa no. Rendi quest'ultimo giusto.

Ciò è coerente con lo spirito del TDD. Per scrivere buoni test, hai bisogno di una buona interfaccia per testare. Quanto è disordinato dietro le quinte in questo momento non è così importante, perché puoi migliorarlo in seguito.

Rifattengo sempre mentre vado, specialmente usando TDD.

1. Scrivi i test

2. Fai passare i test

3. Refactor

Questo ti aiuterà ad avere meno bug e un codice migliore per il prodotto finito. Ti permetterà anche di avere meno codice da conservare quando hai finito.

Refactor presto e spesso! Il tempo che "risparmi" nel non farlo viene speso molte volte nel tentativo di hackerare la funzione successiva e cercare bug in un codice eccessivamente complesso o caotico.

Il refactoring è come raccogliere la tua stanza.

Se mantieni le cose in ordine, hai un overhead lineare, proporzionale alla quantità di lavoro produttivo che stai facendo sul codice, O (n) in termini di algoritmo. Supponendo che tu spenda il 10% del tuo tempo di refactoring (o mantenendo la tua stanza in ordine), quel 10% è un dato, e rimarrà costante nel tempo.

Se, tuttavia, butti i vestiti sporchi in un angolo e continui a farlo, il tempo che passerai a raccogliere la tua stanza aumenta man mano che il disordine diventa più complesso. Supponendo che ogni singolo pezzo di biancheria sporca contribuisca in modo esponenziale al tempo di pulizia richiesto, ora ci si trova in una situazione O (e ⁿ ).

Chiunque abbia mai scavato nel concetto di complessità algoritmica osserverà che c'è un punto di pareggio da qualche parte, cioè c'è una quantità ottimale di biancheria sporca da accumulare; quanto dipende dai fattori costanti che vengono scartati nella notazione big-O. Un altro fattore è il valore del tuo lavoro nel tempo: se il tuo lavoro vale molto adesso, ma a buon mercato la prossima settimana (vale a dire, venerdì è prevista una scadenza per questo progetto e altri tre, ma dopo, sarai per lo più inattivo ), l'equazione potrebbe risultare a favore del non refactoring.

E poi c'è la massa critica della complessità. Ad un certo punto, il disordine ("pasticcio critico", se vuoi) diventa così grave che sembra più facile bruciare l'intera stanza e comprare nuovi vestiti. In realtà di solito non lo è, ma sembra così, e gli effetti psicologici renderanno dieci volte più difficile affrontare la cosa.

E ovviamente, se entri in un progetto che è già un gigantesco casino ridondante, hai una scelta limitata.

TL; DR: in caso di dubbio, refactor. Dovresti avere prove davvero valide prima di decidere di non farlo.

Se hai la possibilità di aggiungere funzionalità o schiacciare i bug per ottenere le tue vendite / soddisfazione del cliente dove pensi che dovrebbe essere, fallo. Una volta che ci sono meno nuove richieste, è possibile bilanciare con il refactoring. Ad un certo punto devi assicurarti di scrivere codice che la gente vuole. A parità di condizioni, preferirei buttare via 100 ore di codice rispetto a un 1000. Che è quello che farai se nessuno lo vuole.

Dipende davvero da dove ti trovi!

Altre cose a cui pensare:

Quanto sei sicuro, hai davvero il design funzionale giusto? Potresti finire di riprogettarlo di nuovo dopo aver ricevuto un feedback dagli utenti?

Preferirei rilasciare piuttosto che riscrivere. Ottimizza dopo essere sicuro di aver inchiodato il design funzionale.

Finché sei sicuro di poter rispettare la scadenza, puoi rifattorizzare tutto ciò che desideri. Tuttavia, anche se c'è un po 'di incertezza, è meglio attenersi allo sviluppo e può essere un fattore di riflessione solo in modesti passi incrementali.

Se il cattivo design che vuoi refactoring ti fa davvero male, è meglio risolverlo ora piuttosto che creare più codice che dipende da esso. Il refactoring in seguito sarebbe più difficile e più costoso; è probabile che non sarai più in grado di farlo.

D'altra parte, se il tuo unico problema è la bruttezza, potresti voler prima completare il tuo software, perché quasi nulla batte di fare le cose .

Il refactoring sarà molto importante mentre lavori al completamento della domanda.

+ VES

1. Flusso chiaro: il refactoring darà chiarezza al codice perché a volte se il codice è poco strutturato, capire il flusso del codice dopo un periodo di tempo potrebbe diventare difficile e il codice di refactoring potrebbe diventare un'attività in salita e i bug potrebbero essere introdotti.

2. Migliora le prestazioni: il refactoring corretto dell'applicazione contribuirà sicuramente a migliorare le prestazioni dell'applicazione.

3. Manutenzione: ultimo ma non meno importante, sarebbe più facile da mantenere a lungo termine.

-VE

1. Consumo di tempo: sarebbe molto più tempo in ogni fase dei tuoi progressi. Quindi potrebbe esserci un ritardo nel completamento.

Linea di fondo

A seconda del tipo di progetto, è possibile stabilire la priorità in base alla qualità del codice o al completamento, a seconda della situazione attuale.

In base alla mia esperienza personale, di solito andrei prima a finire le app con la condizione che ci sia una scadenza da raggiungere. una volta completato puoi rifattarlo.

Finiscilo e riformattalo. Ma se non ci sono scadenze per la fretta o il lasso di tempo, suggerisco che il refactoring sarebbe buono.