10 pratiche di programmazione che i nuovi sviluppatori dovrebbero adottare
Di seguito vi è un elenco di consigli per i neolaureati in informatica con pratiche e concetti che potrebbero risultare utili a tutti coloro che sono interessati a imparare le best practices del momento e migliorare la loro efficienza come sviluppatori.
DRY — Do not Repeat Yourself
Questo principio è uno dei più basilari che un programmatore dovrebbe conoscere e di cui deve tenere sempre conto.
Se stai scrivendo un codice che sai di aver scritto prima, dovresti fermarti e pensare. Pensa a come riutilizzare il codice che hai già scritto. Questo potrebbe sembrare un po’ difficile all’inizio, ma quando stai riesaminando o ridisegnando il tuo codice sarà facile.
Buoni nomi delle variabili/funzioni
Scrivere un buon nome di una variabile o soprattutto un nome di una funzione è un’arte che si padroneggia nel tempo. Ogni volta che pensi che il nome non sia giusto, dedicaci del tempo per trovare un nome fantastico, evitando di nominare causalmente le variabili e le funzioni o dando a loro nomi troppo lunghi.
Codice leggibile e commenti significativi
Dato che i commenti facilitano la lettura e la comprensione del codice, si consiglia spesso di scriverne molti. È preferibile scrivere codici facili da leggere e da capire, accompagnandoli da commenti per le parti più complesse del codice.
La maggior parte delle funzioni e dei metodi semplici generalmente non necessitano di commenti se il codice è scritto bene.
Segui le convenzioni e le linee guida
I linguaggi di programmazione hanno le loro convenzioni in termini di come scrivere codici e per un nuovo programmatore può risultare difficile capire inizialmente il significato di convenzioni e linee guida.
Un principiante, infatti, dovrebbe seguire le linee guida, leggere il codice scritto dai più esperti e adattarsi a quello.
Ristruttura il tuo codice quando impari un modo migliore per riscriverlo
Il codice non è per sempre e dunque ogni volta che ti rendi conto che il codice che hai scritto può essere migliorato o richiede una ristrutturazione, non esitare a riscrivere/ristrutturare.
Alcune volte è necessario riscrivere/ristrutturare a causa di un requisito o per motivi di ridimensionamento. Sebbene ci siano anche altri scenari, potresti prevedere problemi o potresti voler renderlo più robusto per il futuro.
La funzione/classe dovrebbe fare una cosa sola e dovrebbe essere breve
Molti sviluppatori alle prime armi scrivono funzioni lunghe che fanno più di una cosa, mentre molti team hanno una linea guida che limita il numero di linee che una funzione può avere.
La regola empirica è “Una funzione/Classe dovrebbe fare una cosa sola e farla bene”.
Open-closed principle
Il principio aperto-chiuso delle regole SOLID afferma: “I componenti software dovrebbero essere aperti per l’estensione e chiusi per la modifica.”
Ciò significa che qualsiasi componente del software dovrebbe essere estendibile senza apportare modifiche al codice del componente stesso. Sebbene questa regola si applichi a qualsiasi componente del software, è uno degli aspetti più importanti dello sviluppo di librerie usate nel codice o se desideri renderle open-source.
Ogni volta che devi fare un’estensione di un componente, non devi cambiare il codice e ciò consente di risparmiare lo sforzo di testare e distribuire il componente.
Modelli di progettazione
L’apprendimento dei modelli di progettazione può darti una nuova prospettiva sul problema o un modo rapido per adattare una soluzione alle tue esigenze.
Impara i framework
La maggior parte dei neofiti conosce uno o due linguaggi di programmazione. In realtà, la maggior parte dei linguaggi ha più framework che costringono lo sviluppatore a scrivere il codice secondo le convenzioni dei linguaggi e portano coerenza al modo in cui gli sviluppatori scrivono il codice.
Capire il business
Spesso gli sviluppatori sono così immersi nel problema in questione che prestano attenzione solo all’aspetto tecnico delle cose, trascurando il lato commerciale; comprendere anche il lato commerciale può portare una nuova prospettiva di guardare al problema.