I 10 errori più comuni commessi dagli sviluppatori Web: un tutorial per sviluppatori

Da quando il termine World Wide Web è stato coniato nel 1990, lo sviluppo di applicazioni Web si è evoluto dal servizio di pagine HTML statiche ad applicazioni aziendali complesse e completamente dinamiche.

Oggi disponiamo di migliaia di risorse digitali e cartacee che forniscono istruzioni dettagliate sullo sviluppo di tutti i tipi di applicazioni Web differenti. Gli ambienti di sviluppo sono abbastanza "intelligenti" da rilevare e correggere molti errori con cui i primi sviluppatori hanno combattuto regolarmente. Esistono anche molte piattaforme di sviluppo diverse che trasformano facilmente semplici pagine HTML statiche in applicazioni altamente interattive.

Tutti questi modelli, pratiche e piattaforme di sviluppo condividono un terreno comune e sono tutti soggetti a problemi di sviluppo Web simili causati dalla natura stessa delle applicazioni Web.

Lo scopo di questi suggerimenti per lo sviluppo web è far luce su alcuni degli errori comuni commessi nelle diverse fasi del processo di sviluppo web e aiutarti a diventare uno sviluppatore migliore. Ho toccato alcuni argomenti generali che sono comuni praticamente a tutti gli sviluppatori web come la convalida, la sicurezza, la scalabilità e la SEO. Ovviamente non dovresti essere vincolato dagli esempi specifici che ho descritto in questa guida, poiché sono elencati solo per darti un'idea dei potenziali problemi che potresti incontrare.

Errore comune n. 1: convalida dell'input incompleta

La convalida dell'input dell'utente sul lato client e server è semplicemente un must ! Siamo tutti consapevoli del saggio consiglio "non fidarti dell'input dell'utente" ma, tuttavia, gli errori derivanti dalla convalida si verificano troppo spesso.

Una delle conseguenze più comuni di questo errore è SQL Injection che è nella Top 10 di OWASP anno dopo anno.

Ricorda che la maggior parte dei framework di sviluppo front-end fornisce regole di convalida pronte all'uso che sono incredibilmente semplici da usare. Inoltre, la maggior parte delle principali piattaforme di sviluppo back-end utilizza semplici annotazioni per garantire che i dati inviati rispettino le regole previste. L'implementazione della convalida potrebbe richiedere molto tempo, ma dovrebbe far parte della tua pratica di codifica standard e non essere mai messa da parte.

Errore comune n. 2: autenticazione senza un'adeguata autorizzazione

Prima di procedere, assicuriamoci di essere allineati su questi due termini. Come indicato nelle 10 vulnerabilità di sicurezza Web più comuni:

Autenticazione: verifica che una persona sia (o almeno sembra essere) un utente specifico, poiché ha fornito correttamente le proprie credenziali di sicurezza (password, risposte a domande di sicurezza, scansione delle impronte digitali, ecc.).

Autorizzazione: conferma che un determinato utente ha accesso a una risorsa specifica o ha ottenuto l'autorizzazione per eseguire una determinata azione.

Detto in altro modo, l'autenticazione è sapere chi è un'entità, mentre l'autorizzazione è sapere cosa può fare una determinata entità.

Permettetemi di dimostrare questo problema con un esempio:

Considera che il tuo browser conserva le informazioni sull'utente attualmente registrato in un oggetto simile al seguente:

 { username:'elvis', role:'singer', token:'123456789' }

Quando si modifica la password, l'applicazione esegue il POST:

 POST /changepassword/:username/:newpassword

Nel tuo metodo /changepassword , verifichi che l'utente abbia effettuato l'accesso e che il token non sia scaduto . Quindi trovi il profilo utente basato sul parametro :username e modifichi la password dell'utente.

Quindi, hai verificato che il tuo utente abbia effettuato correttamente l'accesso e quindi hai eseguito la sua richiesta cambiando così la sua password. Il processo sembra a posto, giusto? Sfortunatamente la risposta è no!

A questo punto è importante verificare che l'utente che esegue l'azione e l'utente la cui password è stata modificata siano gli stessi. Qualsiasi informazione memorizzata sul browser può essere manomessa e qualsiasi utente avanzato potrebbe facilmente aggiornare username:'elvis' in username:'Administrator' senza utilizzare nient'altro che gli strumenti del browser integrati.

Quindi, in questo caso, ci siamo solo occupati Authentication assicurandoci che l'utente fornisse le credenziali di sicurezza. Possiamo anche aggiungere la convalida che il metodo /changepassword può essere eseguito solo da utenti Authenticated . Tuttavia, questo non è ancora sufficiente per proteggere i tuoi utenti da tentativi dannosi.

Devi assicurarti di verificare il richiedente effettivo e il contenuto della richiesta all'interno del tuo metodo /changepassword e implementare un'adeguata Authorization della richiesta assicurandoti che l'utente possa modificare solo i suoi dati.

Authentication e Authorization sono due facce della stessa medaglia. Non trattarli mai separatamente.

Errore comune n. 3: non pronto per la scalabilità

Nel mondo odierno di sviluppo ad alta velocità, acceleratori di avvio e portata globale istantanea di grandi idee, avere il tuo MVP (prodotto minimo sostenibile) sul mercato il prima possibile è un obiettivo comune per molte aziende.

Tuttavia, questa costante pressione di tempo fa sì che anche i migliori team di sviluppo web trascurino spesso determinati problemi. Il ridimensionamento è spesso una di quelle cose che i team danno per scontate. Il concetto di MVP è fantastico, ma spingilo troppo oltre e avrai seri problemi. Sfortunatamente, la selezione di un database scalabile e di un server Web e la separazione di tutti i livelli dell'applicazione su server scalabili indipendenti non sono sufficienti. Ci sono molti dettagli a cui devi pensare se desideri evitare di riscrivere parti significative della tua applicazione in un secondo momento, il che diventa un grave problema di sviluppo web.

Ad esempio, supponiamo che tu scelga di archiviare le immagini del profilo caricate dei tuoi utenti direttamente su un server web. Questa è una soluzione perfettamente valida: i file sono rapidamente accessibili all'applicazione, i metodi di gestione dei file sono disponibili in ogni piattaforma di sviluppo e puoi persino servire queste immagini come contenuto statico, il che significa un carico minimo sull'applicazione.

Ma cosa succede quando la tua applicazione cresce e devi utilizzare due o più server Web dietro un sistema di bilanciamento del carico? Anche se hai ridimensionato bene l'archiviazione del database, i server dello stato della sessione e i server Web, la scalabilità dell'applicazione fallisce a causa di una cosa semplice come le immagini del profilo. Pertanto, è necessario implementare una sorta di servizio di sincronizzazione dei file (che avrà un ritardo e causerà errori 404 temporanei) o un'altra soluzione alternativa per garantire che i file siano distribuiti sui server Web.

Quello che dovevi fare per evitare il problema in primo luogo era semplicemente utilizzare la posizione di archiviazione dei file condivisa, il database o qualsiasi altra soluzione di archiviazione remota. Sarebbe probabilmente costato qualche ora in più di lavoro per implementare tutto, ma ne sarebbe valsa la pena.

Errore comune n. 4: SEO errato o mancante

La causa principale delle migliori pratiche SEO errate o mancanti sui siti Web sono gli "specialisti SEO" disinformati. Molti sviluppatori web credono di sapere abbastanza sulla SEO e che non sia particolarmente complesso, ma non è vero. La padronanza SEO richiede molto tempo dedicato alla ricerca delle migliori pratiche e delle regole in continua evoluzione su come Google, Bing e Yahoo indicizzano il Web. A meno che tu non sperimenti costantemente e disponga di un monitoraggio + analisi accurato, non sei uno specialista SEO e non dovresti affermare di esserlo.

Inoltre, la SEO viene troppo spesso posticipata come alcune attività che vengono eseguite alla fine. Questo ha un prezzo elevato per i problemi di sviluppo web. La SEO non è solo correlata all'impostazione di buoni contenuti, tag, parole chiave, metadati, tag alternativi di immagine, mappa del sito, ecc. Include anche l'eliminazione di contenuti duplicati, l'architettura del sito scansionabile, tempi di caricamento efficienti, back linking intelligente, ecc.

Come con la scalabilità, dovresti pensare alla SEO dal momento in cui inizi a creare la tua applicazione web, oppure potresti scoprire che completare il tuo progetto di implementazione SEO significa riscrivere l'intero sistema.

Errore comune n. 5: azioni che consumano tempo o processore nei gestori delle richieste

Uno dei migliori esempi di questo errore è l'invio di e-mail in base a un'azione dell'utente. Troppo spesso gli sviluppatori pensano che fare una chiamata SMTP e inviare un messaggio direttamente dal gestore delle richieste dell'utente sia la soluzione.

Supponiamo che tu abbia creato un negozio di libri online e prevedi di iniziare con qualche centinaio di ordini al giorno. Come parte del processo di acquisizione dell'ordine, invii e-mail di conferma ogni volta che un utente pubblica un ordine. All'inizio funzionerà senza problemi, ma cosa succede quando ridimensioni il tuo sistema e improvvisamente ricevi migliaia di richieste che inviano e-mail di conferma? O si ottengono timeout della connessione SMTP, quota superata o il tempo di risposta dell'applicazione si riduce notevolmente poiché ora gestisce le e-mail anziché gli utenti.

Qualsiasi azione che richiede tempo o il processore dovrebbe essere gestita da un processo esterno mentre rilasci le tue richieste HTTP il prima possibile. In questo caso, dovresti disporre di un servizio di posta esterno che ritiri gli ordini e invii notifiche.

Errore comune n. 6: non ottimizzare l'utilizzo della larghezza di banda

La maggior parte dello sviluppo e dei test avviene in un ambiente di rete locale. Pertanto, quando scarichi 5 immagini di sfondo ciascuna di 3 MB o più, potresti non identificare un problema con la velocità di connessione di 1 Gbit nel tuo ambiente di sviluppo. Ma quando i tuoi utenti iniziano a caricare una home page di 15 MB su connessioni 3G sui loro smartphone, dovresti prepararti per un elenco di reclami e problemi.

L'ottimizzazione dell'utilizzo della larghezza di banda potrebbe darti un grande aumento delle prestazioni e per ottenere questo aumento probabilmente hai solo bisogno di un paio di trucchi. Ci sono poche cose che molti buoni sviluppatori web fanno per impostazione predefinita, tra cui:

1. Minimizzazione di tutto JavaScript
2. Minimizzazione di tutti i CSS
3. Compressione HTTP lato server
4. Ottimizzazione delle dimensioni e della risoluzione dell'immagine

Errore comune n. 7: non sviluppo per schermi di dimensioni diverse

Il design reattivo è stato un argomento importante negli ultimi anni. L'espansione degli smartphone con diverse risoluzioni dello schermo ha portato molti nuovi modi di accedere ai contenuti online, che comporta anche una serie di problemi di sviluppo web. Il numero di visite al sito web che provengono da smartphone e tablet cresce ogni giorno e questa tendenza sta accelerando.

Per garantire una navigazione e un accesso senza interruzioni ai contenuti del sito Web, è necessario consentire agli utenti di accedervi da tutti i tipi di dispositivi.

Esistono numerosi modelli e pratiche per la creazione di applicazioni Web reattive. Ogni piattaforma di sviluppo ha i suoi suggerimenti e trucchi, ma ci sono alcuni framework che sono indipendenti dalla piattaforma. Il più popolare è probabilmente Twitter Bootstrap. È un framework HTML, CSS e JavaScript open source e gratuito che è stato adottato da tutte le principali piattaforme di sviluppo. Aderisci semplicemente ai modelli e alle pratiche Bootstrap durante la creazione della tua applicazione e otterrai un'applicazione Web reattiva senza alcun problema.

Errore comune n. 8: incompatibilità cross-browser

Il processo di sviluppo è, nella maggior parte dei casi, sotto pressione. Ogni applicazione deve essere rilasciata il prima possibile e anche i buoni sviluppatori web sono spesso concentrati sulla fornitura di funzionalità rispetto al design. Indipendentemente dal fatto che la maggior parte degli sviluppatori abbia installato Chrome, Firefox, IE, utilizza solo uno di questi il ​​90% delle volte. È pratica comune utilizzare un browser durante lo sviluppo e, appena l'applicazione si avvicina al completamento, inizierai a testarla in altri browser. Questo è perfettamente ragionevole, supponendo che tu abbia molto tempo per testare e risolvere i problemi che si presentano in questa fase.

Tuttavia, ci sono alcuni suggerimenti per lo sviluppo web che possono farti risparmiare molto tempo quando la tua applicazione raggiunge la fase di test cross-browser:

1. Non è necessario eseguire il test in tutti i browser durante lo sviluppo; è dispendioso in termini di tempo e inefficace. Tuttavia, ciò non significa che non puoi cambiare browser frequentemente. Usa un browser diverso ogni due giorni e almeno riconoscerai i problemi principali all'inizio della fase di sviluppo.
2. Fai attenzione a usare le statistiche per giustificare il non supportare un browser. Ci sono molte organizzazioni che sono lente nell'adozione di nuovi software o nell'aggiornamento. Migliaia di utenti che lavorano lì potrebbero ancora aver bisogno di accedere alla tua applicazione e non possono installare il browser gratuito più recente a causa della sicurezza interna e delle politiche aziendali.
3. Evita il codice specifico del browser. Nella maggior parte dei casi è disponibile una soluzione elegante compatibile con più browser.

Errore comune n. 9: non pianificare la portabilità

L'assunzione è la madre di tutti i problemi! Quando si tratta di portabilità, questo detto è più vero che mai. Quante volte hai riscontrato problemi nello sviluppo Web come percorsi di file codificati, stringhe di connessione al database o ipotesi che una determinata libreria sarà disponibile sul server? Presupporre che l'ambiente di produzione corrisponda al computer di sviluppo locale è semplicemente sbagliato.

La configurazione ideale dell'applicazione dovrebbe essere esente da manutenzione:

1. Assicurati che la tua applicazione possa ridimensionarsi ed essere eseguita in un ambiente con più server con bilanciamento del carico.
2. Consenti una configurazione semplice e chiara, possibilmente in un unico file di configurazione.
3. Gestire le eccezioni quando la configurazione del server Web non è quella prevista.

Errore comune n. 10: Anti Pattern RESTful

Le API RESTful hanno preso il loro posto nello sviluppo web e sono qui per restare. Quasi tutte le applicazioni Web hanno implementato una sorta di servizi REST, sia per uso interno che per integrazione con sistemi esterni. Ma vediamo ancora modelli RESTful rotti e servizi che non aderiscono alle pratiche previste.

Due degli errori più comuni commessi durante la scrittura di un'API RESTful sono:

1. Utilizzo di verbi HTTP sbagliati. Ad esempio, utilizzando GET per scrivere i dati. HTTP GET è stato progettato per essere idempotente e sicuro, il che significa che non importa quante volte chiami GET sulla stessa risorsa, la risposta dovrebbe essere sempre la stessa e non dovrebbe verificarsi alcun cambiamento nello stato dell'applicazione.

2. Non invia codici di stato HTTP corretti. Il miglior esempio di questo errore è l'invio di messaggi di errore con codice di risposta 200.

    HTTP 200 OK { message:'there was an error' }

Dovresti inviare HTTP 200 OK solo quando la richiesta non ha generato un errore. In caso di errore, è necessario inviare 400, 401, 500 o qualsiasi altro codice di stato appropriato per l'errore che si è verificato.

Una panoramica dettagliata dei codici di stato HTTP standard è disponibile qui.

Incartare

Sviluppo Web è un termine estremamente ampio che può comprendere legittimamente lo sviluppo di un sito Web, un servizio Web o un'applicazione Web complessa.

Il punto principale di questa guida allo sviluppo web è il promemoria che dovresti sempre fare attenzione all'autenticazione e all'autorizzazione, pianificare la scalabilità e non dare mai per scontato nulla frettolosamente o essere pronto ad affrontare una lunga lista di problemi di sviluppo web!