Sviluppo Web I 10 Coding Antipatterns che devi evitare
Progettare l'architettura di un sito Web o un'applicazione, o impostare un flusso di lavoro di codifica efficace, spesso ci fa affrontare problemi ricorrenti. Non abbiamo necessariamente bisogno di risolvere questi problemi di progettazione del software da zero, come le soluzioni a livello architettonico possono essere riutilizzate allo stesso modo di snippet di codice a livello micro.
I modelli di progettazione sono generalmente soluzioni riutilizzabili per determinati scenari, ciò può tornare utile per risolvere i problemi che si verificano comunemente, e può aiutarci enormemente a ottimizzare il nostro codice.
Mentre i modelli di progettazione sono ottimi mezzi per migliorare il nostro processo di sviluppo utilizzando formule ben testate, a volte possiamo anche sbagliare. Questi sono chiamati antipattern.
Cosa 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 poi si scopre fare più male che bene.
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 brutto fin dall'inizio.
Spesso vengono anche chiamati antipattern modelli di fallimento. La buona notizia è che lo è 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 alle piccole efficienze e ottimizziamo per loro troppo presto nel processo di sviluppo, prima di sapere esattamente cosa vogliamo fare.
Secondo la famosa citazione di Donald Knuth “l'ottimizzazione prematura è la radice di tutto il male“, che può essere un'esagerazione, ma mostra ancora quanto gravi problemi possano essere causati dall'ottimizzazione prematura.
Se ottimizziamo le prestazioni prima di configurare un'architettura efficace, potremmo minore leggibilità del codice, rendere debug e manutenzione più difficile, 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 “implementa sempre le cose quando ne hai effettivamente bisogno, mai quando prevedi di averne bisogno.”
2. Reinventare la ruota
Il “reinventare la ruota” l'antipattern è a volte indicato anche come “progettando 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 cosa che fa perdere tempo, ma le soluzioni personalizzate, in particolare per le funzionalità di base, sono raramente valide come quelle standard che sono già stati testati da molti sviluppatori e utenti.
3. Hell infernale
L'opposto di “reinventare la ruota” antipattern è un altro antipattern comune chiamato “dipendenza inferno”.
Se, invece di scrivere tutto da zero, lo usiamo troppe librerie di terze parti che si basano su versioni specifiche di altre librerie, possiamo facilmente imbattersi in una situazione difficilmente gestibile quando vogliamo aggiornare, in quanto queste dipendenze sussidiarie sono in molti casi incompatibile tra loro.
L'inferno di dipendenza può essere risolto usando i gestori di pacchetti che sono in grado di farlo 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
“Codice degli spaghetti” è probabilmente il più famoso antipasto di codifica. Esso 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, vale a dire. aggrovigliato e contorto. La leggibilità del codice spaghetti è molto bassa, ed è solitamente una missione quasi impossibile capire come funziona esattamente.
Il codice degli spaghetti di solito deriva da combinazione di diverse cattive pratiche di codifica, come il codice che non contiene i 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” succede quando proviamo a trovare una soluzione per un problema sperimentando in successione piccole modifiche, testandole e valutandole una ad una e infine implementando quella che funziona inizialmente.
La programmazione 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 la 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 al contesto dato.
Questa pratica produce un codice altamente ripetitivo, poiché 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, in quanto molti di loro sono inclini a farlo utilizzare i propri snippet di codice pre-scritti e ben testati per attività specifiche, che può facilmente portare a ripetizioni non intenzionali.
7. Programmazione Cargo-Cult
Il nome di “programmazione cargo-setta” 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, schemi di progettazione, ecc. Che hanno funzionato bene per gli altri, senza capire perché lo facciamo, o come funzionano esattamente queste tecnologie.
In molti casi solo gli sviluppatori ritualmente fare ciò che è anca in quel momento senza uno scopo reale. Questa pratica non è solo cattiva perché rende la nostra applicazione superflua gonfia, ma può anche facilmente introdurre nuovi bug nel nostro codice.
8. Lava Flow
Parliamo del “flusso di lava” antipattern quando abbiamo bisogno di gestire il codice con parti ridondanti o di bassa qualità quello sembra essere integrale al programma, ma non capiamo completamente cosa fa o come influenza l'intera applicazione. Questo rende rischioso rimuoverlo.
Di solito succede con codice legacy, o quando il 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 dell'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 i dati di configurazione o di input, 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 è quello funziona correttamente solo in un determinato ambiente, e a in qualsiasi momento le condizioni cambiano, dobbiamo modificare il codice sorgente, di solito in più posti separati.
10. Codifica morbida
Se ci sforziamo molto per evitare la trappola di hard coding, possiamo facilmente imbattersi in un altro antipattern chiamato “codifica morbida”, che è il suo esatto opposto.
Nella codifica morbida, mettiamo le cose che dovrebbero essere nel codice sorgente in fonti esterne, per 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, quindi dovremo riscrivere il codice.
In casi estremi, un programma con codice morbido può diventare così astratto e contorto che è quasi impossibile comprenderlo (in particolare per i nuovi membri del team) ed estremamente difficile da mantenere e correggere.
