Share
Odio il debug e non ho mai incontrato nessuno sviluppatore che abbia sostenuto il contrario. È un ostacolo dover passare attraverso il codice e capire perché è rotto. E, cosa più importante, è un'ammissione che il mio codice è rotto e che non sono infallibile! Eresia, dico io!
Seriamente però, i bug sono semplicemente una parte naturale del processo di sviluppo del web, e, mentre possiamo odiarli, dobbiamo certamente affrontarli. Gli sviluppatori front-end non hanno sempre avuto ricchi strumenti di debug come altre piattaforme e linguaggi. Nei bei 'vecchi tempi, mettere in guardia() era tuo amico e un metodo importante (scusate il gioco di parole) per la risoluzione dei problemi del codice. Inoltre, il debug del codice lato client presenta una serie di sfide uniche a causa della varietà di tecnologie in gioco. Se ci pensi, il debug delle pagine, in particolare quelle dinamiche, coinvolge così tante parti in movimento che potrebbero influenzare il rendering. Hai il Document Object Model (DOM), JavaScript, CSS, traffico di rete, intestazioni HTTP e molte altre tecnologie che funzionano tutte per produrre una pagina e in molti casi interagiscono e si influenzano a vicenda.
Fortunatamente, i tempi sono cambiati e tutti i principali browser hanno strumenti integrati che aumentano notevolmente le funzionalità di risoluzione dei problemi per gli sviluppatori. Diamo molto credito a Joe Hewitt per aver spinto in avanti gli strumenti. Ha creato Firebug nel 2006. A mio parere, ha dato il via a ciò che i veri strumenti del browser dovrebbero essere.
Da allora, abbiamo visto Firebug evolversi enormemente e servire da base di partenza per gli altri e ora disponiamo di potenti strumenti anche in Chrome, Internet Explorer, Safari e Opera.
Per questo articolo, mi concentrerò sugli Strumenti per sviluppatori di Internet Explorer e sulla funzionalità che fornisce. La funzionalità che discuterò sarà molto familiare a chiunque abbia utilizzato un debugger basato su browser, ma voglio focalizzare l'attenzione sugli strumenti di Internet Explorer per garantire che ci sia una buona comprensione di ciò che è effettivamente disponibile.
Permettetemi di iniziare ammettendo che so che IE è il browser che ami odiare. Capisco. Il fatto è che è un browser importante che è importante per molti visitatori del sito e questo significa che lo bersaglierai e che dovrai eseguire il debug del codice prima o poi. Ciò che sorprende è il modo in cui molti sviluppatori non sanno che IE viene fornito con strumenti di sviluppo o peggio che pensano che sia ancora necessario scaricare la barra degli strumenti di sviluppo di Internet Explorer.
Gli strumenti per sviluppatori sono comunemente chiamati "Strumenti di sviluppo F12" perché premendo il tasto "F12" sulla tastiera si apriranno mentre si è in Internet Explorer (in modo abbastanza interessante, premendo F12 si avvia Firebug e gli Strumenti per sviluppatori di Chrome).
Gli strumenti di sviluppo sono accessibili anche tramite il menu "Strumenti" sotto l'etichetta "Strumenti di sviluppo F12".
La cosa fondamentale che dovevo sottolineare è che sono inclusi in Internet Explorer (e sono passati da IE8) quindi non è necessario installare un plug-in per ottenere gli strumenti di sviluppo. Inoltre, mentre vengono chiamati "Strumenti di sviluppo F12", per gli scopi di questo articolo, ho intenzione di rilasciare "F12" e salvarmi alcune sequenze di tasti.
Gli strumenti di sviluppo forniscono agli sviluppatori e ai progettisti un ricco set di strumenti in grado di affrontare molti dei casi di utilizzo di debug e ispezione comuni che dovranno affrontare durante il loro lavoro. Funzionalità come:
Queste sono le caratteristiche che sono fondamentali per il corso al giorno d'oggi ed essenziali per determinare ciò che affligge le tue pagine. Inoltre, gli strumenti per sviluppatori offrono la possibilità di testare il tuo sito in diverse versioni di Internet Explorer modificando la modalità browser:
Il test per più versioni di IE è stato tradizionalmente un dolore reale nel tuckus; questa funzione mira a ridurre l'attrito di garantire che i tuoi siti funzionino attraverso le varie versioni di IE.
Altre funzionalità includono cose come:
Mi concentro molto sull'aiutare gli sviluppatori a utilizzare tecniche di sviluppo basate su standard per garantire che i loro siti funzionino alla perfezione su Internet Explorer. Come puoi immaginare, passo molto tempo ad analizzare il codice, specialmente JavaScript. Quindi, per rintracciare un bug strano, ho bisogno di un debugger JS che possa permettermi di analizzare il codice in vari modi.
Una delle caratteristiche più importanti per me è la capacità di pretrattare JavaScript. Non conosco nessuno sviluppatore che non stia minimizzando il loro codice di produzione al giorno d'oggi. E questa è assolutamente la cosa giusta da fare, ma, quando ho bisogno di eseguire il debug di qualcosa in un sito di produzione - specialmente dove non ho accesso al codice sorgente - essere in grado di stimolare il codice è inestimabile. Sì, ci sono strumenti online come JS Beautify che possono farlo ma mi costringono a copiare e incollare il codice al suo interno per deoffuscare il codice. Avere questa capacità integrata mi fa risparmiare un sacco di tempo. Ad esempio, supponiamo che sto guardando una versione minificata di jQuery:
Tramite l'icona dello strumento, posso accedere all'opzione "Formato JavaScript" che deobfuscing il codice sorgente minisito di jQuery e fornirmi un codice sostanzialmente più leggibile:
Come puoi vedere nell'immagine sopra, il codice è sicuramente più facile da usare. L'altra cosa interessante di questa funzione è che, una volta abilitato, continuerà a deoffuscare i file JS durante la sessione.
Un avvertimento è che il processo di deobfuscation non ripristinerà jQuery alla sua fonte originale. Nessun servizio che io conosca può farlo, ma le mappe sorgente risolveranno il problema in futuro. Assicurati di leggere l'articolo sulle mappe sorgente di Sayanee Basu a cui mi sono appena collegato per una grande introduzione sull'argomento.
Una volta che il codice è leggibile, rende più facile determinare il flusso della sorgente. A questo punto, posso impostare i punti di interruzione nei punti logici del codice per isolare i problemi mentre lo attraversi. E, naturalmente, è possibile impostare più punti di interruzione su più file sorgente.
È inoltre possibile specificare punti di interruzione condizionali che consentono di interrompere il flusso di codice in base a un valore specifico.
Come previsto, è possibile intervenire, uscire da qualsiasi metodo che si sta utilizzando per fornire il controllo granulare necessario per controllare il codice e inoltre non perdere tempo prezioso. Ciò che è importante notare è che mentre stai attraversando il tuo codice, è disponibile uno stack di chiamate che ti consente di vedere come hai ottenuto un metodo specifico o un file JavaScript e tornare a quel metodo o file per ispezionare il codice:
Inoltre, aiuta a isolare percorsi di codice imprevisti che potrebbero essere il punto problematico.
Le informazioni sono fondamentali per capire cosa sta succedendo e gli strumenti di sviluppo funzionano per darti le opzioni per definire ciò che vuoi vedere. Quindi, insieme allo stack delle chiamate, ottieni informazioni sulle variabili nell'ambito corrente tramite la scheda "Locali":
In alternativa, è possibile definire la propria watch list (tramite la scheda Watch) in modo da poter tenere traccia di come i valori delle variabili cambiano dinamicamente in base all'esecuzione del codice. Il bello è che gli strumenti ti danno la flessibilità di cambiare i valori in entrambi gli elenchi in modo da poter vedere come influenza la tua applicazione.
E non dimentichiamo la console. Nessun debugger sarebbe utile senza una console per generare errori e consentire di eseguire il debug in modo interattivo:
La console mostrerà gli errori comuni associati alla tua pagina, compresi i problemi relativi a JavaScript e al markup. È inoltre possibile immettere comandi per interagire con la pagina e utilizzare l'oggetto console all'interno del codice JavaScript per visualizzare i messaggi sulla console.
Tutto quanto sopra è grande e sicuramente prezioso. Un aspetto spesso trascurato del debugging è rappresentato dalle prestazioni del codice. Raramente parlo con gli sviluppatori che menzionano in che modo hanno valutato il loro codice per determinare i colli di bottiglia nei metodi a esecuzione rallentata, specialmente da framework di terze parti.
Gli strumenti di sviluppo ti forniscono un profiler JavaScript che analizzerà il tuo codice mentre viene eseguito, fornendo una grande quantità di informazioni da utilizzare per ottimizzare il tuo codice.
I bit chiave includono:
Dotata di queste informazioni, è possibile determinare se il metodo deve essere refactored, se una libreria di terze parti sta causando problemi o se un metodo specifico del browser è un collo di bottiglia. Per me, la combinazione di Tempo Inclusivo ed Esclusivo sarebbe una metrica importante da valutare perché mi indicherà quanto tempo impiega un metodo specifico per eseguire, compreso il tempo necessario per completare i metodi figlio o esterno. Da lì, posso iniziare a perforare ulteriormente per inchiodare il codice problema.
Non dimenticherò mai quando ho codificato la mia prima richiesta Ajax. Era un po 'di codice ma si sentiva onestamente magico (sì, sono strano in quel modo). Effettuare aggiornamenti DOM dinamici basati sul recupero dei dati da una richiesta HTTP in background era incredibilmente interessante e potente. Inoltre non dimenticherò mai la prima volta che ho provato a inviare un risultato che ha finito per generare un errore e lasciandomi interdetto. Per fortuna, Firebug aveva un ispettore delle richieste di rete che mi permetteva di controllare quale fosse il mio codice sul lato server restituito e di risolverlo.
La scheda "Rete" negli strumenti per sviluppatori fornisce questa funzionalità: mostra il traffico relativo alla pagina caricata ed espone i dettagli che è possibile utilizzare per risolvere i problemi relativi alla rete.
Osservando il traffico catturato è possibile visualizzare il tipo di richiesta effettuata (ad es. Un GET o POST), se ha avuto successo e quanto tempo è necessario per completare. L'ispettore di rete fornisce anche dettagli importanti sul tipo di risorsa richiesta (ad esempio: CSS o un'immagine) e quale tipo di codice ha avviato la richiesta. Tutto ciò è fornito in una visualizzazione di riepilogo che offre dettagli rapidi sulle richieste.
Scegliendo di entrare in una vista dettagliata, sei in grado di raccogliere informazioni granulari su una richiesta specifica. Essere in grado di guardare il corpo della risposta è stato ciò che mi ha permesso di risolvere il problema che ho menzionato prima con la mia chiamata XHR. Ma questo è solo un po 'dei dati complessivi che ottieni passando alla visualizzazione dei dettagli. Oltre a ciò ottieni le intestazioni della richiesta (richiesta e risposta), i cookie che sono stati inviati e anche le informazioni sui tempi che ti dicono quanto tempo è stato richiesto.
La visualizzazione dei tempi nella vista di riepilogo è molto importante perché è una chiara rappresentazione di quale richiesta è lunga e potrebbe essere un problema.
Sarò il primo a dire che I HATE esegue il test per più versioni di Internet Explorer. Sono principalmente seccato con le versioni precedenti e sarei felice se gli sviluppatori potessero semplicemente preoccuparsi di IE9 e IE10. Ma è quello che è e ci sono un paio di modi per affrontare questo. Potresti utilizzare più macchine virtuali per ogni versione di IE che hai scelto come target. È possibile utilizzare Browserstack.com per virtualizzare le versioni di IE nel browser. In alternativa, è possibile utilizzare la funzionalità di cambio modalità browser degli strumenti di sviluppo per fare in modo che IE10 emuli IE7 tramite IE10.
Questo strumento consente di modificare il modo in cui IE esegue il rendering di una pagina in modo che emuli le funzionalità di una versione specifica, garantendo in tal modo che il sito possa funzionare per quella versione. Non solo ti consente di specificare la modalità browser (che determina il supporto delle funzionalità) ma anche la modalità documento (che specifica come verrà interpretata una pagina). Questo ti dà un sacco di flessibilità per testare varie versioni di IE da un singolo browser. Basta notare che il team di IE fa del suo meglio per emulare le versioni. Se vuoi test a prova di tutto, allora le VM sono la strada da percorrere. In genere inizio con l'ultima opzione perché è di gran lunga la più semplice e il rendering è molto vicino a utilizzare effettivamente una versione nativa specifica di IE.
L'ispezione del markup è uno dei compiti più comuni per qualsiasi professionista del web. È bello essere in grado di guardare sotto il cofano su come qualcosa è stato creato senza dover fare un "View-> Source". La scheda "HTML" negli strumenti di sviluppo mostra tutti gli elementi su una pagina specifica con i relativi stili correlati e attributi. Ciò consente di ispezionare e aggiornare i valori in tempo reale e ottenere un feedback immediato. Puoi fare clic su, ad esempio, su un elemento di paragrafo e diventa modificabile in modo da poter modificare il testo e visualizzare immediatamente i risultati. Lo stesso vale per gli stili e gli attributi di quell'elemento.
Gli attributi possono anche essere aggiunti in linea facendo clic con il pulsante destro del mouse su un elemento e scegliendo "Aggiungi attributo" dal menu di scelta rapida o selezionando la scheda "Attributi" e aggiungendola all'elenco. L'immagine seguente mostra come ho aggiunto un attributo color e font all'elemento enfasi, visualizzandoli come stili in linea nel markup e nelle singole righe di attributo nella scheda Attributi:
Il markup della pagina è rappresentato in stile treeview in modo da visualizzare una vista dall'alto dell'albero DOM e sono in grado di espandere gli elementi per vedere i propri figli.
Anche i CSS hanno una propria scheda, tuttavia, è pensata per gestire gli stili globali generalmente memorizzati in fogli di stile. La selezione di un foglio di stile mostra tutti i selettori, le regole e le proprietà definite e ti consente di modificarle a tuo piacimento. In questo caso, semplicemente deselezionando la proprietà allineamento del testo, il testo è stato spostato dinamicamente a sinistra:
Non sta solo modificando le regole esistenti. Puoi anche aggiungere nuovi selettori, regole o proprietà:
La ragione principale per cui volevo scrivere questo pezzo è perché sono stato sinceramente sorpreso da quanti sviluppatori ho incontrato, che avevano un'idea sbagliata riguardo gli Strumenti per gli sviluppatori di F12 - o non sapevo nemmeno che esistessero! La mia speranza è che aiuti gli sviluppatori a capire cosa è disponibile e rende la loro risoluzione un po 'più semplice.
Spero anche che generi feedback per le funzionalità future di cui gli sviluppatori hanno bisogno. Mentre la funzionalità esistente è buona, sono sicuro che ci sono un certo numero di cose nuove che tu, i lettori, troveresti essenziale per la tua esperienza di debug. Fammi sapere cosa sono!
Accentsconagua