Share
Jeg hater feilsøking, og har aldri møtt noen utviklere som hevdet ellers. Det er en dra å måtte gå gjennom koden din og finne ut hvorfor det er ødelagt. Og viktigst er det en innrømmelse at koden min er ødelagt og at jeg ikke er ufeilbarlig! Kjetteri, sier jeg!
Alvorlig er bugs ganske enkelt en naturlig del av webutviklingsprosessen, og selv om vi kanskje hater dem, må vi sikkert takle dem. Front-end-utviklere har ikke alltid hatt rike feilsøkingsverktøy som andre plattformer og språk. I de gode dagene, varsling() var din venn og en viktig metode (unnskyld ordspillet) for feilsøkingskode. Og feilsøking av klient-side-koden har sitt eget unike sett med utfordringer på grunn av ulike teknologier som er i spill. Hvis du tenker på det, involverer feilsøkingssider, spesielt dynamiske, så mange bevegelige deler som kan påvirke gjengivelsen. Du har dokumentobjektmodellen (DOM), JavaScript, CSS, nettverkstrafikk, HTTP-overskrifter og mange flere teknologier som alle arbeider for å lage en side og i mange tilfeller påvirker og påvirker hverandre.
Heldigvis har tider blitt forandret, og alle de store nettleserne har innebygde verktøy som i stor grad øker feilsøkingsfunksjonene for utviklere. Jeg gir mye kreditt til Joe Hewitt for å skyve verktøyet landskapet fremover. Han opprettet Firebug i 2006. Etter min mening brøt den grunnen på hvilke virkelige nettleserverktøy som skulle være.
Siden da har vi sett Firebug utvikle seg enormt og tjene som en grunnlinje for at andre skal jobbe fra, og vi har nå kraftige verktøy i Chrome, Internet Explorer, Safari og Opera også.
For denne artikkelen skal jeg fokusere på utviklerverktøyene til Internet Explorer og funksjonaliteten den gir. Funksjonen jeg diskuterer vil være veldig kjent for alle som har brukt en nettleserbasert debugger, men jeg vil bringe fokus til Internet Explorer verktøy for å sikre at det er en god forståelse av hva som faktisk er tilgjengelig.
La meg begynne med å innrømme at jeg vet at IE er nettleseren du elsker å hate. Jeg forstår. Faktum i saken er at det er en stor nettleser som er viktig for mange besøkende, og det betyr at du skal målrette mot det og også trenger å feilsøke kode i det før eller senere. Hva er overraskende, er hvor mange utviklere ikke vet at IE sender med utviklerverktøy eller verre at de tror de fortsatt trenger å laste ned verktøylinjen for utviklere i Internet Explorer.
Utviklerverktøyene kalles vanligvis "F12 Developer Tools", fordi du trykker på "F12" -tasten på tastaturet, åpner dem når du er i Internet Explorer (interessant nok, å trykke F12 lanserer også Firebug og Chrome Developer Tools).
Utviklerverktøyene er også tilgjengelige via "Verktøy" -menyen under etiketten "F12-utviklerverktøy".
Nøkkelen jeg skulle stresse er at de er inkludert i Internet Explorer (og har vært siden IE8), så det er ikke nødvendig å installere et plugin for å få dev-verktøy. Også, mens de kalles "F12 Developer Tools", i denne artikkelen skal jeg slippe "F12" og lagre noen tastetrykk.
Utviklerverktøyene gir utviklere og designere et rikt sett med verktøy som kan takle mange av de vanlige feilsøkings- og inspeksjonsbrukstilfellene de vil møte under arbeidet. Muligheter som:
Dette er funksjoner som er par for kurset i dag og viktig for å avgjøre hva som skjer på sidene dine. Utover dette gir utviklerverktøyene muligheten til å teste nettstedet ditt i forskjellige versjoner av Internet Explorer ved å endre nettlesermodus:
Testing for flere versjoner av IE har tradisjonelt vært en kongelig smerte i tuckus; Denne funksjonen tar sikte på å senke friksjonen for å sikre at nettstedene dine fungerer på tvers av de ulike versjonene av IE.
Tilleggsfunksjoner inkluderer slike ting som:
Jeg fokuserer mye på å hjelpe utviklere bruke standardbaserte utviklingsteknikker for å sikre at deres nettsteder fungerer bra på IE. Som du kan forestille deg, bruker jeg mye tid til å analysere kode, spesielt JavaScript. Så, for å spore opp en merkelig feil, trenger jeg en JS-debugger som kan la meg analysere koden på mange måter.
En av de viktigste funksjonene for meg er muligheten til å prettify JavaScript. Jeg kjenner ingen utvikler som ikke minner sin produksjonskode nå til dags. Og det er absolutt den riktige tingen å gjøre, men når jeg trenger å feilsøke noe på et produksjonssted - spesielt der jeg ikke har tilgang til kildekoden - er det mulig å prettify koden være uvurderlig. Ja, det er elektroniske verktøy som JS Beautify som kan gjøre det, men det ville tvinge meg til å kopiere og lime inn kode i det for å deobfuscate koden. Å ha denne kapasiteten bygget rett inn sparer meg massevis av tid. For eksempel, si at jeg ser på en minifisert versjon av jQuery:
Via verktøyikonet kan jeg få tilgang til "Format JavaScript" -alternativet som vil deobfuscate den minifiserte jQuery-kildekoden og gi meg en betydelig mer lesbar kode:
Som du kan se på bildet over, er koden sikkert enklere å jobbe med. Den andre kule tingen om denne funksjonen er at når du har aktivert den, vil den fortsette å deobfuscate JS-filene dine under økten.
En advarsel er at deobfuscation-prosessen ikke vil returnere jQuery til sin opprinnelige kilde. Ingen tjeneste som jeg vet om kan gjøre det, men kildekart vil løse dette problemet framover. Husk å lese artikkelen på kildekart av Sayanee Basu som jeg bare har koblet til for en god intro på emnet.
Når koden er lesbar, gjør det det enklere å bestemme strømmen av kilden. På dette punktet kan jeg sette brytpunkter på logiske steder i koden for å isolere problemer mens du går gjennom det. Og selvfølgelig kan du angi flere brytepunkter over flere kildefiler.
Du kan også angi betingede bruddpunkter slik at du kan bryte kodeflyten basert på en bestemt verdi.
Som forventet kan du gå inn i, ut av eller over hvilken som helst metode du er i å gi den granulære kontrollen du trenger for å sjekke ut koden, og ikke kaste bort verdifull tid. Det som er viktig å merke seg er at når du krysser koden din, er det en samtalehøyle som er tilgjengelig som lar deg se hvordan du kom til en bestemt metode eller JavaScript-fil og gå tilbake til den metoden eller filen for å inspisere koden:
I tillegg hjelper det å isolere uventede kodebaner som kan være problempunktet.
Informasjon er nøkkelen til å forstå hva som skjer, og utviklerverktøyene fungerer for å gi deg mulighetene til å definere hva du vil se. Så sammen med anropsstakken får du informasjon om variabler i det nåværende omfanget via "Locals" -fanen:
Du kan også definere din egen overvåkingsliste (via fanen Watch), slik at du kan spore hvordan variable verdier endres dynamisk basert på kodekjøring. Den gode tingen er at verktøyene gir deg fleksibiliteten til å endre verdiene i hver liste, slik at du kan se hvordan det påvirker søknaden din.
Og la oss ikke glemme konsollen. Ingen debugger ville være nyttig uten en konsoll til å sende ut feil og tillate deg å debugge interaktivt:
Konsollen vil vise vanlige feil knyttet til siden din, inkludert JavaScript og oppslagsproblemer. Du kan også legge inn kommandoer for å kommunisere med siden, samt bruke konsollobjektet i JavaScript-koden din for å vise meldinger til konsollen.
Alt ovenfor er flott og absolutt verdifullt. Et ofte oversett aspekt av feilsøking er kodeytelse. Sjelden snakker jeg med utviklere som nevner hvordan de har evaluert sin kode for å fastslå flaskehalser i sakte kjøreretninger, spesielt fra tredjepartsrammer.
Utviklerverktøyene gir deg en JavaScript-profiler som vil analysere koden din når den kjøres, og gir et vell av informasjon som skal brukes for å optimalisere koden din.
Nøkkelbiter inkluderer:
Bevæpnet med denne informasjonen, kan du avgjøre om metoden din må refactored, hvis et 3. partibibliotek forårsaker problemer eller hvis en nettleserespesifikk metode er en flaskehals. For meg vil kombinasjonen av Inkluderende og Eksklusiv tid være viktige beregninger fordi det ville fortelle meg hvor lang tid en bestemt metode tok for å løpe, inkludert tiden det tok barn eller eksterne metoder å fullføre. Derfra kan jeg begynne å bore ned videre for å spikre ned problemkoden.
Jeg vil aldri glemme når jeg kodet min første Ajax-forespørsel. Det var en så liten kode, men det føltes ærlig, magisk (ja, jeg er rar på den måten). Gjør dynamiske DOM-oppdateringer basert på å trekke tilbake data fra en bakgrunn. HTTP-forespørselen var utrolig kul og en kraftig evne. Jeg vil aldri glemme den første gangen jeg prøvde å sende et resultat tilbake som endte opp med å generere en feil og la meg dumbfounded. Heldigvis, Firebug hadde en nettverksforespørselsinspektør som la meg sjekke ut hva min server-sidekode var tilbake og feilsøke den.
"Nettverk" -fanen i utviklerverktøyene gir denne funksjonaliteten. Den viser trafikk relatert til siden som lastes inn og viser detaljer som du kan bruke til å feilsøke nettverksrelaterte problemer.
Ved å se på trafikken fanget, kan du se hvilken type forespørsel som blir gjort (f.eks .: en GET eller POST), hvis den var vellykket og hvor lang tid det tok å fullføre. Nettverksinspektøren gir også viktige detaljer om typen aktiv du forespurte (for eksempel: CSS eller et bilde) og hvilken type kode initierte forespørselen. Dette er alt gitt i et sammendrag som gir rask informasjon om forespørslene.
Ved å velge å gå inn i detaljvisning, kan du hente granulær informasjon om en bestemt forespørsel. Å kunne se på svaret var det som tillot meg å løse problemet jeg nevnte før med mitt XHR-anrop. Men det er bare en liten del av de samlede dataene du får ved å slippe i detaljvisning. Bortsett fra det, får du forespørselens overskrifter (forespørsel og svar), informasjonskapsler som ble sendt og til og med tidspunkt for timing, som forteller deg hvor lenge forespørselen tok.
Timing-skjermen i oppsummeringsvisningen er veldig viktig fordi det er et klart bilde av hvilken forespørsel som kjører lenge og kan være et problem.
Jeg er den første som sier at jeg HATER tester for flere versjoner av Internet Explorer. Jeg er hovedsakelig irritert med de eldre versjonene, og jeg ville være glad hvis utviklere bare kunne bekymre seg for IE9 og IE10. Men det er hva det er, og det er et par måter å adressere dette på. Du kan bruke flere virtuelle maskiner for hver versjon av IE du målretter mot. Du kan bruke Browserstack.com til å virtualisere IE-versjoner i nettleseren. Eller du kan bruke utviklerverktøyets nettlesermodus bytte evne til å ha IE10 emulere IE7 gjennom IE10.
Dette verktøyet lar deg endre måten at IE gjør en side slik at den emulerer en bestemt versjonens evne, og dermed sikre at nettstedet ditt skal fungere for den versjonen. Ikke bare gjør det det mulig å spesifisere nettlesermodusen (som bestemmer funksjonstøtte), men også dokumentmodusen (som angir hvordan en side tolkes). Dette gir deg stor fleksibilitet til å teste ulike versjoner av IE fra en nettleser. Bare vær oppmerksom på at IE-teamet gjør sitt beste for å etterligne versjoner. Hvis du vil ha full-proof testing, så er VMs veien å gå. Jeg starter vanligvis med det siste alternativet fordi det er uten tvil den enkleste og gjengivelsen er svært nær å faktisk bruke en bestemt innfødt versjon av IE.
Inspeksjon av markup er en av de vanligste oppgavene for enhver webprofessor. Det er flott å kunne se under hetten på hvordan noe er bygget uten å måtte gjøre en "View-> Source". "HTML" -fanen i utviklerverktøyene viser alle elementene på en bestemt side sammen med deres relaterte stiler og attributter. Dette lar deg inspisere og oppdatere verdier i sanntid og få umiddelbar tilbakemelding. Du kan klikke på, si et stykkeelement, og det blir redigerbart, slik at du kan endre teksten og se resultatene umiddelbart. Det samme gjelder stilene og attributter til elementet.
Attributter kan også legges inn inline ved å høyreklikke et element og velge "Legg til attributt" fra hurtigmenyen eller ved å velge kategorien "Attributter" og legge det til i listen. Følgende bilde viser hvordan jeg har lagt til et farge- og skriftattributt til vektorgruppen, og viser dem som inline-stiler i markerings- og individuelle attributtlinjer på fanen Attributter:
Sidens markering er representert i treeview-stil, slik at du ser en oversikt over DOM-treet og kan utvide elementer for å se barna sine.
CSS har også sin egen kategori, men det er ment å administrere globale stilarter som vanligvis lagres i stilark. Velger et stilark viser alle valgene, reglene og egenskapene som er definert, og lar deg finjustere dem som du vil. I dette tilfellet, flyttet du bare av tekstjusteringsegenskapen dynamisk til teksten til venstre:
Det er ikke bare å redigere eksisterende regler. Du kan også legge til nye selektorer, regler eller egenskaper:
Den primære grunnen til at jeg ønsket å skrive dette stykket er fordi jeg var virkelig overrasket over hvor mange utviklere jeg har møtt, hvem hadde en misforståelse om F12 Developer Tools - eller visste ikke at de selv eksisterte! Mitt håp er at det hjelper utviklere å få en følelse av hva som er tilgjengelig og gjør feilsøkingen litt enklere.
Jeg håper også at det genererer tilbakemelding for fremtidige funksjoner som utviklere trenger. Mens den eksisterende funksjonaliteten er god, er jeg sikker på at det finnes en rekke nye ting som du, leserne, ville finne avgjørende for feilsøkingsopplevelsen. Gi meg beskjed om hva de er!
Accentsconagua