Come si determina se riscrivere o meno il codice mal progettato? [duplicare]

12

Sono in una piccola squadra a cui è stato consegnato un gioco Java 2D scritto a metà e mal scritto. Il nostro obiettivo è fare tutto il possibile per migliorarlo in circa 11 settimane. Sono abbastanza sicuro che il codice non sia gestibile e ho bisogno di decidere se dovrei lanciare l'idea di una riscrittura (vicino alla riscrittura, comunque).

Ad esempio, la classe Main, che è un'applet, ha la maggior parte della logica di gioco appena lanciata. Gli eventi di tastiera e mouse sono gestiti con enormi blocchi if / else, nessuno dei quali viene commentato (gli unici commenti sono le sezioni di codice che sono state commentate) e tutto il codice di disegno e animazione è in un unico enorme pezzo. Le immagini vengono caricate in una classe separata che passa solo attraverso ciascun file, ciascuno su una riga separata e legge l'immagine in una variabile immagine statica. Sembra tutto un pessimo design.

Abbiamo tempo fino alla fine del semestre, circa 11 settimane, per rendere il gioco migliore di adesso. È giocabile ma gravemente rotto nei punti. Al momento mi è stata assegnata una piccola funzionalità da implementare: un menu principale cliccabile anziché uno controllabile solo da tastiera. Da un lato so di essere capace di implementarlo ma dall'altro ho paura di provare ad aggiungere nuove funzionalità perché a) più cose aggiungiamo, più è probabile che il programma si interrompa a causa delle cattive scelte progettuali e b) più aggiungerò al casino che c'è già.

Ho preso il fine settimana per provare a duplicare la funzionalità di base del gioco con un design diverso (per vedere se poteva essere fatto abbastanza velocemente). Sono in grado di caricare e memorizzare gli sprite, creare entità di gioco e spostarli, e tenere traccia dello stato del gioco per determinare quale input da gestire sulla tastiera e cosa disegnare sullo schermo. Un caricatore di spritesheet è stato il prossimo sulla mia lista (ho scoperto che la grafica del gioco non è nei fogli sprite ma ognuno è in un file separato). Un amico fidato ha detto che potrebbe essere meglio mantenere il vecchio codice ma guardarlo è troppo fragile. Potremmo refactoring mentre andiamo, ma penso che sarebbe difficile anche.

Il nostro gruppo si incontrerà questo venerdì. Avevo pianificato di discutere l'idea di una revisione e di presentare ciò a cui stavo lavorando, ma ora non ne sono così sicuro. Mi sembra un gioco 2D in 2D abbastanza semplice che una volta creata una solida base che sarebbe molto più semplice aggiungere funzionalità, ma dovremmo ridisegnare il codice base abbastanza rapidamente, probabilmente tra due o quattro settimane o giù di lì . Mi piacerebbe pensare che possiamo farlo velocemente ma non ne sono completamente sicuro.

Immagino che potresti ridurre la mia domanda a questo: come determinare meglio quando mantenere un codice mal progettato e quando passare un po 'di tempo a partire quasi completamente da zero?

    
posta offbyone 02.02.2012 - 07:35
fonte

5 risposte

27

Rifatta il codice sorgente esistente. Lo so fa schifo ma se c'è una lezione che ho appreso in fase di sviluppo è che non si butta via un progetto di lavoro perché il codice è terribile.

Il tuo gioco funziona. Mantieni la strategia in questo modo.

  • Gli eventi della tastiera vengono gestiti in giganteschi blocchi? Inseriscilo in una classe e segrega le funzionalità in metodi. Potrai riutilizzare la maggior parte del codice che è già stato scritto .

  • Non ci sono commenti? Aggiungili mentre rifattori specifiche aree del codice base.

  • Il gioco non usa gli spritesheets? Non ha un manager? Concatena gli sprite esistenti in fogli e scrivi il manager in modo che si inserisca nella soluzione di caricamento dello sprite esistente.

  • Il disegno e l'animazione vengono tutti mescolati con la logica del gioco? Di nuovo, inizia a spostare questi blocchi nelle rispettive classi.

Ottieni il mio punto. Non c'è niente di peggio e più deprimente di dover districare una codificata base di codice, ma la vittoria è molto più dolce alla fine. Invece di spendere 5 settimane per riscrivere ciò che è già stato fatto, avrai 5 settimane in più per sputare e lucidare e aggiungere nuove funzionalità.

Siediti con il tuo team e scopri cosa deve ancora essere raggiunto con questo progetto in termini di funzionalità. Dopo aver ottenuto un elenco completo, puoi iniziare a fare dei refactoring deliberati che andranno a beneficio diretto del successo del tuo progetto.

    
risposta data 02.02.2012 - 08:00
fonte
7

La situazione che stai descrivendo è la stessa situazione che incontrerai ovunque nel settore in merito al cosiddetto codice legacy . Per avere un'idea del perché probabilmente non dovresti ricominciare da capo ti suggerisco di leggere questo bel articolo di Joel.

link

Inoltre, ti suggerisco di ottenere una copia del libro di Feathers "" Lavorare efficacemente con il codice legacy ", che descrive molte pratiche utili su come gestire la situazione.

    
risposta data 02.02.2012 - 08:03
fonte
4

Non scrivere da zero. Inevitabilmente, ci sarà una logica che ti mancherà nella riscrittura, e l'esercizio di ottenere profondità e sporco nel codice sarà utile. Trova strumenti di refactoring che possono aiutarti. So che è in Java, ma per esempio, Visual Studio ha strumenti di refactoring che ti permettono di estrarre le funzioni molto facilmente. Forse puoi provare Eclipse e i suoi strumenti, o trovare un plugin.

Inizia con l'estrazione di grandi blocchi che sembrano correlati dal punto di vista funzionale. È possibile identificare una logica che può essere suddivisa in classi. Trova le dipendenze e parametrizzale (ad esempio, deglobalizza le variabili). In definitiva, prova prima a stabilire una struttura migliore attorno al codice esistente.

Potresti non trovare un brillante esempio di perfezione OO, ma non è questo l'obiettivo. L'obiettivo è aggiungere manutenibilità al progetto in modo tale da poter aggiungere funzionalità senza generare un fusibile.

    
risposta data 02.02.2012 - 07:48
fonte
1

how do you best determine when to maintain poorly-designed code and when to spend some time starting almost completely from scratch?

Quando un cambiamento più semplice diventa un compito colossale * , allora è meglio iniziare a rifarlo. Ma non buttare mai via il tuo vecchio codice (leggi in le 10 cose di Joel che non dovresti mai fare .

* Ho pensato che il codice sia stato testato e senza bug. Se introduci nuovi bug, allora il tuo compito non è finito.

    
risposta data 02.02.2012 - 10:15
fonte
0

Suggerisci di eseguire un rilevatore di cloni sul codice. Questo ti permetterà di trovare dove viene trovato il codice duplicato che può essere estratto, e sarai in grado di formare utili distrazioni (ad esempio, gestire eventi del mouse, ecc.).

Il nostro strumento CloneDR troverà blocchi di codice che corrispondono ai parametri del modulo; essenzialmente propone subroutine (OK, questo è Java, sono chiamati metodi) che mostra il codice duplicato e come può essere parametrizzato.

    
risposta data 02.02.2012 - 12:04
fonte

Leggi altre domande sui tag