Sviluppo Web: i 10 codici antipattern da evitare

La progettazione dell'architettura di un sito Web o di un'applicazione o la creazione di un flusso di lavoro di codifica efficace spesso ci fanno affrontare problemi ricorrenti. Non è necessario risolvere questi problemi di progettazione del software da zero, poiché le soluzioni a livello di architettura possono essere riutilizzate allo stesso modo degli snippet di codice a livello micro .

Gli schemi di progettazione sono generalmente soluzioni riutilizzabili per determinati scenari, che possono rivelarsi utili per risolvere i problemi più comuni e possono enormemente aiutarci a ottimizzare il nostro codice.

Mentre i modelli di progettazione sono ottimi per migliorare il nostro processo di sviluppo utilizzando formule ben testate, a volte possiamo anche sbagliare. Questi sono chiamati antipattern.

Quali sono gli antipattern?

Il termine "antipattern" è stato coniato in un libro intitolato AntiPattern nel 1998. Si riferisce a soluzioni riutilizzate che inizialmente sembrano utili, ma in seguito risulta più dannoso che utile.

Questo può accadere per diversi motivi, ad esempio se non utilizziamo i modelli nel giusto contesto, impostazione o tempo (le soluzioni che erano efficaci in passato potrebbero non funzionare sempre nel presente), o in altri casi l'intero paradigma era solo male fin dall'inizio.

Gli antipattern sono anche spesso chiamati modelli di fallimento . La buona notizia è che è possibile riconoscerli ed evitarli .

In questo post daremo un'occhiata a 10 antipatterns di codifica comuni nello sviluppo web che potrebbero farci pensare che abbiamo codice ben ottimizzato. (Nota che gli antipatternati elencati in questo post non sono necessariamente uguali a quelli che puoi trovare nel libro sopra menzionato).

1. Ottimizzazione prematura

Il buon tempismo è un fattore cruciale nell'ottimizzazione del codice. Possiamo facilmente riprodurre l'antipattern di "ottimizzazione prematura", se prestiamo attenzione a piccole efficienze e ottimizziamo per loro troppo presto nel processo di sviluppo, prima di sapere esattamente cosa vogliamo fare.

Secondo la famosa frase di Donald Knuth, "l'ottimizzazione prematura è la radice di tutti i mali", che può essere un'esagerazione, ma mostra ancora come in seguito possano verificarsi gravi problemi di ottimizzazione prematura.

Se ottimizziamo le prestazioni prima di configurare un'architettura efficace, potremmo ridurre la leggibilità del codice, rendere più difficile il debug e la manutenzione e aggiungere parti superflue al nostro codice.

Per prevenire l'ottimizzazione prematura, è una buona idea seguire il principio di programmazione YAGNI (Non ne hai bisogno), che consiglia di "implementare sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno".

2. Reinventare la ruota

L'antipattern "reinventare la ruota" è a volte indicato anche come "progettazione nel vuoto" . Succede quando vogliamo fare tutto da soli e scrivere tutto da zero, senza cercare metodi, API o librerie già esistenti.

Reinventare la ruota non è solo una perdita di tempo, ma le soluzioni personalizzate, in particolare per le funzionalità di base, sono raramente valide come quelle standard che sono già state testate da molti sviluppatori e utenti.

3. Hell infernale

L'opposto del "reinventare la ruota" antipattern è un altro antipattern comune chiamato "inferno di dipendenza" .

Se, invece di scrivere tutto da zero, usiamo troppe librerie di terze parti che si basano su versioni specifiche di altre librerie, possiamo facilmente trovarci in una situazione difficilmente gestibile quando vogliamo aggiornarle, poiché queste dipendenze sussidiarie sono in molti casi incompatibili con l'un l'altro .

L'inferno di dipendenza può essere risolto utilizzando i gestori di pacchetti che sono in grado di aggiornare in modo intelligente le dipendenze interdipendenti . Se siamo troppo sopraffatti dal problema, il refactoring può anche essere una buona idea.

4. Codice degli spaghetti

"Spaghetti code" è probabilmente il più famoso antipasto di codifica. Descrive un'applicazione che è difficile da eseguire il debug o modificare a causa della mancanza di un'architettura adeguata .

Il risultato di una cattiva progettazione del software è un mucchio di codice simile nella struttura a una ciotola di spaghetti, cioè aggrovigliati e contorti . La leggibilità del codice spaghetti è molto bassa, ed è solitamente una missione quasi impossibile capire come funziona esattamente.

Il codice di Spaghetti deriva solitamente dalla combinazione di diverse pratiche di codifica errate, come il codice che non contiene blocchi condizionali corretti, con molte istruzioni goto, eccezioni e thread, contenenti parti che appartengono ad altre parti, ha relazioni minime tra oggetti, ha funzioni o metodi che non possono essere riutilizzati, o non sono documentati correttamente o affatto.

5. Programmazione per permutazione

"Programmazione per permutazione" o "programmazione per caso" si verifica quando cerchiamo di trovare una soluzione per un problema sperimentando in successione piccole modifiche, testandole e valutandole una ad una e infine implementando quella che funziona inizialmente.

Programmare per permutazione può facilmente introdurre nuovi bug nel nostro codice, peggio ancora, sono bug che non riconosciamo necessariamente in una volta. In molti casi, è anche impossibile prevedere se la soluzione funzionerà per tutti gli scenari possibili, oppure no.

6. Copia e incolla la programmazione

"Copia e incolla programmazione" si verifica quando non seguiamo il principio di codifica Do not Repeat Yourself (DRY) e invece di creare soluzioni generiche, inseriamo snippet di codice già esistenti in posizioni diverse, e successivamente li modificiamo per adattarli dato contesto.

Questa pratica si traduce in un codice altamente ripetitivo, in quanto le parti di codice inserite di solito differiscono solo in piccole discrepanze.

La copia e incolla della programmazione non è impegnata solo dagli sviluppatori alle prime armi, ma anche dai programmatori esperti, poiché molti di loro sono inclini a utilizzare i propri frammenti di codice pre-scritti e ben testati per attività specifiche, che possono facilmente portare a ripetizioni involontarie .

7. Programmazione Cargo-Cult

Il nome di "programmazione del culto del carico" deriva da uno specifico fenomeno etnografico chiamato "culto del carico". I culti del carico apparvero nel Pacifico meridionale dopo la seconda guerra mondiale, quando il contatto forzato con civiltà avanzate indusse i nativi a pensare che i prodotti fabbricati, come la Coca-Cola, i televisori e i frigoriferi portati dalle navi mercantili verso le isole, fossero creati da soprannaturali metodi; e se eseguono riti magici simili alle usanze degli occidentali, il carico pieno di merci verrà di nuovo.

Quando commettiamo l'antipattern della programmazione del culto del carico, fondamentalmente facciamo lo stesso. Utilizziamo framework, librerie, soluzioni, modelli di progettazione, ecc. Che hanno funzionato bene per gli altri, senza capire perché lo facciamo, o come funzionano esattamente le tecnologie.

In molti casi gli sviluppatori fanno solo ritualmente ciò che è anca in quel momento senza uno scopo reale . Questa pratica non è male solo perché rende superflua la nostra applicazione, ma può anche introdurre facilmente nuovi bug nel nostro codice.

8. Flusso di lava

Parliamo del "flusso di lava" antipattern quando abbiamo bisogno di trattare il codice che ha parti ridondanti o di bassa qualità che sembrano essere parte integrante del programma, eppure non capiamo completamente cosa fa o come influenza l'intera applicazione . Questo rende rischioso rimuoverlo.

Di solito accade con il codice legacy, o quando il codice è stato scritto da qualcun altro (di solito senza documentazione adeguata), o quando il progetto è passato troppo velocemente dallo sviluppo alla fase di produzione.

Il nome di questo antipattern deriva dalla sua somiglianza con la lava proveniente dai vulcani, cioè all'inizio si muove rapidamente e fluidamente senza prendere troppe precauzioni, ma in seguito si solidifica e diventa difficile da rimuovere.

In teoria, possiamo sbarazzarci dei flussi di lava con test approfonditi e refactoring, ma in pratica l'implementazione è spesso difficile o addirittura impossibile . Poiché i flussi di lava di solito hanno costi di prestazioni elevati, è meglio prevenirli impostando un'architettura ben progettata e un flusso di lavoro sonoro dall'inizio.

9. Hard Coding

"Hard coding" è un antipattern ben noto contro il quale la maggior parte dei libri di sviluppo web ci avverte proprio nella prefazione. L'hard coding è la sfortunata pratica in cui memorizziamo dati di input o di configurazione, come un percorso file o un nome host remoto, nel codice sorgente piuttosto che ottenerlo da un file di configurazione, da un database, da un input dell'utente o da un'altra fonte esterna .

Il problema principale con il codice duro è che funziona correttamente solo in un determinato ambiente, e in qualsiasi momento le condizioni cambiano, abbiamo bisogno di modificare il codice sorgente, di solito in più posti separati.

10. Codifica morbida

Se ci sforziamo molto per evitare il trabocchetto di hard coding, possiamo facilmente imbattersi in un altro antipattern chiamato "soft coding", che è il suo esatto opposto.

Nel soft coding, inseriamo le cose che dovrebbero essere nel codice sorgente in fonti esterne, ad esempio memorizziamo la logica di business nel database. Il motivo più comune per cui lo facciamo è il timore che le regole aziendali cambino in futuro, pertanto dovremo riscrivere il codice.

In casi estremi, un programma con codice morbido può diventare così astratto e complicato che è quasi impossibile comprenderlo (soprattutto per i nuovi membri del team) ed estremamente difficile da mantenere e eseguire il debug .