Come "tracciare"?

Ci sono un certo numero di cose che ti aiuteranno, ma non c'è un proiettile d'argento che renda semplice la rielaborazione del tuo progetto. In nessun ordine particolare:

• Usa controllo versione. dovresti essere in grado di tornare a qualsiasi revisione del tuo progetto in qualsiasi momento. Se determini di aver commesso un grosso errore di progettazione due settimane fa e desideri poterlo riprendere, il controllo della versione ti consente di tornare indietro.

• Evita le dipendenze. Se correggere il tuo progetto è più difficile che ricominciare da zero, è molto probabile che le varie parti del tuo programma siano troppo interdipendenti. Esistono molti schemi e strategie per rendere il codice più modulare e ridurre le dipendenze tra i moduli. Passa un po 'di tempo a studiare il buon design orientato agli oggetti (supponendo che tu stia lavorando in stile OO). Isolare diverse funzionalità in moduli separati significa che i problemi dovrebbero essere meglio limitati a specifici moduli, e migliorare il tuo progetto significa rielaborare un modulo o due invece di riscrivere l'intero progetto.

• Risolvi comunque il tuo codice. La risoluzione del tuo codice potrebbe sembrare un lavoro più che ricominciare da capo, ma probabilmente imparerai molto di più correggendo i tuoi errori. È difficile capire davvero i problemi fino a quando non è necessario correggerli. Ricominciare può portare a commettere gli stessi vecchi errori e dover ricominciare da capo qualche volta in futuro.

• Rivedi in anticipo, ripassa spesso. Se non noti problemi fino a quando non si rompono così tanto da dover abbandonare il progetto, non stai guardando il tuo codice abbastanza difficile , abbastanza presto, o abbastanza spesso.

• Chiedi aiuto. Dici che la tua mancanza di esperienza porta a decisioni sbagliate. Trova alcuni amici o colleghi intelligenti e con esperienza che possono aiutarti a prendere decisioni sul design in primo luogo e rivedere sia il tuo design che il tuo codice lungo la strada. Spiegare il tuo lavoro ad altre persone può aiutare anche se i tuoi aiutanti non sono davvero così intelligenti o esperti. Altri punti di vista sono spesso utili e l'atto di spiegare se stesso ti aiuta a vedere il tuo lavoro attraverso gli occhi di qualcun altro.

Mi sembra di identificare due problemi comuni:

• Requisiti di spostamento
• Design del database errato.

Ciò che mi sembra strano è che hai problemi di prestazioni approfonditi che implicano riscritture di grandi dimensioni, ovvero estremamente inusuali. Se non si esegue il profiling, quando si riscontra un problema di prestazioni è normale provare a risolvere i problemi di prestazioni ciecamente, il che è improbabile che funzioni e molto, molto frustrante (la sensazione che si prova è che hai riscritto tutto, ma le cose sono ancora lento - questo normalmente significa che non hai riscritto la parte importante ). Se impari ad usare un profiler, troverai facilmente i veri problemi di prestazioni nel tuo codice e probabilmente li risolverai facilmente.

Ora, una volta risolto, risolviamo il problema.

I requisiti di cambiamento sono spesso inevitabili e spesso molto costosi. La progettazione del modello di database è fondamentale.

Che cosa puoi fare:

• Impara e pratica la modellazione del database. Imparare dai propri errori. Leggi alcuni libri. Uno che consiglierei che potrebbe funzionare per te è Il Resource Book del modello di dati , che contiene i modelli di database tipici per le applicazioni aziendali . Non è un sostituto della teoria dei modelli, ma sarà utile
• Dedicare più tempo alla raccolta dei requisiti. Raramente i clienti possono descrivere il loro modello di dati in dettaglio da soli - è necessario aiutarli- Gli esempi tratti dal libro che ho menzionato in precedenza potrebbero tornare utili.
• Mantieni il tuo database il più possibile normalizzato. I progetti di database normalizzati sono "più semplici" - sebbene possano comportare tabelle aggiuntive, tendono ad essere molto più facili da refactoring
• Utilizza il principio di responsabilità singola, DRY ... e altri, meno importanti principi di progettazione del software :) Ti guiderà verso un codice più piccolo, più facile da refactoring.