Refactor.

Non riesci quasi mai a farlo bene la prima volta. E anche se lo fai, i requisiti cambiano e ne arrivano di nuovi, quindi nel tempo è necessario estendere e modificare il codice in modi imprevisti. Quindi, ogni volta che noti che è difficile o difficile cambiare il codice nel modo desiderato, prima devi renderlo aperto per il cambiamento. Una lettura consigliata per questo è Refactoring to Patterns .

Un buon design raramente viene fuori dalla scatola, ma emerge attraverso una serie di trasformazioni e perfezionamenti nel corso della vita di un'app. Certo, più esperienza si ha, più è facile vedere i vicoli ciechi: decisioni che sembrano allettanti ora ma che costerebbero caro nel lungo periodo. La pratica rende il maestro.

È solo una questione di abilità artigianale e di avere il tempo a disposizione per dedicarsi al lavoro artigianale (nel caso in cui tu stia producendo il lavoro per un cliente pagante).

Che cosa comporta la lavorazione artigianale? A livello di base:

• Stile di scrittura pulito e coerente
• Documentazione adeguata
• (IMO) nomi descrittivi per metodi, variabili e classi

Ad un livello superiore si incontrano principi di progettazione comuni

• D.R.Y: link
• S.O.L.I.D: link

l'utilizzo di metodologie Test Driven Design può aiutare a mantenere i metodi puliti e mirati.

Una volta che inizi a creare classi ben progettate, inizi a pensare di creare applicazioni ben progettate - dove puoi iniziare a pensare a concetti come Design Patterns e Dependency Injection.

Dopo aver scartato alcune parole d'ordine, acronimi e collegamenti wiki, tuttavia, si tratta comunque di cose uguali a qualsiasi forma di artigianato:

Pazienza, perseveranza e attenzione ai dettagli.

Il tuo interesse per un pezzo di codice potrebbe ben rallentare prima che sia "finito", o potresti essere troppo impaziente di impegnarti in TDD o scrivere una documentazione adeguata.

Un Artigiano supererà questi ostacoli e si assicurerà che tutte le io siano punteggiate e incrociate.

in risposta al commento dell'OP:

Se lavori in un ambiente commerciale. potresti scoprire che non ti viene dato il tempo sufficiente per applicare la tua arte alla sua piena estensione. IME questa è una causa molto comune di codice di scarsa qualità: è difficile vendere test unitari e documentazione come ROI al cliente / MD.

Dipende da ciò che chiami la fine. Devi solo tornare indietro e aggiustarlo e applicare ciò che hai appreso ai progetti futuri, laddove applicabile. Il codice errato di solito sporge dopo che è stato scritto o lo sapevi prima del tempo, ma voleva solo far funzionare la cosa. Alla fine, puoi tenerne conto in fase di progettazione; assicurati di non sovrastimare la cosa.

Il codice errato è relativo. Possiamo tutti guardare una linea di codice e raccomandare di non farlo in questo modo, ma anche sottolineare la coerenza. Il modo migliore per rovinare una linea di codice perfetta è copiarlo e incollarlo dappertutto.

Potresti non tornare mai indietro e ottenere effettivamente progetti precedenti al livello di robustezza, flessibilità e chiarezza che desideri. C'è sempre il prossimo. Il software non è facile.

Robustezza : conosce in anticipo i requisiti del tuo progetto. Non è possibile anticipare ogni modifica al progetto, ma ogni informazione è meno lavoro che devi fare per rendere la tua soluzione adatta ai nuovi requisiti. Aiuta a chiarire a lungo termine.

Flessibilità - Scopri come pensare usando il modello Model-Controller-Interface. Quando costruisci il tuo progetto, definisci la struttura prima di procedere con i dettagli. Sarebbe come costruire la cornice della casa e le pareti prima di iniziare a stendere il tappeto. Ti permette di estenderlo o crescere facilmente secondo le tue esigenze. Un buon punto di partenza per iniziare a lavorare sui dettagli si trova nelle sezioni del progetto che non saranno modificate.

Chiarezza - Aggiungi commenti che spiegano il motivo per cui hai inserito il codice, non quello che fa. Se devi scegliere tra la scrittura di una logica terziaria stenografica e la scrittura di una dichiarazione completa se, scrivi la dichiarazione completa. Se devi chiedere perché, sappi che ti darò la caccia se eseguirò il debug del tuo codice un giorno e scoprirò che non l'hai fatto.

Una tecnica funziona per me: TDD.

• aiuta a ottenere un'interfaccia e un comportamento chiari in fretta
• fornisce una suite di test di regressione per il futuro refactoring
• è un ottimo aiuto per la comunicazione quando c'è bisogno di chiarimenti sui requisiti

Per la robustezza, avere l'attitudine che il resto del sistema è inaffidabile e fallirà tutte le possibilità che ottiene. Questo ti fa prendere l'abitudine di controllare sempre i codici di ritorno, sempre rilevando eccezioni, e sempre pensando a "come posso recuperare da questo?"

Per flessibilità, programmare sempre le interfacce e provare a delegare responsabilità. DI è utile, ma può diventare ingombrante su progetti di grandi dimensioni.

Per chiarezza, scrivi sempre il codice più semplice e diretto possibile. Salva le tecniche difficili per i luoghi in cui hai identificato un problema. Questo gioca anche in flessibilità. Ho partecipato a molti progetti in cui qualcuno (non sempre io ...;) impiega molto tempo a implementare una soluzione "elegante" che alla fine non funziona (a causa di una modifica delle specifiche o dei requisiti). Il risultato è che poi trascorri molto tempo ad adattare l'elegante soluzione ai nuovi requisiti, o semplicemente a scartarla e scrivere qualcosa di nuovo.