Innhold
Det nye nettstedet ditt oppfører seg ikke slik du forventer - men hvordan vet du om feilen er skjult i koden din, eller om det er et nettleserproblem? Vi spurte ekspertene.
Paul Lewis
Lag alltid en redusert prøvesak. På den måten eliminerer du muligheten for at feilen er i koden eller et rammeverk. Det vil også hjelpe deg med å definere utløserne for feilen som vises. Når du har den reduserte testsaken som viser feilen, må noen andre sjekke koden. Vi gjør alle feil fordi vi er for kjent med koden vår. Vær aldri redd for å sende inn en feil som inkluderer testsaken din - det er den beste måten å få reparasjoner prioritert av leverandører.
Paul Lewis er utvikler talsmann for Google
Bruce Lawson
Selvfølgelig tester du i alle nettlesere, ikke sant? Så hvis du ser en feil i alle nettlesere, er det sannsynligvis koden din. Forsikre deg om at du tester over hele spekteret - fordi forskjellige nettlesere kan dele den samme gjengivelsesmotoren; Opera og Chrome, for eksempel, bruker begge Blink-rendering-motoren, så vil de vise de samme nettleserfeilene.
For å begrense det ytterligere, valider koden din med validator.w3.org, sjekk CSS på jigsaw.w3.org/css-validator og se i DevTools-konsollen for å fange eventuelle JS-feil.
Hvis bare en gjengivelsesmotor ikke fungerer som den skal, vær så snill, vær så snill å rapportere feilen til nettleseren. Vi elsker å fikse feil, og det gjør alles liv bedre. Steve Faulkner har en flott guide til rapportering av feil.
Bruce Lawson er en talsmann for åpne standarder for Opera
Chris Heilmann
For å kunne fortelle om en feil er din eller nettleseren, er det noen få ting du kan gjøre. Den første er virkelig å teste antagelsene dine. Er det du opplever virkelig en 'bug' eller bare 'ikke det du forventet'? Det er mange eksempler der en nettleser gjør noe annerledes enn hva du vil at den skal gjøre, fordi det er slik den ble definert i standarden. Derfor er det viktig å sjekke om dette for å validere.
Som utviklere forventer vi ofte at ting skal være så enkle som abstraksjoner som biblioteker og forprosessorer gjør dem for oss, men å ha den samme funksjonaliteten i en nettleser vil gjøre at den fungerer fryktelig sakte.
I alle fall er det noen måter å finne ut om nettleserens buggy eller om du gjorde noe galt:
- Test hva du gjør på tvers av forskjellige nettlesere - hvis de alle viser at det er feil, er det mest sannsynlig at du har gjort en feil
- Hvis bare en nettleser 'gjør det galt', søk i nettleserens feilsporingsverktøy. Du kan finne en feiloppføring og en løsning på den måten. Hvis ikke, kan du sende en ny feil - du kan bidra til å gjøre nettlesere bedre på den måten
- Sjekk feilloggen til nettleserkonsollen - de fleste nettlesere har nå lesbare feil
- Bruk utviklerverktøy for å spore opp hva som virkelig skjer. Utvikling i disse dager er mye mer kompleks enn det pleide å være - forprosessorer og biblioteker og deres interaksjon kan kaste mange nøkler. Bruk blackbox-funksjonene i Firefox 1, for eksempel for å sikre at du egentlig bare feilsøker koden din - feilen kan være forårsaket av et bibliotek du brukte
- Sett brytepunkter og gå gjennom koden trinn for trinn - det kan være en manglende variabel eller en i et annet format enn forventet
- Sjekk nettverksfanen for å se om avhengigheter ikke ble lastet inn eller hadde feil MIME-type, eller om en skrift ikke ble lastet inn
- Sjekk innstillingene til din lokale server - ofte sendes ikke ressurser i feil format, og får nettleseren til å kveles
Nettlesere er ikke perfekte, men de kan forbedres. Det er imidlertid mye mer sannsynlig at noe i koden din gikk galt, enn at en nettleser virkelig er ødelagt. Det føles mye bedre å skylde på nettleseren enn å finne ut hva som gikk galt på slutten, så det er naturlig å gå for det.
Chris Heilmann er hovedevangelist i Mozilla
Lea Verou
Hvis du får et annet resultat i hver nettleser (forutsatt at alle funksjonene du bruker støttes i hver nettleser du tester i), har du definitivt snublet over en nettleserfeil!
Selvfølgelig er jobben din ikke ferdig ennå: du må redusere den til det essensielle før du rapporterer den. For det første fordi du ellers ikke aner hva feilen er nøyaktig, så hvordan kan du søke hvis den allerede er rapportert? For det andre, fordi jo mer nøyaktig feilrapporten din er, jo større er sjansene dine for å fikse den - snart. Jeg skrev en artikkel om å lage feilrapporter for noen år siden, og det meste er fortsatt ganske relevant.
Du må også finne ut hvilken nettleser som er buggy ved å lese den aktuelle spesifikasjonen. Du kan bli overrasket over å finne ut at noen av nettleserne du testet noen ganger vil være buggy. For eksempel testet jeg nylig 'resize' -egenskapen på pseudo-elementer, og det viste seg at både WebKit / Blink og Gecko var buggy på forskjellige måter, så jeg måtte sende inn tre feilrapporter!
Nå når du tester en funksjon som bare støttes av en gjengivelsesmotor, eller når du får det samme resultatet overalt, men du mistenker at det er feil, er det vanskeligere å vite om du faktisk har snublet over en feil. Igjen, det beste alternativet er å isolere problemet så mye som mulig, og deretter lese spesifikasjonen og sammenligne forventet resultat med det du får.
Ikke utelukk muligheten for at spesifikasjonen i seg selv er buggy - spesifikasjoner er skrevet av mennesker, og er langt fra perfekte. I så fall må du rapportere problemet til riktig W3C-adresseliste (www-style for CSS). Ikke vær sjenert - standarder elsker å få kommentarer fra forfattere om hvordan disse spesifikasjonene brukes i naturen. Selv om det viser seg ikke å være en feil, er innspillene uvurderlige!
Lea Verou er en CSS WG-invitert ekspert
Frances Berriman
Hvis du tror du har en nettleserfeil på hendene, kan du lage en testtilfelle - dette er et eksempel på at feilen bruker den minste mengden kode som trengs for å utløse den uventede effekten eller feilen, og ideelt sett fjerner du all bruk av biblioteker andre avhengigheter. 99 prosent av tiden, bare å gå gjennom bevegelsene for å fjerne koden din til bare bein, vil hjelpe deg med å identifisere at feilen er din egen, og for at 1 prosent at den ikke er det, har du et eksempel på utgave for å rapportere til nettleserutviklerne.
Frances Berriman er seniordesigner og frontingeniør
Anna Debenham
Dette skjedde med meg nylig. Jeg isolerte koden i en demo på JS Bin for å forsikre meg om at ingenting annet jeg hadde skrevet forårsaket den, og begrenset den til et par linjer med CSS. Jeg testet demoen på forskjellige nettlesere og enheter, og innså at feilen bare dukket opp i den siste versjonen av webkit for elementer med gjentatte bakgrunnsbilder, en bakgrunnsfarge og en CSS-transformasjon! For å hjelpe alle andre som kom over det samme problemet, sendte jeg inn en feilrapport.
Anna Debenham er en frontend-utvikler
Rey Bango
Som webutvikler klandrer jeg alltid nettleserprodusentene fordi jeg vet at jeg aldri skriver buggy-kode! Helt seriøst antar jeg at 99 prosent av tiden antar at en feil er knyttet til koden jeg skriver bare fordi nettleserprodusenter gjør en ganske god jobb med å fange mange av problemene på forhånd.
Nettleserbaserte feilsøkingsverktøy har utviklet seg enormt, slik at du ganske enkelt kan gå ned i problemer. Par det med et godt lintingsverktøy som JSHint, og i de fleste tilfeller kan du enkelt identifisere problemer forårsaket av utviklere.
En nøkkelindikator for at noe kan være oppe på nettlesersiden er når den samme koden mislykkes i forskjellige nettlesere. Det er vanligvis en indikasjon på forskjeller i funksjonens implementering, på hvilket tidspunkt en redusert testtilfelle må skje. Det er derfor det alltid anbefales å teste nettlesere i deres opprinnelige miljøer, slik at du kan se gjengivelsen og redegjøre for nyanser av hvert operativsystem.
Jeg pleier å bruke JSBin eller CodePen for å lage de reduserte testscenariene, siden disse gjør det utrolig enkelt å lage markering og JavaScript-utdrag for å simulere koden din. Når du har funnet ut at det er et nettleserbasert problem, må du huske å rapportere det. Det er for lett å anta at noen andre vil, så det å gjøre det ekstra trinnet for å arkivere en feil gjør en stor forskjell.
Rey Bango er utvikler talsmann for Microsoft
Dette er en utvidet versjon av en artikkel publisert i nettmagasin nummer 259.
