Cosa devo fare quando il mio codice ha un odore?

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 potrebbe essere, e odio questa sensazione. Finisco per passare il tempo a cercare le cose, ma poi sono facilmente sopraffatto da molti dettagli, come i modelli di design tra cui scegliere e quando utilizzare una classe astratta o un'interfaccia. Dovrei provare ad imparare un po 'di tutto in una volta?

Alcuni suggerimenti:

1. Utilizzare l' incapsulamento per gestire la complessità separando la funzionalità in blocchi predefiniti distinti. Dimostra che ogni blocco funziona (tramite unit test) e puoi usarlo senza preoccuparti dei suoi dettagli interni.

2. Impara e studia i modelli software . I modelli software sono metodi collaudati per eseguire determinate attività comuni e ben note.

3. Studiare e comprendere le strutture di dati. Scopri gli usi appropriati e le caratteristiche prestazionali per ciascun tipo di struttura dati.

4. Conosci bene il tuo linguaggio di programmazione, i suoi punti di forza e di debolezza e come utilizzare al meglio le sue funzionalità.

Non devi sapere tutto questo in una volta, ma dovresti studiarlo nel tempo.

Il mio consiglio è: smetti di preoccuparti.

L'esperienza è il miglior insegnante e non ottieni esperienza se non scrivi il codice. Inoltre, il codice mal progettato che è scritto è meglio del grande design che non lo è .

Quindi, scrivi altro codice. Termina i tuoi progetti. Quella sensazione che il codice non sia l'ideale è probabilmente giusta. E probabilmente avrai problemi con questo codice. E quando hai questi problemi, allora impareresti perché è stato esattamente male. Impareresti molto di più dall'esperienza diretta che dal "cercare le cose".

Inoltre, non sperare che questa sensazione di "odore di codice" possa mai scomparire. Man mano che stai migliorando, risolverai alcuni problemi, ma inizierai a notare quelli nuovi, più oscuri / avanzati.

Questo è un problema comune con i programmatori principianti. Non paralizzare te stesso 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 perfetto e abbastanza buono . Accetta che ogni sistema che crei può essere migliorato. Concentrati sul completamento dei tuoi progetti. Dopo aver finito, puoi tornare indietro e migliorare su di essi. Ecco perché abbiamo la versione 2.0, dopo tutto.

Dovrei provare ad imparare un po 'di tutto in una volta?

Spero di no. D'altra parte, dovresti imparare e migliorare tutto il tempo.

Leggi libri, segui corsi, diventa qualificato, lavora e dovresti migliorare.

Il mio miglior consiglio è quello di concentrarmi sui fondamenti come l'elenco suggerito da Robert Harvey. Lo sviluppo del software è un mostro complesso che impiega anni anche per diventare bravo a distanza, specialmente nell'argomento del buon design dell'interfaccia. È davvero difficile apprezzare molti aspetti dello sviluppo del software senza prima averli vissuti. Anche qualcosa di semplice come il codice di commento può essere sottovalutato. Dal primo giorno, ti viene insegnato a scrivere un codice ben documentato. Devo ammettere che non è stato fino a quando non sono stato davvero coinvolto in un $$ tentando di capire il codice che ho scritto mesi fa prima di apprezzare davvero il valore dei buoni commenti. Lo stesso si può dire per molti concetti di programmazione. Ad esempio, incapsulamento dei dati, moduli accoppiati bassi e interfacce pulite e nitide.

La risorsa più preziosa che ho incontrato sono i miei collaboratori. Stai per scrivere codice male. Accettalo e basta. È quello che fai per assicurarti di scrivere codice migliore nel tempo che ti definisce un programmatore. Ad esempio, quando ho iniziato a lavorare, la mia azienda non aveva alcun tipo di codice formale o procedure di revisione del progetto. Mi sono preso la responsabilità di sottoporre il mio lavoro alle critiche dei miei colleghi più anziani e ad essere sincero, mi sentivo un idiota per una parte migliore del mio primo anno di lavoro.

Lo sviluppo del software è un'esperienza di apprendimento continua. Poni tonnellate di domande, fai rivedere il tuo codice, capisci il perché dei suggerimenti che danno più persone senior, non aver paura di mettere in discussione la validità dei suggerimenti che più sviluppatori senior danno e soprattutto non aver paura di sbagliare. Alla fine il fattore intimidatorio o il senso di essere sopraffatti dalle mode. Per la cronaca ... le curve di apprendimento fanno schifo.

• Primo: refactoring (avrà ancora un odore ma sarà un po 'più organizzato)
• Secondo: vedi se puoi usare un po 'di Design Patter per far corrispondere i pezzi refactored alla tua logica.
• Terzo: quando le cose iniziano a sembrare migliori, ricorda il tempo che hai trascorso facendo il primo e il secondo passo. In questo modo quando scrivi alcune nuove funzionalità, ci penserai mentre lo fai e non come un altro processo.

Dai un'occhiata al libro Refactoring: Improveing ​​The Design Of Existing Code , di Martin Fowler. La prima cosa da fare è riformattare il codice , al fine di migliorare la leggibilità del codice e ridurre la complessità per migliorarne la manutenibilità.

Quando esegui il refactoring del codice, stai già utilizzando Pattern di progettazione , Codice incapsulante , ecc.

Questo è uno dei migliori libri che abbia mai letto su questo argomento. Fornisce molte ricette utili.

Una buona risorsa è The Pragmatic Programmer . Il capitolo "Windows rotto" 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 "va dappertutto" o "perché l'ho fatto lì?". Ma prenditi il ​​tempo per vedere se ci sono schemi comuni che hai usato.

• Un buon design riutilizzerà un piccolo numero di concetti in tutta la base di codice (l'ideale è un concetto, ma in pratica potresti averne bisogno di un altro paio)
• Un buon design renderà facile capire dove risolvere i problemi (principio DRY, principio SRP)
• Una buona progettazione avrà una buona segnalazione degli errori (relativa al punto sopra, ma chiamata come elemento separato perché è un aspetto spesso trascurato)

Una volta capito dove vuoi andare, fai piccoli passi facilmente reversibili per arrivarci (cioè questo è il Refactoring ). Ogni volta che si migliora il codice, considerare l'impatto sul resto del codice. Hai reso le cose migliori o peggiori? Questo almeno è il mio approccio per portare ordine nel caos.

Se hai già esperienza nella programmazione, perché non studi alcuni progetti open source con codice pulito ? È possibile esaminare QUESTA domanda da SO che ha alcuni collegamenti pertinenti.

Inoltre, i modelli di progettazione sono assolutamente da sapere: pensaci, l'idea di avere modelli è quella di risolvere i problemi noti senza reinventare la ruota o scrivere codice errato.

Infine, sembra che tu abbia bisogno di una dose di programmazione funzionale per schiarirti le idee. Guarda in Haskell o Ocaml per iniziare.

Se non sei un mostro pericoloso, dovresti trovare un cosiddetto amico , che può rivedere il tuo codice e viceversa. Inoltre, se stai facendo cose, che saranno rivisitate o semplicemente supervisionate da altri, è una buona pressione farlo nel modo migliore.

E non dimenticare, la programmazione inizia prima della codifica, rivisita sempre le tue idee, i tuoi piani. Se il tuo piano è cattivo, è un atto gioioso buttarlo fuori: hai appena salvato la frustrazione di buttare via un mucchio di codice (e il tempo della sua creazione) basato su un piano cattivo.

Il mio consiglio è di prendere sul serio ciascuno degli odori e provare a risolverlo. Ci sono molti buoni libri sull'argomento (Clean code e GOOS sono i migliori IMHO). Ma più dei 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 ad altri programmatori dedicati).