Share
Ik haat debuggen en heb nog nooit een ontwikkelaar ontmoet die anders ruzie heeft gemaakt. Het is een sleur om door je code te moeten gaan en uit te zoeken waarom hij kapot is. En nog belangrijker, het is een erkenning dat mijn code is verbroken en dat ik niet onfeilbaar ben! Ketterij, zeg ik!
Maar serieus, bugs zijn gewoon een natuurlijk onderdeel van het webontwikkelingsproces en hoewel we ze misschien haten, moeten we er zeker mee omgaan. Front-end ontwikkelaars hebben niet altijd uitgebreide foutopsporingstools zoals andere platforms en talen. In de goede 'oude dagen, alert () was je vriend en een belangrijke methode (excuseer de woordspeling) voor de code voor probleemoplossing. En het debuggen van client-side code heeft zijn eigen unieke reeks uitdagingen vanwege de verscheidenheid aan technologieën die in het spel zijn. Als u erover nadenkt, bevat het debuggen van pagina's, vooral dynamische, zoveel bewegende delen die de weergave kunnen beïnvloeden. U hebt het Document Object Model (DOM), JavaScript, CSS, netwerkverkeer, HTTP-headers en nog veel meer technologieën die allemaal werken om een pagina te produceren en in veel gevallen interacteren en elkaar beïnvloeden.
Gelukkig zijn de tijden veranderd en hebben alle grote browsers ingebouwde hulpprogramma's die de probleemoplossing voor ontwikkelaars aanzienlijk vergroten. Ik geef Joe Hewitt veel lof voor het vooruithelpen van het gereedschap. Hij creëerde Firebug in 2006. Naar mijn mening brak het terrein aan wat echte browser-tools zouden moeten zijn.
Sindsdien hebben we Firebug enorm zien evolueren en fungeren als basis voor anderen om vanaf te werken en we hebben nu ook krachtige tools in Chrome, Internet Explorer, Safari en Opera.
Voor dit artikel ga ik me richten op de ontwikkelaarstools van Internet Explorer en de functionaliteit die het biedt. De functionaliteit die ik zal bespreken, zal zeer bekend zijn bij iedereen die een browsergebaseerde debugger gebruikt, maar ik wil de aandacht vestigen op de hulpmiddelen van Internet Explorer om er zeker van te zijn dat er een goed begrip is van wat daadwerkelijk beschikbaar is.
Laat ik beginnen met toe te geven dat ik weet dat Internet Explorer de browser is die je graag haat. Ik snap het. Het feit is dat het een belangrijke browser is die belangrijk is voor veel sitebezoekers en dat betekent dat je het zult targeten en dat je ook eerder of later code moet debuggen. Wat verrassend is, is hoeveel ontwikkelaars niet weten dat IE wordt geleverd met ontwikkelaarstools of erger nog dat ze denken dat ze de Internet Explorer Developer Toolbar nog moeten downloaden.
De ontwikkelaarshulpprogramma's worden gewoonlijk de "F12 Developer Tools" genoemd, omdat het indrukken van de "F12" -toets op uw toetsenbord ze opent terwijl u zich in Internet Explorer bevindt (interessant genoeg, als u op F12 drukt, worden ook Firebug en de Chrome-ontwikkelaarstools gestart).
De ontwikkelaarstools zijn ook toegankelijk via het menu "Tools" onder het label "F12 developer tools".
Het belangrijkste dat ik moest benadrukken is dat ze zijn opgenomen in Internet Explorer (en sinds IE8 zijn), dus er is geen noodzaak om een plug-in te installeren om dev-tools te krijgen. Ook, terwijl ze de "F12 Developer Tools" worden genoemd, zal ik voor de doeleinden van dit artikel de "F12" weglaten en me een aantal toetsaanslagen besparen.
De ontwikkelaarshulpmiddelen bieden ontwikkelaars en ontwerpers een uitgebreide set hulpprogramma's waarmee ze veel van de gebruikelijke gevallen van foutopsporing en inspectie kunnen aanpakken waarmee ze tijdens hun werk te maken krijgen. Mogelijkheden zoals:
Dit zijn functies die tegenwoordig paraat zijn en essentieel zijn om te bepalen wat uw pagina's scheelt. Bovendien bieden de ontwikkelaarstools de mogelijkheid om uw site in verschillende versies van Internet Explorer te testen door de browsermodus te wijzigen:
Testen op meerdere versies van IE is van oudsher een koninklijke pijn in de tuckus; Deze functie is bedoeld om de wrijving te verminderen en ervoor te zorgen dat uw sites over de verschillende versies van IE werken.
Extra mogelijkheden omvatten zaken als:
Ik concentreer me veel op het helpen van ontwikkelaars om op standaarden gebaseerde ontwikkelingstechnieken te gebruiken om ervoor te zorgen dat hun sites geweldig werken op IE. Zoals je je wel kunt voorstellen, besteed ik veel tijd aan het analyseren van code, vooral JavaScript. Dus, om een vreemde fout op te sporen, heb ik een JS-foutopsporing nodig waarmee ik de code op verschillende manieren kan analyseren.
Een van de belangrijkste functies voor mij is het vermogen om JavaScript te verfraaien. Ik ken geen enkele ontwikkelaar die zijn productiecode tegenwoordig niet verkleint. En dat is absoluut het juiste ding om te doen, maar wanneer ik iets op een productiesite moet debuggen - vooral waar ik geen toegang tot de broncode heb - is het in staat zijn om de code mooier te maken van onschatbare waarde. Ja, er zijn online tools zoals JS Beautify die dat kunnen, maar het zou me dwingen om code erin te kopiëren en in te plakken om de code te verbeteren. Als ik deze mogelijkheid heb laten inbouwen, kost me dat veel tijd. Stel dat ik bijvoorbeeld naar een verkleinde versie van jQuery kijk:
Via het toolpictogram kan ik de "Format JavaScript" -optie gebruiken, die de verkorte jQuery-broncode zal verduidelijken en me aanzienlijk leesbaardere code zal geven:
Zoals je kunt zien in de afbeelding hierboven, is de code zeker gemakkelijker om mee te werken. Het andere leuke aan deze functie is dat als je het eenmaal hebt ingeschakeld, het je JS-bestanden tijdens je sessie blijft opschrijven.
Een waarschuwing is dat het deobfuscation-proces jQuery niet terugzet naar de oorspronkelijke bron. Geen enkele dienst waarvan ik weet dat kan, maar bronkaarten zullen dat probleem in de toekomst oplossen. Lees het artikel over bronkaarten van Sayanee Basu dat ik zojuist heb gekoppeld voor een geweldige intro over het onderwerp.
Zodra de code leesbaar is, wordt het gemakkelijker om de stroom van de bron te bepalen. Op dit punt kan ik breekpunten op logische plekken in de code instellen om problemen te isoleren terwijl u er doorheen gaat. En natuurlijk kunt u meerdere onderbrekingspunten instellen voor meerdere bronbestanden.
U kunt ook voorwaardelijke breekpunten opgeven waarmee u de codestroom kunt verbreken op basis van een specifieke waarde.
Zoals verwacht, kunt u in, uit of over welke methode dan ook stappen om de gedetailleerde controle te bieden die u nodig hebt om code te bekijken en ook geen kostbare tijd te verspillen. Het is belangrijk om op te merken dat wanneer u uw code doorloopt, er een oproepstapel toegankelijk is waarmee u kunt zien hoe u bij een specifieke methode of een JavaScript-bestand bent terechtgekomen en kunt terugkeren naar die methode of dit bestand om de code te inspecteren:
Bovendien helpt het om onverwachte codepaden te isoleren die mogelijk het probleempunt zijn.
Informatie is essentieel om te begrijpen wat er gebeurt en de ontwikkelaarstools werken om u de opties te geven om te definiëren wat u wilt zien. Dus samen met de oproepstack krijgt u informatie over variabelen in de huidige scope via het tabblad "Locals":
Of u kunt uw eigen watchlist definiëren (via het tabblad Watch), zodat u kunt bijhouden hoe variabele waarden dynamisch veranderen op basis van code-uitvoering. Het mooie is dat de hulpprogramma's u de flexibiliteit bieden om de waarden in beide lijsten te wijzigen, zodat u kunt zien hoe deze uw toepassing beïnvloedt.
En laten we de console niet vergeten. Geen debugger zou nuttig zijn zonder een console om fouten uit te voeren en u in staat te stellen interactief debuggen:
Op de console worden veelvoorkomende fouten weergegeven die aan uw pagina zijn gekoppeld, waaronder JavaScript en markeringsproblemen. U kunt ook opdrachten invoeren om met de pagina samen te werken en het console-object in uw JavaScript-code gebruiken om berichten weer te geven op de console.
Al het bovenstaande is geweldig en zeker waardevol. Een vaak over het hoofd gezien aspect van foutopsporing is de prestaties van de code. Zelden praat ik met ontwikkelaars die vermelden hoe zij hun code hebben geëvalueerd om knelpunten in trage werkwijzen vast te stellen, vooral van frameworks van derden.
De ontwikkelaarstools bieden u een JavaScript-profiler waarmee u uw code kunt analyseren terwijl deze wordt uitgevoerd, en die een schat aan informatie biedt die u kunt gebruiken om uw code te optimaliseren.
Sleutelbits zijn onder meer:
Gewapend met deze informatie kunt u bepalen of uw methode moet worden aangepast, of een externe bibliotheek problemen veroorzaakt of dat een browserspecifieke methode een knelpunt is. Voor mij zou de combinatie van Inclusief en Exclusieve Tijd belangrijke meetgegevens zijn om te evalueren, omdat het zou vertellen hoe lang een specifieke methode duurde, inclusief de tijd die het kind kostte of externe methoden om te voltooien. Vanaf daar kan ik verder gaan boren om de probleemcode op te sporen.
Ik zal het nooit vergeten toen ik mijn eerste Ajax-verzoek codeerde. Het was zo'n klein beetje code, maar het voelde echt magisch (ja ik ben zo raar). Het uitvoeren van dynamische DOM-updates op basis van het terughalen van gegevens van een HTTP-achtergrondverzoek was ongelooflijk cool en een krachtige mogelijkheid. Ik zal ook nooit de eerste keer vergeten dat ik probeerde een resultaat terug te sturen dat uiteindelijk een fout veroorzaakte en mij met stomheid geslagen had. Gelukkig had Firebug een inspecteur voor netwerkaanvragen waarmee ik kon controleren wat mijn server-side code retourneerde en hoe ik het kon oplossen.
Het tabblad 'Netwerk' in de ontwikkelaarshulpprogramma's biedt deze functionaliteit: het toont verkeer gerelateerd aan de pagina die wordt geladen en geeft details weer die u kunt gebruiken om problemen met het netwerk op te lossen.
Door naar het vastgelegde verkeer te kijken, ziet u het type verzoek dat wordt gedaan (bijvoorbeeld: een GET of POST), of het is geslaagd en hoe lang het duurde om te voltooien. De netwerkinspecteur geeft ook belangrijke details over het type item dat u hebt aangevraagd (bijvoorbeeld: CSS of een afbeelding) en welk type code het verzoek heeft gestart. Dit wordt allemaal gegeven in een overzichtsweergave met snelle details over de verzoeken.
Door te kiezen voor gedetailleerde weergave, kunt u gedetailleerde informatie over een specifiek verzoek verzamelen. Door te kunnen kijken naar het antwoordorgaan kon ik het probleem oplossen dat ik eerder noemde met mijn XHR-oproep. Maar dat is slechts een klein deel van de totale gegevens die u krijgt door naar de detailweergave te gaan. Afgezien daarvan krijg je de headers van het verzoek (request & response), cookies die zijn verzonden en zelfs timinginformatie die je vertelt hoe lang het verzoek duurde.
De timingweergave in de overzichtsweergave is erg belangrijk omdat het een duidelijk beeld geeft van het lange verzoek dat een probleem kan vormen.
Ik zal de eerste zijn die zegt dat ik HAAT testen voor meerdere versies van Internet Explorer. Ik ben vooral geïrriteerd door de oudere versies en ik zou blij zijn als ontwikkelaars zich eenvoudig zorgen zouden kunnen maken over IE9 en IE10. Maar het is wat het is en er zijn een paar manieren om dit aan te pakken. U kunt meerdere virtuele machines gebruiken voor elke versie van IE die u target. U zou Browserstack.com kunnen gebruiken om IE-versies in de browser te virtualiseren. U kunt ook de browsermodusschakelmogelijkheden van ontwikkelaarstools gebruiken om IE10 IE7 te laten emuleren door IE10.
Met deze tool kunt u de manier wijzigen waarop IE een pagina rendert, zodat deze de functionaliteit van een specifieke versie emuleert, waardoor u zeker weet dat uw site voor die versie zou werken. Hiermee kunt u niet alleen de browsermodus opgeven (die functiesteun bepaalt), maar ook de documentmodus (die specificeert hoe een pagina wordt geïnterpreteerd). Dit geeft u veel flexibiliteit om verschillende versies van IE vanuit een enkele browser te testen. Merk op dat het IE-team zijn best doet om versies te emuleren. Als u volledig-proof testen wilt, dan zijn VM's de juiste keuze. Ik begin meestal met de laatste optie omdat het verreweg het gemakkelijkst is en de weergave heel dicht bij het daadwerkelijk gebruiken van een specifieke native versie van IE is.
Het inspecteren van markeringen is een van de meest voorkomende taken voor elke webprofessional. Het is geweldig om onder de motorkap te kunnen kijken hoe iets is gebouwd zonder een "Beeld-> Bron" te hoeven doen. Het tabblad "HTML" in de ontwikkelaarshulpprogramma's toont alle elementen op een specifieke pagina samen met hun gerelateerde stijlen en attributen. Hiermee kunt u waarden in realtime bekijken en bijwerken en onmiddellijk feedback krijgen. U kunt bijvoorbeeld op een aline-element klikken en het kan worden bewerkt, zodat u de tekst kunt wijzigen en de resultaten onmiddellijk kunt zien. Hetzelfde geldt voor de stijlen en attributen van dat element.
Attributen kunnen ook inline worden toegevoegd door met de rechtermuisknop op een element te klikken en 'Attribuut toevoegen' te kiezen in het contextmenu of door het tabblad 'Attributen' te selecteren en toe te voegen aan de lijst. De volgende afbeelding laat zien hoe ik een kleur- en lettertype-kenmerk heb toegevoegd aan het nadrukelement, en deze weergeeft als inline-stijlen in de markup- en individuele attribuutlijnen op het tabblad Kenmerken:
De opmaak van de pagina wordt weergegeven in een boomstructuurstijl, zodat u een bovenaanzicht van de DOM-structuur ziet en elementen kunt uitvouwen om hun kinderen te zien.
CSS heeft ook een eigen tabblad, maar het is bedoeld om globale stijlen te beheren die meestal in stylesheets worden opgeslagen. Door een stylesheet te selecteren, worden alle gedefinieerde selectors, regels en eigenschappen getoond en kunt u ze naar wens aanpassen. In dit geval verschoof het eenvoudig verwijderen van de eigenschap text-align de tekst dynamisch naar links:
Het is niet alleen het bewerken van bestaande regels. U kunt ook nieuwe selectors, regels of eigenschappen toevoegen:
De belangrijkste reden waarom ik dit stuk wilde schrijven is omdat ik oprecht verrast was door het aantal ontwikkelaars dat ik ontmoette, die een misvatting over de F12 Developer Tools hadden - of niet wisten dat ze zelfs bestonden! Ik hoop dat het ontwikkelaars helpt een idee te krijgen van wat er beschikbaar is en hun probleemoplossing een beetje gemakkelijker maakt.
Ik hoop ook dat het feedback genereert voor toekomstige functies die ontwikkelaars nodig hebben. Hoewel de bestaande functionaliteit goed is, weet ik zeker dat er een aantal nieuwe dingen zijn die jij, de lezers, essentieel vinden voor je foutopsporingservaring. Laat me weten wat die zijn!
Accentsconagua