Quali dettagli tecnici dovrebbe considerare un programmatore di un'applicazione web prima di rendere il sito pubblico?

L'idea qui è che la maggior parte di noi dovrebbe già conoscere la maggior parte di ciò che è su questa lista. Ma ci potrebbero essere uno o due elementi che non avete mai esaminato prima, non capite appieno, o forse non avete nemmeno mai sentito parlare. Interfaccia ed esperienza utente

• Siate consapevoli che i browser implementano gli standard in modo incoerente e assicuratevi che il vostro sito funzioni ragionevolmente bene su tutti i principali browser. Come minimo fai dei test con un recente motore Gecko (Firefox), un motore WebKit (Safari e alcuni browser mobili), Chrome, i tuoi browser IE supportati (approfitta delle immagini VPC di compatibilità delle applicazioni), e Opera. Considera anche come i browser rendono il tuo sito in diversi sistemi operativi.
• Considera come le persone potrebbero usare il sito oltre che dai principali browser: telefoni cellulari, lettori di schermo e motori di ricerca, per esempio: WAI e Section508, Sviluppo mobile: MobiForge.
• Staging: Come distribuire gli aggiornamenti senza influenzare i vostri utenti. Avere uno o più ambienti di test o di staging disponibili per implementare modifiche all'architettura, al codice o ai contenuti di sweeping e assicurarsi che possano essere distribuiti in modo controllato senza rompere nulla. Avere un modo automatico per distribuire le modifiche approvate al sito live. Questo è più efficacemente implementato in combinazione con l'uso di un sistema di controllo di versione (git, Subversion, ecc.) e un meccanismo di build automatico (Ant, NAnt, ecc.).
• Non mostrate errori ostili direttamente all'utente.
• Non mettere gli indirizzi email degli utenti in testo semplice, perché verranno spammati a morte.
• Aggiungi l'attributo rel="nofollow" ai link generati dagli utenti per evitare lo spam.
• Costruisci limiti ben ponderati nel tuo sito]13 - Anche questo appartiene alla voce Sicurezza.
• Impara come fare miglioramento progressivo.
• Reindirizzare dopo un POST]15 se quel POST ha avuto successo, per evitare che un refresh si presenti di nuovo.
• Non dimenticate di prendere in considerazione l'accessibilità. È sempre una buona idea e in certe circostanze è un requisito legale. WAI-ARIA e WCAG 2 sono buone risorse in questo campo.
• Leggi Don't Make Me Think. Sicurezza
• E' molto da digerire ma la OWASP development guide copre la sicurezza dei siti web da cima a fondo.
• Conoscere l'Iniezione, specialmente l'SQL injection e come prevenirla.
• Non fidarsi mai dell'input dell'utente, né di qualsiasi altra cosa che arriva nella richiesta (che include i cookie e i valori nascosti dei campi dei moduli!).
• Effettuate l'hashing delle password usando salt e usate sali diversi per le vostre righe per prevenire gli attacchi rainbow. Utilizzare un algoritmo di hashing lento, come bcrypt (testato nel tempo) o scrypt (ancora più forte, ma più recente) (1, 2), per memorizzare le password. (Come conservare in sicurezza una password). Il NIST approva anche PBKDF2 per l'hash delle password", ed è approvato da FIPS in .NET (maggiori informazioni qui). Evitare di usare direttamente la famiglia MD5 o SHA.
• Non cercare di inventare il tuo sistema di autenticazione di fantasia](https://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely/1581919#1581919). E' una cosa così facile da sbagliare in modi sottili e non verificabili e non lo sapresti nemmeno fino a quando non sei stato hackerato.
• Conoscere le regole per l'elaborazione delle carte di credito. (Vedi anche questa domanda)
• Usare SSL/TLS/HTTPS per tutti i siti in cui vengono inseriti dati sensibili (come credenziali, informazioni di identificazione personale, informazioni sulla carta di credito). Let's Encrypt è un'autorità di certificazione gratuita che può aiutare.
• Prevenire l'hijacking di sessione]31.
• Evitare il cross site scripting (XSS).
• Evitare le falsificazioni di richieste cross site (CSRF).
• Evitare il Clickjacking.
• Mantenete i vostri sistemi aggiornati con le ultime patch.
• Assicuratevi che le informazioni di connessione al vostro database siano protette.
• Tenetevi informati sulle ultime tecniche di attacco e sulle vulnerabilità che riguardano la vostra piattaforma.
• Leggere The Google Browser Security Handbook.
• Leggere The Web Application Hacker's Handbook.
• Considerare Il principio del minimo privilegio. Provate ad eseguire il vostro app server come non-root. (esempio tomcat)
• Mettete rel="noopener noreferrer" su tutti i link forniti dall'utente con target="_blank" per evitare che JavaScript sulla pagina di destinazione reindirizzi la vostra pagina da qualche altra parte, come una falsa pagina di login. Maggiori informazioni
• Considerare l'utilizzo di una rigorosa politica di sicurezza dei contenuti. Performance
• Implementare il caching se necessario, capire e utilizzare correttamente HTTP caching così come HTML5 Manifest.
• Ottimizzare le immagini - non usare un'immagine di 20 KB per uno sfondo che si ripete.
• Comprimere il contenuto per la velocità, vedere brotli, gzip/deflate (deflate is better).
• Combinare/concatenare più fogli di stile o più file di script per ridurre il numero di connessioni del browser e migliorare la capacità di gzip di comprimere le duplicazioni tra i file.
• Date un'occhiata al sito Yahoo Exceptional Performance, un sacco di grandi linee guida, compreso il miglioramento delle prestazioni front-end e il loro strumento YSlow (richiede Firefox, Safari, Chrome o Opera). Inoltre, Google page speed (utilizzare con estensione del browser) è un altro strumento per il profiling delle prestazioni, e ottimizza anche le immagini.
• Usa CSS Image Sprites per piccole immagini correlate come le barre degli strumenti (vedi il punto "minimizza le richieste HTTP")
• Usa SVG image sprites per piccole immagini correlate come le barre degli strumenti. La colorazione SVG è un po' complicata. Puoi leggere a riguardo qui.
• I siti web occupati dovrebbero considerare dividere i componenti tra i domini. In particolare...
• Il contenuto statico (cioè immagini, CSS, JavaScript, e generalmente il contenuto che non ha bisogno di accedere ai cookie) dovrebbe andare in un dominio separato che non usa cookie, perché tutti i cookie per un dominio e i suoi sottodomini sono inviati con ogni richiesta al dominio e ai suoi sottodomini. Una buona opzione qui è usare una Content Delivery Network (CDN), ma considerate il caso in cui questa CDN possa fallire includendo CDN alternative, o copie locali che possono essere servite al suo posto.
• Minimizzare il numero totale di richieste HTTP necessarie a un browser per rendere la pagina.
• Scegliere un template engine e renderlo/precompilarlo usando task-runner come gulp o grunt
• Assicurati che ci sia un file favicon.ico nella root del sito, cioè /favicon.ico. [I browser lo richiederanno automaticamente (http://mathiasbynens.be/notes/rel-shortcut-icon), anche se l'icona non è affatto menzionata nell'HTML. Se non hai una /favicon.ico, questo provocherà un sacco di 404, prosciugando la larghezza di banda del tuo server. **SEO (ottimizzazione per i motori di ricerca)
• Usare "search engine friendly" URL, cioè usare example.com/pages/45-article-title invece di example.com/index.php?page=45.
• Quando si usa # per il contenuto dinamico cambia il # in #! e poi sul server $_REQUEST["_escaped_fragment_"] è quello che googlebot usa invece di #!. In altre parole, ./#!page=1 diventa ./?_escaped_fragments_=page=1. Inoltre, per gli utenti che potrebbero usare FF.b4 o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); è un ottimo comando. Così, anche se la barra degli indirizzi è cambiata, la pagina non viene ricaricata. Questo ti permette di usare ? invece di #! per mantenere il contenuto dinamico e anche dire al server quando mandi il link per email che siamo dopo questa pagina, e l'AJAX non ha bisogno di fare un'altra richiesta extra.
• Non usare link che dicono "clicca qui". Stai sprecando un'opportunità SEO e rende le cose più difficili per le persone con lettori di schermo.
• Avere una sitemap XML, preferibilmente nella posizione predefinita /sitemap.xml.
• Usa `` quando hai più URL che puntano allo stesso contenuto, questo problema può essere affrontato anche da Google Webmaster Tools.
• Usa Google Webmaster Tools e Bing Webmaster Tools.
• Installare Google Analytics fin dall'inizio (o uno strumento di analisi open source come Piwik).
• Conoscere il funzionamento di robots.txt e degli spider dei motori di ricerca.
• Reindirizzare le richieste (usando 301 Moved Permanently) che chiedono di www.example.com a example.com (o il contrario) per evitare di dividere il ranking di google tra i due siti.
• Sappiate che ci possono essere spider che si comportano male là fuori.
• Se hai un contenuto non testuale guarda le estensioni sitemap di Google per i video ecc. Ci sono alcune buone informazioni su questo in Tim Farley'risposta. Tecnologia
• Capire HTTP e cose come GET, POST, sessioni, cookies, e cosa significa essere "stateless".
• Scrivete il vostro XHTML/HTML e CSS secondo le specifiche W3C e assicuratevi che siano validati. L'obiettivo qui è quello di evitare le modalità bizzarre del browser e come bonus rendere molto più facile lavorare con i browser non tradizionali come gli screen reader e i dispositivi mobili.
• Capire come JavaScript viene processato nel browser.
• Capire come JavaScript, fogli di stile e altre risorse usate dalla vostra pagina vengono caricate e considerare il loro impatto sulle prestazioni percepite. È ora ampiamente considerato come appropriato spostare gli script in fondo delle vostre pagine con eccezioni tipicamente come le applicazioni di analisi o gli spessori HTML5.
• Capire come funziona la sandbox JavaScript, specialmente se si intende utilizzare gli iframe.
• Siate consapevoli che JavaScript può essere e sarà disabilitato, e che AJAX è quindi un'estensione, non una linea di base. Anche se la maggior parte degli utenti normali lo lascia attivo ora, ricordate che NoScript sta diventando sempre più popolare, i dispositivi mobili potrebbero non funzionare come previsto, e Google non eseguirà la maggior parte del vostro JavaScript quando indicizza il sito.
• Imparate la differenza tra 301 e 302 redirect (anche questo è un problema di SEO).
• Imparate il più possibile sulla vostra piattaforma di distribuzione.
• Considerare l'uso di un Reset Style Sheet o normalize.css.
• Considerare i framework JavaScript (come jQuery, MooTools, Prototype, Dojo o YUI 3), che nascondono molte delle differenze del browser quando si usa JavaScript per la manipolazione del DOM.
• Prendendo le prestazioni percepite e i framework JS insieme, considerate di usare un servizio come il Google Libraries API per caricare i framework in modo che un browser possa usare una copia del framework che ha già nella cache piuttosto che scaricare una copia duplicata dal vostro sito.
• Non reinventare la ruota. Prima di fare QUALSIASI COSA cercate un componente o un esempio su come farla. C'è il 99% di possibilità che qualcuno l'abbia fatto e abbia rilasciato una versione OSS del codice.
• Sul rovescio della medaglia, non iniziare con 20 librerie prima ancora di aver deciso quali sono i tuoi bisogni. In particolare sul web lato client dove è quasi sempre più importante mantenere le cose leggere, veloci e flessibili. Correzione dei bug
• Comprendete che passerete il 20% del vostro tempo a codificare e l'80% a mantenere, quindi codificate di conseguenza.
• Impostare una buona soluzione di segnalazione degli errori.
• Avere un sistema per le persone che ti contattano con suggerimenti e critiche.
• Documentate come funziona l'applicazione per il futuro staff di supporto e per le persone che fanno manutenzione.
• Fate frequenti backup! (E assicuratevi che quei backup siano funzionali) Avere una strategia di ripristino, non solo una strategia di backup.
• Usate un sistema di controllo della versione per memorizzare i vostri file, come Subversion, Mercurial o Git.
• Non dimenticate di fare i vostri test di accettazione. Frameworks come Selenium possono aiutare. Specialmente se automatizzate completamente i vostri test, magari usando uno strumento di integrazione continua, come Jenkins.
• Assicuratevi di avere un logging sufficiente usando framework come log4j, log4net o log4r. Se qualcosa va storto sul vostro sito live, avrete bisogno di un modo per scoprire cosa.
• Quando fai il log assicurati di catturare sia le eccezioni gestite che quelle non gestite. Riporta/analizza l'output del log, in quanto ti mostrerà dove sono i problemi chiave nel tuo sito. Altro
• Implementare il monitoraggio e l'analisi sia lato server che lato client (uno dovrebbe essere proattivo piuttosto che reattivo).
• Usa servizi come UserVoice e Intercom (o altri strumenti simili) per rimanere costantemente in contatto con i tuoi utenti.
• Seguire Vincent Driessen's Git branching model Un sacco di roba omessa non necessariamente perché non sono risposte utili, ma perché sono o troppo dettagliate, fuori portata, o vanno un po 'troppo lontano per qualcuno che cerca di ottenere una panoramica delle cose che dovrebbero sapere. Per favore, sentitevi liberi di modificare anche questo, probabilmente ho saltato alcune cose o fatto alcuni errori.