Rendere il tuo codice pulito e bello è un ottimo modo per rispettare le scadenze. Robert Martin ha colto nel segno con una delle sue concise affermazioni: "L'unica vera misura della qualità del codice è l'unità What-The-F**ks/Minute" .” "nell'originale). Lasciatemi spiegare cosa significa. Ogni volta che rivedo il codice, il mio cervello attraversa una delle tre emozioni:
“WTF?! Che diamine?!" (con disgusto) - Non è questo... va tutto malissimo....
“WTF?! Che diamine?!" (con ammirazione) - hmm, un ragazzo intelligente lo ha fatto!
“WTF?! Che diamine?!" (con irritazione) - una specie di confusione, di cosa stiamo parlando?!
Quindi cosa è fondamentale e cosa valutiamo esattamente quando vediamo del codice? Questo è tutto: la sua purezza e bellezza. La capacità di scrivere codice pulito e bello è un indicatore di uno sviluppatore altamente professionale. La formazione in questa abilità si basa su due componenti: conoscenza e lavoro. La conoscenza ti insegna modelli, principi, pratiche, euristiche. Ti servono per crescere professionalmente. Solo tu devi assorbire questa conoscenza come una spugna attraverso la pratica costante e il duro lavoro. In breve, scrivere codice pulito non è facile. Questo è un lavoro duro e scrupoloso e dovrai impegnarti sodo. Attraverso prove ed errori, migliorerai ripetendo gli stessi passaggi più e più volte finché non troverai la soluzione che desideri. Semplicemente non esiste un modo più semplice. Di seguito sono riportati alcuni suggerimenti per aiutarti a imparare a scrivere codice pulito.
Cosa c'è in un nome
Kendrick Lamar (artista hip-hop americano, ndr) una volta osservò accuratamente: "Se voglio raccontare la vera storia, devo iniziare dal mio nome". I nomi nello sviluppo di software sono ovunque. Diamo nomi a funzioni, classi, argomenti, pacchetti, programmi: tutto. Diamo nomi ai file sorgente, ai libri di consultazione e a tutto ciò che è connesso ad essi. Diamo nomi alle cose all'infinito e questo diventa una parte fondamentale del lavoro per creare un codice pulito. Il nome che dai a qualcosa dovrebbe riflettere l'intento. Trovare un buon nome non è facile, ci vuole tempo, ma si risparmia anche molto tempo quando si ha a che fare con il codice e la situazione si complica. Quindi fai attenzione a questo processo e non aver paura di cambiare nome in seguito se trovi qualcosa di più adatto. Tutti coloro che si occupano del tuo codice ti saranno molto grati.
Ricorda che il nome di qualsiasi variabile, classe, funzione deve rispondere a tre domande principali: perché esiste (variabile, funzione, ecc.), cosa fa e a cosa serve.
Ciò richiede non solo buone capacità descrittive, ma anche erudizione generale e una visione ampia. E nessuno può insegnartelo meglio di te stesso.
"Una funzione" - una cosa
Louis Henry Sullivan (architetto razionalista e modernista americano) una volta disse: “la funzione determina la forma ” . Lo ha detto dell'architettura delle case, ma questo non cambia l'essenza. Ogni sistema è costruito su un linguaggio specifico del dominio che i programmatori creano per descriverlo accuratamente. Le funzioni agiscono come verbi della lingua e le classi sono sostantivi. Molto spesso, le funzioni sono fondamentali nell'organizzazione di un linguaggio di programmazione e scriverle correttamente è l'essenza della creazione di un buon codice. Esistono solo due regole d'oro per scrivere funzioni di qualità:
Dovrebbero essere piccoli
Devono fare una cosa, un compito, e farlo bene
Cioè, la tua funzione dovrebbe essere piccola e non dovrebbe contenere strutture annidate. Pertanto, i livelli di rientro delle funzioni non dovrebbero essere più di uno o due. Questo approccio rende il codice molto più facile da leggere, comprendere e comprendere. Inoltre, dobbiamo essere sicuri che le espressioni all'interno della funzione siano allo stesso livello di astrazione. Mescolare i livelli di astrazione all'interno di una funzione crea sempre molta confusione e alla fine porta a un codice ingestibile. I migliori programmatori trattano le funzioni come storie da raccontare, piuttosto che semplici codici da scrivere. Usano gli strumenti del linguaggio di programmazione scelto per creare un blocco di codice ricco, espressivo e più pulito che può essenzialmente fungere da grande narratore.
"I commenti non compensano un codice errato"
Venus Williams, tennista americana e cinque volte campionessa di Wimbledon, ha colto nel segno quando ha detto: “Ognuno lascia i propri commenti. Ecco come appaiono le voci . " I commenti sono come un’arma a doppio taglio: un commento ben posizionato è una cosa molto utile. D'altra parte, niente ingombra lo spazio più dei commenti frivoli e inutili. Ma i commenti più dannosi sono quelli che diffondono disinformazione e menzogne. In breve, i commenti sono una sorta di male necessario. Non sempre, ma per la maggior parte. Perché? È semplice, più vecchio è il commento, più difficile è mantenerlo e la maggior parte dei programmatori, come sai, non sempre modifica i commenti insieme alle modifiche nel codice. Il codice si muove e si evolve. Parti di codice vengono spostate avanti e indietro, ma non ci sono commenti. E questo diventa un problema!
Ricorda: un codice pulito e chiaro con pochi commenti è molto meglio di un codice complesso e disordinato. Non sprecare le tue energie spiegando il caos che hai creato nei commenti. Meglio spendere quel tempo per ripulire quel pasticcio.
“La formattazione del codice è sempre una priorità”
Lo ha detto nientemeno che Robert C. Martin (Robert Cecil Martin), alias Uncle Bob, sviluppatore, autore di numerosi libri sullo sviluppo di software, consulente, coautore del manifesto Agile e così via. E aggiungeva: “La formattazione del codice è una forma di comunicazione. E la comunicazione è una priorità assoluta per qualsiasi sviluppatore professionista”. L'affermazione di cui sopra non deve essere sottovalutata, perché parla di una delle caratteristiche più importanti di un eccellente sviluppatore. Il codice formattato ti consente di guardare in profondità nella tua mente. Vogliamo impressionare le persone con la nostra pulizia, attenzione ai dettagli, capacità di organizzare ed esprimere chiaramente i nostri pensieri. Ma se, quando le persone guardano il codice, vedono una sorta di confusione, che ricorda una vinaigrette, senza inizio né fine, ciò vanifica i tuoi sforzi e abbassa la reputazione dello sviluppatore. Non dubitarne nemmeno! Sei molto lontano dalla verità se pensi che la cosa principale in questo business sia che "il codice funziona e basta". La funzionalità creata oggi verrà molto probabilmente modificata nella prossima versione, ma la leggibilità del codice non cambierà. Lo stile del codice e la sua buona leggibilità facilitano la conservazione del codice per lungo tempo, anche dopo che il codice originale è stato modificato in modo irriconoscibile.
Non dimenticare mai che in futuro ciò che molto probabilmente verrà ricordato non è il tuo codice in sé, ma il tuo stile e la tua coerenza. Pertanto, assicurati che il codice sia ben formattato e segua regole semplici e comprensibili a tutti i membri del team.
Per prima cosa crea un blocco "try-catch-finally".
Georges Canguilhem (storico della scienza, filosofo) ha giustamente osservato: “Commettere errori è naturale per una persona, ma insistere sugli errori viene dal diavolo ” . La risoluzione dei problemi è qualcosa che fanno tutti i programmatori. Nell'input potrebbero essere immessi dati non validi e i dispositivi potrebbero guastarsi. E come sviluppatori, dobbiamo assicurarci che il codice faccia quello che dovrebbe fare. Il problema non è solo la gestione degli errori, ma una gestione degli errori “pulita e facile da leggere”. Molti programmi si adattano alla gestione degli errori. Se lo fai, tutto precipita in un tale caos che lo scopo e la logica del codice principale vengono distrutti. Questo è sbagliato, non dovrebbe essere così. Il codice dovrebbe essere pulito e affidabile e la gestione degli errori dovrebbe essere integrata in modo fluido e naturale nel codice. Questo è un indicatore di un programmatore di alta classe. E uno dei modi per raggiungere questo obiettivo è attraverso un corretto annidamento e copertura di tutti gli errori nei blocchi try-catch. Questi blocchi definiscono l'ambito del codice. Quando esegui il codice nella porzione try di un blocco try-catch-finally, stai affermando che l'esecuzione può interrompersi in qualsiasi momento e poi riprendere in un catch. Pertanto, ti consigliamo di iniziare con try-catch-finally quando scrivi il codice. Ciò aiuterà a determinare cosa può aspettarsi l'utente dal codice, indipendentemente da cosa va storto con il codice durante il tentativo.
Ricorda sempre che ogni eccezione generata deve contenere un contesto sufficiente per determinare la posizione e l'origine dell'errore. I messaggi di errore creativi e informativi vengono ricordati molto tempo dopo la scrittura del codice, anche quando il programmatore è già impegnato con compiti completamente diversi.
Riassumiamo
Una frase insolita ci aiuterà a riassumere tutto quanto sopra. Questo è il senso del codice o “un senso del codice comune”, una sorta di equivalente programmatore del buon senso. Nelle parole di Robert Martin: “Scrivere codice pulito richiede l’uso sistematico di molte piccole tecniche, applicate come risultato di un meticoloso e alquanto doloroso senso di “pulizia”. Queste piccole tecniche vengono collettivamente chiamate code-sense . " Alcuni di noi hanno questo “senso del codice sonoro” fin dall’inizio, mentre altri devono svilupparlo attraverso la pratica persistente. Questo istinto aiuta non solo a riconoscere la differenza tra codice cattivo e buono, ma aiuta anche nella formazione di strategie volte a trasformare il codice cattivo in buono. Il cattivo codice rovina tutto. Parlando in senso figurato, se glassi la torta più deliziosa con la merda di cane, allora... uh... difficilmente piacerà a nessuno. Il senso del codice aiuta un programmatore a utilizzare gli strumenti giusti per raggiungere il suo obiettivo di creare codice pulito. Un programmatore che capisce cos'è il senso del codice è un artista che può creare un'opera d'arte su uno schermo vuoto che sarà ricordata per molti anni. Come ha riassunto Harold “Hal” Abelson, professore di informatica al Mit e direttore fondatore di Creative Commons e della Free Software Foundation: “I programmi devono essere scritti prima in modo che le persone possano leggerli, e poi in modo che possano essere giustiziato." macchina" . Cosa puoi leggere sull'argomento: “Un manuale di Agile Software Craftsmanship” - Robert Martin. "Un manuale di stima Agile" - Mike Cohn Informazioni sull'autore: Ravi Shankar Rajan è un Global IT Program Manager di Mumbai (India). Famoso blogger, poeta haiku, appassionato di archeologia e appassionato di storia. Puoi connetterti con lui su Twitter , Medium , LinkedIn
GO TO FULL VERSION