it-swarm.it

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

Cosa dovrebbe considerare un programmatore che implementa i dettagli tecnici di un'applicazione Web prima di rendere pubblico il sito? Se Jeff Atwood può dimenticare HttpOnly cookies , sitemaps , andrichiesta tra siti falsi tutti nello stesso sito, quale cosa importante potrei anche dimenticare?

Ci sto pensando dal punto di vista di uno sviluppatore web, in modo tale che qualcun altro stia creando il design e i contenuti effettivi per il sito. Quindi, mentre l'usabilità e il contenuto possono essere più importanti della piattaforma, voi programmatori avete poco da dire in proposito. Quello di cui devi preoccuparti è che l'implementazione della piattaforma è stabile, funziona bene, è sicura e soddisfa tutti gli altri obiettivi aziendali (come non costare troppo, impiegare troppo tempo a costruire e classificare con Google come il supporto dei contenuti).

Pensa a questo dal punto di vista di uno sviluppatore che ha lavorato per applicazioni di tipo intranet in un ambiente abbastanza affidabile, e sta per avere il suo primo colpo e pubblicando un sito potenzialmente popolare per l'intero grande Web cattivo.

Inoltre, sto cercando qualcosa di più specifico di una vaga risposta "standard web". Voglio dire, HTML, JavaScript e CSS su HTTP sono praticamente un dato di fatto, soprattutto quando ho già specificato che sei uno sviluppatore web professionale. Andando oltre, Quale standard? In quali circostanze e perché? Fornisci un collegamento alle specifiche dello standard.

2187
Joel Coehoorn

L'idea qui è che la maggior parte di noi dovrebbe già conoscere la maggior parte di ciò che è in questo elenco. Ma potrebbero esserci solo uno o due elementi che non hai mai esaminato prima, che non capisci completamente o che non hai mai nemmeno sentito parlare.

Interfaccia ed esperienza utente

  • Tieni presente che i browser implementano gli standard in modo incoerente e assicurati che il tuo sito funzioni ragionevolmente bene su tutti i principali browser. Ad un test minimo contro un recente Gecko engine ( Firefox ), un motore WebKit ( Safari e alcuni browser mobili), Chrome , i tuoi supportati IE browser (sfrutta le Application Compatibility VPC Images ) e Opera . Considera anche come i browser visualizzano il tuo sito in diversi sistemi operativi.
  • Considera come le persone potrebbero utilizzare il sito diverso dai principali browser: telefoni cellulari, screen reader e motori di ricerca, ad esempio. - Alcune informazioni sull'accessibilità: WAI e Section508 , Sviluppo mobile: MobiForge .
  • Staging: come distribuire gli aggiornamenti senza influire sugli utenti. Avere uno o più ambienti di test o di gestione temporanea disponibili per implementare modifiche all'architettura, al codice o al contenuto ampio e garantire che possano essere distribuiti in modo controllato senza interrompere nulla. Avere un modo automatizzato per distribuire le modifiche approvate al sito live. Questo è implementato in modo più efficace in combinazione con l'uso di un sistema di controllo della versione (git, Subversion, ecc.) E un meccanismo di costruzione automatizzato (Ant, NAnt, ecc.).
  • Non visualizzare errori ostili direttamente all'utente.
  • Non mettere gli indirizzi e-mail degli utenti in chiaro perché verranno spammati a morte.
  • Aggiungi l'attributo _rel="nofollow"_ ai link generati dall'utente per evitare lo spam .
  • Costruisci limiti ben ponderati nel tuo sito - Anche questo appartiene alla sicurezza.
  • Scopri come fare miglioramento progressivo .
  • Reindirizzamento dopo un POST se quel POST ha avuto successo, per impedire che un aggiornamento venga inviato nuovamente.
  • Non dimenticare di tenere conto dell'accessibilità. È sempre una buona idea e in determinate circostanze è un requisito legale . WAI-ARIA e WCAG 2 sono buone risorse in quest'area.
  • Leggi Non farmi pensare .

Sicurezza

performance

  • Implementare la memorizzazione nella cache, se necessario, comprendere e utilizzare HTTP caching correttamente e HTML5 Manifest .
  • Ottimizza immagini: non utilizzare un'immagine da 20 KB per uno sfondo ripetuto.
  • Comprimi il contenuto per la velocità, vedi brotli , gzip/deflate (deflate is better).
  • Combina/concatena 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 i duplicati tra i file.
  • Dai un'occhiata al sito Yahoo Exceptional Performance , molte linee guida eccezionali, incluso il miglioramento delle prestazioni del front-end e il loro strumento YSlow (richiede Firefox, Safari, Chrome o Opera). Inoltre, Google page speed (usa con estensione del browser ) è un altro strumento per la profilazione delle prestazioni e ottimizza anche le tue immagini.
  • Usa CSS Image Sprites per piccole immagini correlate come le barre degli strumenti (vedi il punto "minimizza le richieste HTTP")
  • Usa Sprite di immagini SVG per piccole immagini correlate come le barre degli strumenti. La colorazione SVG è un po 'complicata. Puoi leggerlo qui .
  • I siti Web occupati dovrebbero considerare suddivisione dei componenti tra domini . In particolare ...
  • Il contenuto statico (ad esempio immagini, CSS, JavaScript e generalmente contenuto che non necessita dell'accesso ai cookie) dovrebbe andare in un dominio separato che non utilizza i cookie , poiché tutti i cookie per un dominio e i suoi sottodomini vengono inviati con ogni richiesta al dominio e ai suoi sottodomini. Una buona opzione qui è quella di utilizzare una rete di distribuzione di contenuti (CDN), ma considerare il caso in cui tale CDN potrebbe non riuscire includendo CDN alternative o copie locali che possono essere offerte invece.
  • Ridurre al minimo il numero totale di richieste HTTP richieste per un browser per eseguire il rendering della pagina.
  • Scegli un template engine e renderlo/pre-compilalo usando runner come gulp o grunt
  • Assicurati che ci sia un file _favicon.ico_ nella radice del sito, ovvero _/favicon.ico_. I browser lo richiederanno automaticamente , anche se l'icona non è affatto menzionata nell'HTML. Se non hai un _/favicon.ico_, ciò comporterà un sacco di 404 secondi, riducendo la larghezza di banda del tuo server.

SEO (ottimizzazione per i motori di ricerca)

  • Utilizza URL "compatibili con i motori di ricerca", ovvero usa _example.com/pages/45-article-title_ anziché _example.com/index.php?page=45_
  • Quando si utilizza _#_ per il contenuto dinamico, cambiare _#_ in _#!_ e quindi sul server _$_REQUEST["_escaped_fragment_"]_ è ciò che utilizza googlebot invece di _#!_. In altre parole, _./#!page=1_ diventa _./?_escaped_fragments_=page=1_. Inoltre, per gli utenti che potrebbero utilizzare FF.b4 o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); è un ottimo comando. Quindi, 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 invii il link che stiamo inviando questa pagina e AJAX non è necessario per fare un'altra richiesta extra.
  • Non utilizzare collegamenti che indicano "fai clic qui" . Stai sprecando un'opportunità SEO e rende le cose più difficili per le persone con screen reader.
  • Avere una XML sitemap , preferibilmente nella posizione predefinita _/sitemap.xml_.
  • Utilizza _<link rel="canonical" ... />_ quando hai più URL che puntano allo stesso contenuto, questo problema può essere risolto anche da Strumenti per i Webmaster di Google .
  • Utilizza Strumenti per i Webmaster di Google e Strumenti per i Webmaster di Bing .
  • Installa Google Analytics proprio all'inizio (o uno strumento di analisi open source come Piwik ).
  • Scopri come funzionano robots.txt ​​e gli spider dei motori di ricerca.
  • Reindirizzare le richieste (utilizzando _301 Moved Permanently_) chiedendo _www.example.com_ a _example.com_ (o viceversa) per evitare di dividere la classifica di google tra i due siti.
  • Sappi che ci possono essere ragni mal educati là fuori.
  • Se hai contenuti non testuali, cerca nelle estensioni sitemap di Google per i video, ecc. Ci sono alcune buone informazioni a riguardo in Tim Farley's answer .

Tecnologia

  • Comprendi HTTP e cose come GET, POST, sessioni, cookie e cosa significa essere "apolidi".
  • Scrivi il tuo XHTML / HTML e CSS secondo specifiche W3C e assicurati che convalida . L'obiettivo qui è quello di evitare le stranezze del browser e, come bonus, è molto più semplice lavorare con browser non tradizionali come screen reader e dispositivi mobili.
  • Comprendi come viene elaborato JavaScript nel browser.
  • Scopri come vengono caricati JavaScript, i fogli di stile e altre risorse utilizzate dalla tua pagina e considera il loro impatto sulle prestazioni percepite . Ora è ampiamente considerato appropriato spostare gli script in basso delle tue pagine con eccezioni che sono in genere cose come app di analisi o shim HTML5.
  • Scopri come funziona la sandbox JavaScript, soprattutto se intendi utilizzare iframe.
  • Tenere presente che JavaScript può e sarà disabilitato e che AJAX è quindi un'estensione, non una base. Anche se la maggior parte degli utenti lo lascia ora, ricorda che NoScript ​​sta diventando più popolare. Anche se i moderni robot di scansione supportano l'indicizzazione del contenuto generato da JavaScript, è consigliabile utilizzare il rendering sul lato server per altri robot di scansione o utenti che hanno disabilitato JavaScript.
  • Scopri differenza tra 301 e 302 reindirizzamenti (anche questo è un problema SEO).
  • Scopri il più possibile sulla tua piattaforma di distribuzione.
  • Prendi in considerazione l'uso di un Ripristina foglio di stile o normalize.css .
  • Considera i framework JavaScript (come jQuery , MooTools , Prototype , Dojo o YUI =), che nasconderà molte differenze del browser quando si utilizza JavaScript per la manipolazione del DOM.
  • Tenendo insieme le prestazioni percepite e i framework JS, considera l'utilizzo di un servizio come Google Libraries API per caricare i framework in modo che un browser possa utilizzare una copia del framework che ha già memorizzato nella cache anziché scaricare una copia duplicata da il tuo sito.
  • Non reinventare la ruota. Prima di fare QUALCOSA cercare un componente o un esempio su come farlo. C'è una probabilità del 99% che qualcuno l'abbia fatto e abbia rilasciato una versione OSS del codice.
  • D'altro canto, non iniziare con 20 librerie prima ancora di aver deciso quali sono le tue esigenze. Soprattutto sul Web lato client dove è quasi sempre più importante mantenere le cose leggere, veloci e flessibili.

Bug fixing

  • Comprendi che spenderai il 20% del tuo tempo nella codifica e l'80% della sua manutenzione, quindi codifica di conseguenza.
  • Impostare una buona soluzione per la segnalazione degli errori.
  • Avere un sistema con cui le persone possano contattarti per suggerimenti e critiche.
  • Documentare come funziona l'applicazione per il personale di supporto futuro e le persone che eseguono la manutenzione.
  • Fai backup frequenti! (E assicurati che quei backup siano funzionali) Avere una strategia di ripristino, non solo una strategia di backup.
  • Utilizzare un sistema di controllo versione per memorizzare i file, ad esempio Subversion , Mercurial o Git .
  • Non dimenticare di fare il test di accettazione. Frame come Selenium possono aiutare. Soprattutto se automatizzi completamente i tuoi test, magari utilizzando uno strumento di integrazione continua, come Jenkins .
  • Assicurarsi di disporre di una registrazione sufficiente utilizzando framework come log4j , log4net ​​o log4r . Se qualcosa va storto sul tuo sito live, avrai bisogno di un modo per scoprire cosa.
  • Durante la registrazione, assicurarsi di acquisire sia le eccezioni gestite sia le eccezioni non gestite. Segnala/analizza l'output del registro, in quanto ti mostrerà dove si trovano i problemi chiave nel tuo sito.

Altro

  • Implementare monitoraggio e analisi sia lato server che lato client (si dovrebbe essere proattivi piuttosto che reattivi).
  • Utilizza servizi come UserVoice e Intercom (o qualsiasi altro strumento simile) per rimanere costantemente in contatto con i tuoi utenti.
  • Segui Vincent Driessen 's Git branching model

Molte cose sono state omesse 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 avere una visione d'insieme delle cose che dovrebbero sapere. Non esitate a modificare anche questo, probabilmente mi sono perso alcune cose o ho fatto degli errori.

2655
victoriah