Hvilke tekniske detaljer bør en programmerer av en webapplikasjon vurdere før nettstedet offentliggjøres?

Tanken her er at de fleste av oss allerede burde kjenne til det meste av det som står på denne listen. Men det kan være ett eller to punkter du ikke har satt deg inn i før, ikke helt forstår eller kanskje aldri har hørt om. **Grensesnitt og brukeropplevelse

• Vær oppmerksom på at nettlesere implementerer standarder på ulikt vis, og sørg for at nettstedet ditt fungerer rimelig bra i alle de store nettleserne. Test som et minimum mot en nyere Gecko-motor (Firefox), en WebKit-motor (Safari og noen mobilnettlesere), Chrome, de støttede IE-nettleserne (dra nytte av Application Compatibility VPC Images) og Opera. Vurder også hvordan nettlesere gjengir nettstedet i ulike operativsystemer.
• Tenk på hvordan folk kan komme til å bruke nettstedet på andre måter enn fra de store nettleserne: mobiltelefoner, skjermlesere og søkemotorer, for eksempel. — Litt informasjon om tilgjengelighet: WAI og Section508, mobilutvikling: MobiForge.
• Staging: Slik distribuerer du oppdateringer uten at det påvirker brukerne. Ha ett eller flere test- eller staging-miljøer tilgjengelig for å implementere endringer i arkitektur, kode eller omfattende innhold og sikre at de kan distribueres på en kontrollert måte uten å ødelegge noe. Ha en automatisert metode for å distribuere godkjente endringer til live-siden. Dette implementeres mest effektivt i forbindelse med bruk av et versjonskontrollsystem (git, Subversion osv.) og en automatisert byggemekanisme (Ant, NAnt osv.).
• Ikke vis uvennlige feil direkte til brukeren.
• Ikke skriv brukernes e-postadresser i ren tekst, da de vil bli spammet til døde.
• Legg til attributtet rel="nofollow" til brukergenererte lenker for å unngå spam.
• Bygg inn veloverveide begrensninger på nettstedet ditt - Dette hører også hjemme under Sikkerhet.
• Lær hvordan du gjør progressiv forbedring.
• Omdiriger etter en POST hvis denne POST-en var vellykket, for å forhindre at en oppdatering sendes inn igjen.
• Ikke glem å ta hensyn til tilgjengelighet. Det er alltid en god idé, og under visse omstendigheter er det et lovkrav. WAI-ARIA og WCAG 2 er gode ressurser på dette området.
• Les Don't Make Me Think. **Sikkerhet
• Det er mye å fordøye, men OWASP development guide dekker sikkerhet på nettsteder fra topp til bunn.
• Kjenn til Injection, spesielt SQL injection, og hvordan du kan forhindre det.
• Stol aldri på brukerinndata eller noe annet som kommer i forespørselen (inkludert informasjonskapsler og skjulte skjemafeltverdier!).
• Hash passord ved hjelp av salt og bruk forskjellige salter for radene dine for å forhindre regnbueangrep. Bruk en langsom hashing-algoritme, for eksempel bcrypt (tidstestet) eller scrypt (enda sterkere, men nyere) (1, 2), til lagring av passord. (Slik lagrer du et passord på en sikker måte). NIST godkjenner også PBKDF2 for å hashe passord]25, og den er FIPS-godkjent i .NET (mer informasjon her). Unngå å bruke MD5- eller SHA-familien direkte.
• Ikke prøv å finne på ditt eget fancy autentiseringssystem (https://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely/1581919#1581919). Det er så lett å gjøre feil på subtile og ikke-testbare måter, og du vil ikke engang vite det før etter du blir hacket.
• Kjenn til reglene for behandling av kredittkort. (Se også dette spørsmålet)
• Bruk SSL/TLS/HTTPS for alle nettsteder der sensitive data legges inn (som legitimasjon, personlig identifiserbar informasjon, kredittkortinformasjon). Let's Encrypt er en gratis sertifikatmyndighet som kan hjelpe.
• Forhindre øktkapring]31.
• Unngå cross site scripting (XSS).
• Unngå cross site request forgeries (CSRF).
• Unngå clickjacking.
• Hold systemene dine oppdatert med de nyeste oppdateringene.
• Sørg for at informasjonen om databasetilkoblingen er sikret.
• Hold deg informert om de nyeste angrepsteknikkene og sårbarhetene som påvirker plattformen din.
• Les The Google Browser Security Handbook.
• Les The Web Application Hacker's Handbook.
• Ta hensyn til The principle of least privilege. Prøv å kjøre app-serveren din som ikke-root. (tomcat-eksempel)
• Sett rel="noopener noreferrer" på alle brukerleverte lenker med target="_blank" for å forhindre at JavaScript på destinasjonssiden omdirigerer siden din til et annet sted, for eksempel en falsk påloggingsside. Mer informasjon
• Vurder å bruke strenge retningslinjer for innholdssikkerhet. **Ytelse
• Implementer hurtigbufring om nødvendig, forstå og bruk HTTP-hurtigbufring på riktig måte, samt HTML5 Manifest.
• Optimaliser bilder - ikke bruk et 20 KB stort bilde til en gjentagende bakgrunn.
• Komprimer innhold for hastighet, se brotli, gzip/deflate (deflate er bedre).
• Kombiner/konkatener flere stilark eller flere skriptfiler for å redusere antall nettlesertilkoblinger og forbedre gzip-evnen til å komprimere dupliseringer mellom filer.
• Ta en titt på nettstedet Yahoo Exceptional Performance, med mange gode retningslinjer, inkludert forbedring av front-end-ytelsen og verktøyet YSlow (krever Firefox, Safari, Chrome eller Opera). Også Google page speed (bruk med nettleserutvidelse) er et annet verktøy for ytelsesprofilering, og det optimaliserer også bildene dine.
• Bruk CSS Image Sprites for små relaterte bilder som verktøylinjer (se punktet "minimer HTTP-forespørsler")
• Bruk SVG image sprites for små relaterte bilder som verktøylinjer. SVG-fargelegging er litt vanskelig. Du kan lese om det her.
• Travle nettsteder bør vurdere å dele opp komponenter på tvers av domener. Nærmere bestemt...
• Statisk innhold (dvs. bilder, CSS, JavaScript og generelt innhold som ikke trenger tilgang til informasjonskapsler) bør plasseres i et eget domene som ikke bruker informasjonskapsler, fordi alle informasjonskapsler for et domene og dets underdomener sendes med alle forespørsler til domenet og dets underdomener. Et godt alternativ her er å bruke et innholdsleveringsnettverk (Content Delivery Network, CDN), men ta høyde for at CDN-et kan svikte ved å inkludere alternative CDN-er eller lokale kopier som kan brukes i stedet.
• Minimer det totale antallet HTTP-forespørsler som kreves for at en nettleser skal kunne gjengi siden.
• Velg en template engine og render/forhåndskompiler den ved hjelp av task-runners som gulp eller grunt.
• Sørg for at det finnes en favicon.ico-fil i roten av nettstedet, dvs. /favicon.ico. Nettlesere vil automatisk be om det, selv om ikonet ikke er nevnt i HTML i det hele tatt. Hvis du ikke har en /favicon.ico, vil dette resultere i mange 404-er, noe som tapper serverens båndbredde. SEO (optimalisering for søkemotorer).
• Bruk søkemotorvennlige nettadresser, dvs. bruk example.com/pages/45-article-title i stedet for example.com/index.php?page=45.
• Når du bruker # for dynamisk innhold, endrer du # til #!, og på serveren bruker googlebot $_REQUEST["_escaped_fragment_"] i stedet for #!. Med andre ord blir ./#!page=1 til ./?_escaped_fragments_=page=1. For brukere som kanskje bruker FF.b4 eller Chromium, er history.pushState({"foo":"bar"}, "About", "./?page=1"); en flott kommando. Så selv om adresselinjen er endret, lastes ikke siden inn på nytt. Dette gjør at du kan bruke ? i stedet for #! for å beholde dynamisk innhold og også fortelle serveren når du sender lenken via e-post at vi er etter denne siden, og AJAX trenger ikke å gjøre en ekstra forespørsel.
• Ikke bruk lenker som sier "klikk her". Du kaster bort en SEO-mulighet, og det gjør det vanskeligere for personer med skjermlesere.
• Ha et XML-sitemap, helst på standardplasseringen /sitemap.xml.
• Bruk `` når du har flere nettadresser som peker til samme innhold, dette problemet kan også løses fra Google Webmaster Tools.
• Bruk Google Webmaster Tools og Bing Webmaster Tools.
• Installer Google Analytics helt fra starten av (eller et analyseverktøy med åpen kildekode som Piwik).
• Sett deg inn i hvordan robots.txt og søkemotorens edderkopper fungerer.
• Omdiriger forespørsler (ved hjelp av 301 Moved Permanently) som ber om www.example.com til example.com (eller omvendt) for å unngå å splitte Google-rankingen mellom de to nettstedene.
• Vær oppmerksom på at det kan finnes edderkopper som oppfører seg dårlig.
• Hvis du har annet innhold enn tekst, bør du undersøke Googles sitemap-utvidelser for video osv. Det finnes god informasjon om dette i Tim Farley's svar. **Teknologi
• Forstå HTTP og ting som GET, POST, økter, informasjonskapsler og hva det betyr å være "stateless".
• Skriv XHTML/HTML og CSS i henhold til W3C-spesifikasjonene og sørg for at de validerer. Målet er å unngå særegenheter i nettleseren og som en bonus gjøre det mye enklere å arbeide med ikke-tradisjonelle nettlesere som skjermlesere og mobile enheter.
• Forstå hvordan JavaScript behandles i nettleseren.
• Forstå hvordan JavaScript, stilark og andre ressurser som brukes på siden din, lastes inn, og vurder hvordan de påvirker opplevd ytelse. Det er nå allment ansett som hensiktsmessig å flytte skript til bunnen av sidene dine, med unntak av ting som analyseapper eller HTML5-shims.
• Forstå hvordan JavaScript-sandkassen fungerer, spesielt hvis du har tenkt å bruke iframes.
• Vær oppmerksom på at JavaScript kan og vil bli deaktivert, og at AJAX derfor er en utvidelse, ikke en basisfunksjon. Selv om de fleste vanlige brukere lar det være på nå, må du huske at NoScript blir stadig mer populært, at mobile enheter kanskje ikke fungerer som forventet, og at Google ikke vil kjøre det meste av JavaScriptet ditt når nettstedet indekseres.
• Lær deg forskjellen mellom 301- og 302-omdirigeringer (dette er også et SEO-spørsmål).
• Lær så mye du kan om distribusjonsplattformen din.
• Vurder å bruke Reset Style Sheet eller normalize.css.
• Vurder JavaScript-rammeverk (for eksempel jQuery, MooTools, Prototype, Dojo eller YUI 3), som skjuler mange av nettleserforskjellene når du bruker JavaScript til DOM-manipulering.
• Når det gjelder opplevd ytelse og JS-rammeverk, bør du vurdere å bruke en tjeneste som Google Libraries API til å laste inn rammeverk, slik at nettleseren kan bruke en kopi av rammeverket den allerede har bufret, i stedet for å laste ned en kopi fra nettstedet ditt.
• Ikke finn opp hjulet på nytt. Før du gjør NOE, søk etter en komponent eller et eksempel på hvordan du gjør det. Det er 99 % sjanse for at noen har gjort det og gitt ut en OSS-versjon av koden.
• På den andre siden bør du ikke begynne med 20 biblioteker før du i det hele tatt har bestemt deg for hva du trenger. Spesielt på klientsiden på nettet, der det nesten alltid er viktigere å holde ting lett, raskt og fleksibelt. **Feilretting
• Forstå at du kommer til å bruke 20 % av tiden din på koding og 80 % på vedlikehold, så kod deretter.
• Sett opp en god løsning for feilrapportering.
• Ha et system der folk kan kontakte deg med forslag og kritikk.
• Dokumenter hvordan applikasjonen fungerer for fremtidige supportmedarbeidere og personer som utfører vedlikehold.
• Ta hyppige sikkerhetskopier! (Og sørg for at disse sikkerhetskopiene er funksjonelle) Ha en strategi for gjenoppretting, ikke bare en strategi for sikkerhetskopiering.
• Bruk et versjonskontrollsystem til å lagre filene dine, for eksempel Subversion, Mercurial eller Git.
• Ikke glem å utføre akseptansetesting. Rammeverk som Selenium kan være til hjelp. Spesielt hvis du helautomatiserer testingen, kanskje ved å bruke et verktøy for kontinuerlig integrasjon, for eksempel Jenkins.
• Sørg for at du har tilstrekkelig logging ved hjelp av rammeverk som log4j, log4net eller log4r. Hvis noe går galt på live-siden din, trenger du en måte å finne ut hva det er.
• Når du logger, må du sørge for å fange opp både håndterte og uhåndterte unntak. Rapporter/analyser loggutdataene, da de vil vise deg hvor de viktigste problemene er på nettstedet ditt. **Annet
• Implementer overvåking og analyse på både server- og klientsiden (den ene bør være proaktiv snarere enn reaktiv).
• Bruk tjenester som UserVoice og Intercom (eller andre lignende verktøy) for å holde kontinuerlig kontakt med brukerne.
• Følg Vincent Driessen's Git-forgreningsmodell. Mange ting er utelatt, ikke nødvendigvis fordi de ikke er nyttige svar, men fordi de enten er for detaljerte, utenfor omfanget eller går litt for langt for noen som ønsker å få en oversikt over ting de bør vite. Du må gjerne redigere dette også, jeg har sikkert oversett noe eller gjort noen feil.