Scrivere buon codice è l'obiettivo di ogni sviluppatore. All'inizio imparando le basi ci abituiamo ad utilizzare qualsiasi tipo di codice, quindi non ci preoccupiamo troppo degli approcci giusti o migliori: vogliamo solo un codice che funzioni.
Quando iniziamo ad abituarci alla programmazione, "farlo funzionare" non basta più. Quindi ci chiediamo se quello che stiamo facendo è effettivamente il nostro meglio e, in caso contrario, come possiamo migliorare.
Se vuoi aumentare e migliorare te stesso, dovrai portare la tua programmazione al livello successivo. Questa guida ti aiuterà a capire cosa serve per scrivere un buon codice e la mentalità di cui hai bisogno per non guardare mai indietro.
Se non hai conseguito una laurea in informatica, probabilmente non hai mai sentito parlare di Big O. O-grande è una notazione matematica che consente di misurare la velocità e la dimensione della memoria di un algoritmo informatico quando ipoteticamente ci sono input infiniti.
È un'ottima misura per l'efficienza e il costo del codice, ma oltre a ciò, Big O non può misurare nient'altro. È uno strumento matematico utilizzato per misurare la complessità nel nostro codice; tuttavia, non pesa la variabile umana, i requisiti di sistema specifici o la nostra architettura del software.
Non sto suggerendo che dovresti trascurare Big O, ma dovresti prenderlo per quello che è - un approccio matematico che fa parte dei criteri di ciò che è il codice di qualità - e in nessun modo prenderlo come misura assoluta. Big O è un buon punto di partenza per misurare la qualità del tuo codice, ma non fermarti solo a questo.
La persistenza del codice è uno dei fattori più sottovalutati in ciò che rende il codice di qualità. In poche parole, è la misura di quanto del tuo codice vivrà attraverso tutte le fasi di generazione e mantenimento del codice di produzione, dall'idea della funzionalità al test finale e alla distribuzione, e attraverso il refactoring, il debug e l'implementazione di nuove funzionalità.
È una perdita di tempo e un enorme ostacolo quando del codice deve essere parzialmente o interamente riscritto perché nessuno sa cosa fa o come funziona o perché è più conveniente scriverlo da zero invece di provare a farlo funzionare. Quel pezzo di codice non è un codice di qualità e non è persistente attraverso i cambiamenti che si verificano nel tempo.
I sistemi possono cambiare, così come i requisiti e le tecnologie, ma un buon codice sopravviverà con poche o addirittura nessuna modifica.
Quindi la prossima volta che scrivi del codice, siediti e pensa "Come posso risolvere questo problema in un modo che deve essere codificato solo una volta?" Ovviamente la soluzione non sarà così semplice come potresti pensare.
Esistono numerosi plug-in, componenti aggiuntivi e standard di formattazione, ma molto probabilmente sarai costretto a utilizzare strumenti o standard specifici per un lavoro specifico. Ma non vederlo come un'ostacolo. Al contrario, le limitazioni ti costringeranno a imparare nuovi modelli di codifica e ad essere flessibile con le tue abilità.
Ecco alcune idee tecniche per migliorare la qualità del codice:
- Usa un linter.
- Aderire a uno standard di codifica.
- Commenta il tuo codice in modo appropriato.
- Usa nomi corretti (variabili, funzioni, ecc.).
- Non trascurare i test adeguati.
- Approfitta degli strumenti di revisione del codice automatizzati e degli strumenti di integrazione continua.
- Condividi il tuo codice e chiedi feedback (revisione del codice).
- Sii consapevole del quadro generale del progetto.
- Rimani aggiornato su aggiornamenti e nuove librerie.
- Leggi, completa e pulisci il codice.
Diventare pratico con il tuo codice può essere di grande aiuto, ma può anche farti tornare indietro se non sai come utilizzare correttamente i tuoi strumenti.
Pensa sempra di scrivere codice con l'idea esplicita che è per noi, non per il computer. Sì, il computer compilerà, collegherà, eseguirà e interagirà con il codice, ma al giorno d'oggi ci sono così tanti livelli di astrazione che il nostro codice traduce a malapena la sua esatta intenzione. Quindi è inutile "salvare" alcuni caratteri qui o utilizzare legature di caratteri perché verranno analizzati più velocemente.
Questa idea del "codice umano" ti permette di scrivere programmi nel modo più leggibile e facile da capire, pensando sempre al nostro futuro o ai colleghi che se ne occuperanno.
Ovviamente dovresti assicurarti di non diminuire le prestazioni (Big O) e altri fattori come gli standard di codifica, ma avere sempre nella tua testa che questo è un messaggio per un essere umano e non solo pezzi di codice per far funzionare qualcosa. Questo è un enorme cambio di approccio ottimale nella scrittura del codice.
Una delle grandi seccature nel cambiare lavoro è conoscere la nuova struttura del codice di un determinato progetto. Tuffarsi in quell'enorme pila di vecchi e nuovi pezzi di codice non commentato può essere snervante e far perdere tempo finche non si riece a capire la logica è il senso.
Quindi prima iniziare ad inserire delle parti del nuovo codice nel vecchio oppure iniziare un nuovo progetto, usa il buon senso su come approcciare le nuove implementazioni. Il tuo nuovo codice può essere fluido e veloce, elegante e comunicativo, ma se si trova nel file sbagliato, nell'ambito sbagliato o nel blocco sbagliato, sembrerà comunque fuori posto e complesso da tradurre. Il contesto e dove si inserisce il nuovo codice è importante. Ricorda che stai scrivendo codice per te e i tuoi colleghi: quindi dove e come insierisci le nuovi parti del codice potrebbero generare grande confusione o chiarimenti perspicaci.
Nelle basi del codice i modelli di progettazione significano molto. Se il tuo progetto punta molto sulla programmazione funzionale, non andare in giro a creare classi e metodi inutilmente. Scrivere un buon codice è dove l'istinto incontra la conoscenza. Ci vuole tempo per ottenere entrambi, ma la ricompensa è una vera forma d'arte.
Prima di ogni commit, prova a rispondere a queste domande:
- Il tuo sistema si rompe se apporti una brutta modifica a una parte del tuo codice?
- Il tuo codice può essere riutilizzato su un'altra parte del sistema?
- Il tuo codice può essere aggiornato o aggiornato facilmente nel tempo senza aggiungere bug?
- Il tuo codice è facile da capire logicamente?
- Il tuo codice è efficiente e di piccole dimensioni?
Se non puoi dare una risposta chiara e soddisfacente a nessuna di queste domande, significa che dovresti tornare indietro e riconsiderare il tuo codice. Fingere che un problema non esista non lo farà durare a lungo.
A volte è semplicemente meglio riscrivere tutto. La vecchia tecnologia, una cattiva base di codice con molti bug, nuovi requisiti che richiedono un'architettura completamente nuova e problemi di escalation sono diversi motivi per cui questa può essere un'opzione obbligata. Per qualsiasi motivo tu lo stia prendendo in considerazione, assicurati che sia la decisione giusta e che la prossima volta lo farai bene e creerai un codice che durerà a lungo.
Scrivere codice di qualità e di lunga durata non è solo possibile ma necessario. Molte volte, la scritta errata del codice, comporta trascorrere del tempo a capire come funziona invece di dedicarsi a scrivere nuove parte di codice.
Come ogni cosa nella vita, il buon codice riguarda l'equilibrio; non esiste una risposta valida per tutti. Dipende dal tuo sistema, dai tuoi input e dai risultati che vuoi ottenere. Ma devi sapere come inclinare la bilancia e confrontare, come tornare indietro e adattarti e come scrivere codice che non muore mai.
I grandi programmatori non nascono così; si impegnano molto e cercano sempre di migliorare nel tempo.
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
