10 Principi di programmazione di base Ogni programmatore deve seguire

Chiunque può scrivere codice Ma buon codice? Ecco dove diventa difficile.

Tutti abbiamo ascoltato storie dell'orrore sul codice spaghetti, enormi catene if-else, interi programmi che possono essere interrotti semplicemente cambiando una variabile, funzioni che sembrano essere state offuscate e così via. Questo è quello che succede quando provi a realizzare un prodotto che può essere spedito con solo un semestre di esperienza di programmazione sotto la cintura.

Non accontentarti di scrivere questo codice lavori. Cerca di scrivere codice che possa essere mantenuto - non solo da te stesso, ma da chiunque altro possa finire a lavorare sul software in futuro. A tal fine, ecco alcuni principi per aiutarti a ripulire il tuo atto.

1. BACIO

Il “mantienilo semplice, stupido” principio si applica praticamente a tutta la vita, ma è particolarmente necessario nei progetti di programmazione medio-grandi.

Inizia all'inizio quando definisci l'ambito di ciò che desideri creare. Solo perché sei appassionato dello sviluppo del gioco non significa che puoi creare il prossimo World of Warcraft o Grand Theft Auto. Quando ritieni di aver semplificato abbastanza, semplifica ulteriormente il livello - la funzionalità di scorrimento è inevitabile, quindi inizia in piccolo.

Ma anche dopo che la codifica è iniziata, mantienila semplice. Il codice complesso richiede più tempo per progettare e scrivere, è più soggetto a errori ed errori ed è più difficile da modificare in seguito. Nelle parole sagge di Antoine de Saint-Exupery, “La perfezione si ottiene, non quando non c'è altro da aggiungere, ma quando non c'è più nulla da togliere.”

2. ASCIUTTO

Il “non ripeterti” principio è cruciale per un codice pulito e facile da modificare. Quando si scrive codice, si desidera evitare la duplicazione dei dati e la duplicazione della logica. Se noti lo stesso pezzo di codice che viene scritto più e più volte, stai infrangendo questo principio.

L'opposto del codice DRY è il codice WET: “scrivi tutto due volte” (o “sprecare il tempo di tutti”). Uno dei modi migliori per diagnosticare il codice WET è chiedersi: per modificare in qualche modo il comportamento del programma, quante aree di codice dovresti modificare?

Supponiamo che tu stia scrivendo un'app di directory podcast. Nella pagina di ricerca, hai il codice per recuperare i dettagli di un podcast. Nella pagina del podcast, hai il codice per recuperare i dettagli del podcast. Nella pagina dei preferiti, lo stesso codice di recupero. Considerare l'astrazione di tutto ciò in una funzione in modo che se è necessario modificarlo in seguito, è possibile eseguire tutto in un unico punto.

3. Aperto / Chiuso

Sia che tu stia scrivendo oggetti Che cos'è la programmazione orientata agli oggetti? Le nozioni di base spiegate nei termini di Layman Che cos'è la programmazione orientata agli oggetti? Le nozioni di base spiegate nei termini di Layman I linguaggi di programmazione più moderni supportano il paradigma "programmazione orientata agli oggetti" (OOP). Ma cos'è esattamente OOP e perché è così utile? Leggi di più in Java o nei moduli in Python, dovresti mirare a creare il tuo codice aperto all'estensione ma chiuso alla modifica. Questo vale per tutti i tipi di progetti, ma è particolarmente importante quando si rilascia una libreria o un framework che gli altri possono utilizzare.

Ad esempio, supponiamo di mantenere un framework GUI. Potresti rilasciarlo così com'è, aspettandoti che gli utenti finali possano modificare e integrare direttamente il tuo codice rilasciato. Ma cosa succede quando rilasci un aggiornamento importante quattro mesi dopo? Come implementano tutte le tue aggiunte senza buttare via tutto il lavoro che hanno fatto?

Invece, rilascia il codice impedisce modifica diretta e incoraggia estensione. Questo separa il comportamento di base dal comportamento modificato. I benefici? Maggiore stabilità (gli utenti non possono rompere accidentalmente il comportamento di base) e maggiore manutenibilità (gli utenti si preoccupano solo del codice esteso). Il principio open / closed è la chiave per fare una buona API Quali sono le API e come le API aperte cambiano Internet Quali sono le API e come sono le API aperte Modifica di Internet Ti sei mai chiesto come i programmi sul tuo computer e sui siti web che visiti "parlare" l'un l'altro? Leggi di più .

4. Composizione> Ereditarietà

Il “composizione sull'eredità” principio afferma che gli oggetti con comportamenti complessi dovrebbero farlo contenendo istanze di oggetti con comportamenti individuali invece di ereditare una classe e aggiungere nuovi comportamenti.

L'eccessiva dipendenza dall'ereditarietà può portare a due problemi principali. Innanzitutto, la gerarchia dell'ereditarietà può diventare caotica in un batter d'occhio. In secondo luogo, si ha una minore flessibilità per la definizione dei comportamenti del caso speciale, in particolare quando si desidera implementare il comportamento da un ramo di ereditarietà in un altro ramo di ereditarietà:

La composizione è molto più pulita da scrivere, più facile da mantenere e consente una flessibilità quasi infinita per quanto riguarda i tipi di comportamenti che è possibile definire. Ogni singolo comportamento è di classe e crea comportamenti complessi combinando comportamenti individuali.

5. Singola responsabilità

Il principio di responsabilità unica dice che ogni classe o modulo in un programma dovrebbe preoccuparsi solo di fornire un po 'di funzionalità specifica. Come dice Robert C. Martin, “Una classe dovrebbe avere solo una ragione per cambiare.”

Classi e moduli spesso iniziano in questo modo, ma quando aggiungi funzionalità e nuovi comportamenti, è facile per loro evolvere in classi di Dio e moduli di Dio che occupano centinaia, o anche migliaia, di linee di codice. A questo punto, dovresti suddividerli in classi e moduli più piccoli.

6. Separazione delle preoccupazioni

Il principio della separazione delle preoccupazioni è come il principio della responsabilità unica ma a un livello più astratto. In sostanza, un programma dovrebbe essere progettato in modo che abbia molti diversi incapsulamenti non sovrapposti, e questi incapsulamenti non dovrebbero conoscere l'uno dell'altro.

Un esempio ben noto di questo è il paradigma model-view-controller (MVC), che separa un programma in tre aree distinte: i dati (“modello”), la logica (“controllore”) e cosa vede l'utente finale (“vista”). Le variazioni di MVC sono comuni nei framework web più popolari di oggi.

Ad esempio, il codice che gestisce il caricamento e il salvataggio dei dati in un database non ha bisogno di sapere come eseguire il rendering di tali dati sul web. Il codice di rendering può ricevere input dall'utente finale, ma poi passa quell'input al codice logico per l'elaborazione. Ogni parte si gestisce da sola.

Ciò si traduce in un codice modulare, che semplifica notevolmente la manutenzione. E in futuro, se hai mai bisogno di riscrivere tutto il codice di rendering, puoi farlo senza preoccuparti di come i dati vengono salvati o la logica viene elaborata.

7. YAGNI

Il “non ne avrai bisogno” principio è l'idea che non dovresti mai codificare per funzionalità che tu potrebbe bisogno in futuro. Le probabilità sono te non lo farà ne ha bisogno e sarà una perdita di tempo - e non solo, ma aumenterà inutilmente la complessità del tuo codice.

Si potrebbe vedere questo come un'applicazione specifica del principio KISS e una risposta a coloro che prendono troppo sul serio il principio di ASCIUTTO. Spesso i programmatori inesperti cercano di scrivere il codice più astratto e generico possibile per evitare il codice WET, ma troppa astrazione finisce in un codice gonfiabile impossibile da gestire.

Il trucco consiste nell'applicare il principio DRY solo quando è necessario. Se noti pezzi di codice che vengono scritti più e più volte, quindi li astragga, ma mai quando tu pensare un pezzo di codice sarà scritto più e più volte. Più volte che no, non lo sarà.

8. Evita l'ottimizzazione prematura

Il nessun principio di ottimizzazione prematura è simile al principio YAGNI. La differenza è che YAGNI affronta la tendenza a implementare comportamenti prima che siano necessari mentre questo principio affronta la tendenza a accelerare gli algoritmi prima che sia necessario.

Il problema con l'ottimizzazione prematura è che non si può mai veramente sapere dove saranno i colli di bottiglia di un programma fino a dopo il fatto. Puoi indovinare, ovviamente, ea volte potresti persino avere ragione. Ma il più delle volte, perderai tempo prezioso cercando di accelerare una funzione che non sia così lenta come pensi o non venga chiamata tutte le volte che ti aspetti.

Raggiungi le tue pietre miliari il più semplicemente possibile, allora profila il tuo codice per identificare i veri colli di bottiglia.

9. Refactor, Refactor, Refactor

Una delle verità più difficili da accettare come programmatore inesperto è quella il codice raramente esce giusto la prima volta. Esso può sentire proprio quando implementate questa nuova brillante funzionalità, ma man mano che il vostro programma cresce in complessità, le funzionalità future potrebbero essere ostacolate da come avete scritto quella in anticipo.

I Codebase sono in continua evoluzione. È del tutto normale rivisitare, riscrivere o persino riprogettare interi pezzi di codice, e non solo normale, ma salutare farlo. Conosci meglio le esigenze del tuo progetto adesso di quando hai fatto al inizio, e dovresti regolarmente usare questa conoscenza appena acquisita per rifattorizzare il vecchio codice.

Si noti che non deve sempre essere un grande processo. Prendi una pagina dai Boy Scouts of America, che vivono con queste parole: “Lascia il campeggio più pulito di quanto tu non abbia trovato.” Se è necessario controllare o modificare il vecchio codice, pulirlo sempre e lasciarlo in uno stato migliore.

10. Pulisci codice> Codice intelligente

A proposito di codice pulito, lascia il tuo ego alla porta e dimentica di scrivere codice intelligente. Sai di cosa sto parlando: il tipo di codice che sembra più un enigma che una soluzione ed esiste solo per mostrare quanto sei intelligente. La verità è che a nessuno importa davvero.

Un esempio di codice intelligente sta mettendo la logica in una riga il più possibile. Un altro esempio è quello di sfruttare le complessità di una lingua per scrivere affermazioni strane ma funzionali. Tutto ciò che potrebbe far dire a qualcuno “Aspetta cosa?” quando analizzi il tuo codice.

I buoni programmatori e il codice leggibile vanno di pari passo. Invia commenti quando necessario. Aderire alle guide di stile, sia dettate da un linguaggio (come Python) o un'azienda (come Google). Osserva gli idiomi per lingua e smetti di scrivere codice Java in Python o viceversa. Leggi il nostro articolo sui consigli per la scrittura di codice più pulito 10 Suggerimenti per scrivere Cleaner & Better Codice 10 Suggerimenti per scrivere Cleaner e Better Code Scrittura di codice pulito sembra più facile di quanto non sia in realtà, ma ne valgono i benefici. Ecco come iniziare a scrivere codice più pulito oggi. Leggi di più .

Ciò che rende un buon programmatore?

Chiedi a cinque persone e otterrai 10 risposte diverse. Per me, un buon programmatore è colui che comprende che la codifica dovrebbe in ultima analisi servire l'utente finale, che è facile lavorare con un team, e che finisce i suoi progetti secondo le specifiche e in tempo.

Se sei appena agli inizi, non preoccuparti troppo di questo ancora. Concentrati sull'imparare a codificare senza stress. Se ti senti bloccato, consulta il nostro articolo sul superamento del blocco del programmatore. E se non sei felice di scrivere il codice, leggi il nostro articolo sui segni che non sei destinato a essere un programmatore 6 Segni che non sei destinato a essere un programmatore 6 Segni che non sei destinato a essere un programmatore Non tutti sono tagliato per essere un programmatore. Se non sei completamente sicuro di essere un programmatore, ecco alcuni segnali che potrebbero indirizzarti nella giusta direzione. Leggi di più .

Come definiresti un buon programmatore? Hai qualche consiglio per i programmatori inesperti che vogliono migliorare? Condividi con noi giù nei commenti qui sotto!

Scopri di più su: Programmazione.