Dovrei, e se sì, come faccio a imparare a favorire la progettazione in anticipo con l'astrazione sulla rimozione retrospettiva della ripetizione? [duplicare]

Per qualche ragione, progettare in anticipo ci sembra al nostro cervello come dovrebbe essere più veloce, ma raramente lo è. È molto più facile calcolare la duplicazione da due funzioni concrete già presenti nell'editor piuttosto che tralasciare la duplicazione da due funzioni effimere che non sono state ancora scritte.

Il trucco è far serrare il tuo refactor. Se stai facendo un refactoring ogni pochi minuti, è praticamente impossibile distinguere il vero design anteriore. Su algoritmi davvero complessi, potrei passare un'ora o due senza una fase di refactoring. Stai sbagliando se dici mai al tuo capo qualcosa del tipo: "Funziona, ma ho bisogno di un altro paio di giorni per il refactoring".

Stai praticamente indicando te stesso il problema: "... è il tempo extra impiegato per refactoring alla fine in modo che scrivo" DRY "code"

Il punto di scrivere codice incrementale e codifica sotto test è quello di ottenere il cosiddetto ciclo 'red-green-refactor':

• Rosso: scrivi un test in errore che mostra una mancanza nel tuo codice
• Verde: scrivi il codice per eseguire il nuovo test, insieme agli altri test esistenti, passa
• Refactor: elimina gli odori del codice, la duplicazione, cose del genere. Durante questo, tieni i test in esecuzione e assicurati che passino

Mi sembra che tu stia facendo l'intera codifica e, solo quando hai finito, riesci a puntare il codice. Non farlo. Scrivi un pezzo ben definito del tuo codice, sottoponilo a test e inizia a rifarlo. I test che hai appena scritto ti aiuteranno e ti impediranno di rompere il codice durante il refactoring.

I find that when I design up-front, because there is no way to test the design, I often go way off tangent and as soon as I start writing the code the design gets discarded.

La differenza tra il tipo di progettazione up-front (a cascata) rispetto a quello incrementale è la quantità di requisiti a cui ci si avvicina. Per aiutarti a risolvere i tuoi problemi attuali, devi essere in grado di prendere un progetto (iniziare in piccolo) e costruirlo senza uscire dalla tangente. Una volta capito che il design presenta difetti, interrompi la codifica e ridisegna.

L'obiettivo non è quello di essere in grado di realizzare un design perfetto in anticipo né di essere in grado di codificare ciecamente un design imperfetto, ma di arrivare a una sorta di mezzo felice. L'estremo della tua pratica attuale sarebbe quello di creare un progetto globale, ma poi solo il codice del codice del cowboy del progetto. Quando il design non funziona, smetti di scrivere codice e fissa il design.

Alcuni dei refactoring e / o la condivisione del codice possono essere riconosciuti durante la creazione di quella seconda classe o anche più tardi. Man mano che migliorerai, non solo migliorerai la progettazione iniziale, ma anche il modo migliore per riconoscere quanto sia possibile o addirittura pratico il design in prima fila. Quando si lavora con una squadra e si presuppone che tutti siano d'accordo sul progetto attuale, ci saranno problemi se un programmatore si muove su una tangente. Non lasciare che sia tu. Fermare la squadra se necessario e riprogettare.