Sono un programmatore alle prime armi e spesso quando lavoro sui miei progetti, ho sempre la sensazione che il design del mio codice non sia il migliore che possa essere, e odio questa sensazione. Finisco col passare il tempo a cercare le cose, ma poi sono sopraffatto facilmente con molti dettagli, come i modelli di progettazione tra cui scegliere e quando usare una classe astratta o un'interfaccia. Dovrei provare a imparare un po 'di tutto in una volta?
Alcuni suggerimenti:
Usa incapsulamento per gestire la complessità separando la funzionalità in blocchi di costruzione distinti. Dimostra che ogni blocco funziona (tramite unit test), e puoi usarlo senza preoccuparti dei suoi dettagli interni.
Scopri e studia modelli di software . I modelli software sono metodi provati e comprovati per l'esecuzione di alcune attività comuni e ben note.
Studia e comprendi le strutture dei dati. Scopri gli usi e le caratteristiche delle prestazioni appropriate per ogni tipo di struttura dei dati.
Conosci bene il linguaggio di programmazione, i suoi punti di forza e di debolezza e come utilizzare al meglio le sue funzionalità.
Non devi sapere tutto questo contemporaneamente, ma dovresti studiarlo tutto nel tempo.
Il mio consiglio è: smettila di preoccuparti.
L'esperienza è l'insegnante migliore e non hai esperienza se non scrivi codice. Inoltre, il codice mal progettato che è scritto è meglio di un ottimo design che è non .
Quindi, scrivi più codice. Finisci i tuoi progetti. La sensazione che il codice non sia ideale probabilmente ha ragione. E probabilmente avrai problemi con questo codice. E quando hai questi problemi, allora imparerai perché esattamente è stato male. Imparerai molto di più dall'esperienza diretta che da "cercare le cose".
Inoltre, non sperare che questa sensazione di "odore di codice" possa mai andare via. Mentre stai migliorando, risolvi alcuni problemi, ma inizia a notare nuovi, più oscuri / avanzati.
Questo è un problema comune con i programmatori principianti. Non paralizzarti pensando che tutto deve essere perfetto. Questo è il modo più sicuro per non finire mai un progetto. Una delle abilità più importanti da imparare come sviluppatore è la differenza tra perfect e abbastanza buono . Accetta che ogni sistema che crei possa essere migliorato. Concentrati sulla conclusione dei tuoi progetti. Dopo aver finito, puoi tornare indietro e migliorare su di loro. Ecco perché abbiamo la versione 2.0, dopo tutto.
Am I supposed to try and learn a little bit of everything at once?
Spero di no. D'altra parte, dovresti imparare e migliorare tutto il tempo.
Leggi libri, segui corsi, ottieni qualifiche, lavora e dovresti migliorare.
Il mio miglior consiglio è di concentrarsi sui fondamenti, come l'elenco suggerito da Robert Harvey. Lo sviluppo del software è un mostro complesso che impiega anni per arrivare anche a distanza, specialmente nel tema della buona progettazione dell'interfaccia. È davvero difficile apprezzare molti aspetti dello sviluppo del software senza prima averli sperimentati. Anche qualcosa di semplice come il codice di commento può essere sottovalutato. Dal primo giorno, ti viene insegnato a scrivere codice ben documentato. Devo ammettere che non è stato fino a quando non sono stato un po 'in un tentativo di comprensione del codice $$ che ho scritto mesi fa, prima di apprezzare veramente il valore di buoni commenti. Lo stesso si può dire per molti concetti di programmazione. Ad esempio, incapsulamento dei dati, moduli a basso accoppiamento e interfacce pulite e nitide.
La risorsa più preziosa che ho incontrato sono i miei collaboratori. Stai per scrivere male il codice. Accettalo. È quello che fai per assicurarti di scrivere un codice migliore nel tempo che ti definisce come programmatore. Ad esempio, quando ho iniziato a lavorare per la prima volta, la mia azienda non aveva alcun tipo di codice formale o procedure di revisione del progetto. Mi sono assunto il compito di sottoporre il mio lavoro alle critiche dei miei colleghi più anziani e ad essere onesti, mi sentivo un idiota per una parte migliore del mio primo anno di lavoro.
Lo sviluppo del software è un'esperienza di apprendimento in corso. Fai molte domande, leggi il tuo codice, comprendi il perché dei suggerimenti che le persone più anziane danno, non aver paura di mettere in discussione la validità dei suggerimenti che gli sviluppatori più anziani danno e soprattutto non aver paura di sbagliare. Alla fine il fattore intimation o senso di essere sopraffatti mode. Per la cronaca ... le curve di apprendimento fanno schifo.
Dai un'occhiata al libro Refactoring: migliorare il design del codice esistente , di Martin Fowler. La prima cosa che dovresti fare è ridefinire il tuo codice , al fine di migliorare la leggibilità del codice e ridurre la complessità per migliorarne la funzionalità.
Quando rettifichi il codice, stai già utilizzando Design Patterns , codice Encapsulating , ecc.
Questo è uno dei migliori libri che abbia mai letto su questo argomento. Fornisce molte utili ricette.
Una buona risorsa è The Pragmatic Programmer . Il capitolo su "Broken Windows" descrive dove ti vedi. La risposta breve e concisa è quella di risolvere i problemi.
Quando inizi a correggere il tuo design, aiuta a capire cosa non ti piace. È facile trovare risposte vaghe come "tutto va per il verso giusto" o "perché l'ho fatto lì?". Ma prenditi il tempo per vedere se ci sono schemi comuni che hai usato.
Una volta capito dove vuoi andare, fai piccoli passi facilmente reversibili per arrivarci (cioè questo è ciò che Refactoring riguarda). Ogni volta che si migliora il codice, considerare l'impatto sul resto del codice. Hai fatto le cose meglio o peggio? Questo almeno è il mio approccio per portare ordine nel caos.
Se hai già qualche esperienza in programmazione, perché non studi alcuni progetti open source con clean code ? Puoi esaminare THIS domanda da SO che ha alcuni link rilevanti.
Inoltre, è necessario conoscere gli schemi di progettazione: pensaci, l'idea di avere schemi è quella di risolvere problemi noti senza reinventare la ruota o scrivere codice buggato.
Infine, sembra che tu abbia bisogno di un po 'di programmazione funzionale per schiarirti le idee. Guarda Haskell o Ocaml per cominciare.
Se non sei un mostro pericoloso, dovresti trovare un cosiddetto amico , che può rivedere il tuo codice e viceversa. Inoltre, se fai delle cose, che saranno rivisitate, o semplicemente supervisionate da altri, è una buona pressione farlo in modo migliore.
E non dimenticare, la programmazione inizia prima nella codifica, rivisita sempre le tue idee, i tuoi piani. Se il tuo piano è brutto, è un atto gioioso buttarlo fuori: hai appena salvato la frustrazione di buttare fuori un mucchio di codice (e il tempo della sua creazione) basato su un piano sbagliato.
Il mio consiglio è di prendere sul serio tutti gli odori e provare a risolverlo. Ci sono molti buoni libri sull'argomento (codice pulito e GOOS sono i migliori IMHO). Ma più che i libri vanno alle conferenze per ascoltare e discutere con altre persone e sulle comunità online (mailing list, gruppi). Ancora meglio provare a unirti al tuo xxug locale (dotnetug, jug, xpug, ecc.) O trovarne uno.
Discutere con altri programmatori è l'unico modo che conosco per migliorare davvero (a meno che tu non sia abbastanza fortunato da lavorare insieme con altri programmatori dedicati).
Leggi altre domande sui tag code-quality