El Mòdul 7 va acabar amb un diagnòstic incòmode: Nómada Tasques té sis capes, catorze mòduls, dues fonts de dades i un canal en temps real, i l'única manera de saber si alguna cosa funciona és obrir-la i provar-la a mà. Aquesta lliçó ataca la primera meitat del problema —quan ja saps que alguna cosa falla, com esbrines per què?— i ho fa amb un canvi de mentalitat: depurar no és endevinar, és un procediment. Aprendràs el cicle reproduir → aïllar → formular hipòtesis → comprovar → corregir → prevenir, la tècnica de bisecció que redueix a la meitat el terreny sospitós a cada pas, la consola sencera (que és molt més que console.log), el depurador de les DevTools amb les seves sis classes de punts d'interrupció, la lectura d'una pila de crides asíncrona, els source maps, i els panells de xarxa i emmagatzematge. I acabaràs resolent tres errors reals de Nómada Tasques pas a pas, amb el mètode al davant.

1. Per què depurar per intuïció no escala
2. El mètode: sis passos
3. Bisecció: partir el problema per la meitat
4. La consola més enllà de console.log
5. El truc de les claus: console.log({variable})
6. La sentència debugger i el primer punt d'interrupció
7. Els sis tipus de punt d'interrupció
8. Executar pas a pas: step over, into i out
9. Els panells Scope, Watch i Call Stack
10. Llegir un stack trace i «Pause on exceptions»
11. Depurar codi asíncron
12. Source maps: per què producció és il·legible sense ells
13. Depurar la xarxa: el panell Network
14. Depurar l'emmagatzematge: el panell Application
15. Depurar en un mòbil real
16. Cas 1: la tasca que no canvia d'estat
17. Cas 2: el filtre que perd tasques en recarregar
18. Cas 3: el comptador d'hores descompensat
19. El bug que no es reprodueix
20. Errors Habituals i Consells
21. Exercicis
22. Conclusió

La manera com gairebé tothom comença a depurar és aquesta: llegir el codi on creu que hi ha l'error, veure alguna cosa estranya, canviar-la, recarregar, mirar si continua fallant. Repetir. Això s'anomena depuració per canvi aleatori, i té tres problemes greus:

• No convergeix. Cada canvi modifica el sistema, així que l'error pot desaparèixer per una raó diferent de la que creies, i reaparèixer una setmana després.
• Introdueix errors nous. Un if afegit "per si de cas" que tapa el símptoma deixa el sistema amb dos problemes en lloc d'un.
• No ensenya res. Quan l'error se'n va, no saps per què se n'ha anat, i per tant no pots evitar el següent de la mateixa família.

L'alternativa és tractar l'error com el que és: una diferència entre el que el programa fa i el que creus que fa. Depurar és localitzar el punt exacte on el teu model mental i la realitat se separen. I per a això existeix un procediment.

Una idea que convé interioritzar des d'ara: el 90 % del temps de depuració es gasta a localitzar l'error, no a arreglar-lo. La correcció sol ser una línia. Per això tot el mètode està orientat a localitzar de pressa, no a escriure de pressa.

Els sis passos, amb el que significa cadascun a la pràctica:

El pas 6 és el que gairebé tothom es salta, i és el que converteix una tarda perduda en un actiu permanent. Encara no saps escriure aquestes proves —això arriba a Proves Unitàries amb Jest—, però en aquesta lliçó ja deixaràs escrita la comprovació que hauria d'existir per a cada error. Quan arribis a 08-03 tindràs tres proves esperant-te.

Una regla d'or del pas 3: una hipòtesi que no es pot demostrar falsa no és una hipòtesi. «Crec que hi ha alguna cosa estranya al filtre» no serveix. «Crec que estat.filtres.responsable val 'Iván' quan hauria de valer null» sí que serveix, perquè una sola ullada la resol.

Quan l'error és en algun punt d'un recorregut llarg —el clic entra per controlador.js, passa per tauler.js, torna per tauler-vista.js i acaba a repositori-local.js—, buscar llegint és lent. La tècnica correcta és la bisecció: triar un punt intermedi del recorregut, comprovar si allà les dades ja estan malament, i descartar la meitat corresponent.

Si la dada ja està malament al punt mitjà (C), l'error és entre A i C. Si està bé, és entre C i E. Cada comprovació divideix el terreny entre dos. Amb quatre comprovacions cobreixes un recorregut de setze passos.

La bisecció s'aplica a tres dimensions diferents, i convé conèixer-les totes tres:

• Al flux de dades, com acabes de veure: comprovar en punts intermedis del camí.
• Al temps, amb git bisect: si l'aplicació funcionava fa trenta commits i ara no, Git pot buscar en binari el commit culpable en cinc passos.

• Al codi, comentant la meitat: si desactives connectarFormulari i l'error desapareix, ja saps de quin costat mirar. És la versió més tosca, però en una interfície amb molts oients és sorprenentment eficaç.

console.log és una eina legítima —qui digui que un professional no la fa servir mai, menteix—, però l'objecte console té una dotzena de mètodes que resolen millor problemes concrets. Aquests són els que es fan servir de debò:

Quatre d'ells mereixen un exemple complet, perquè canvien de debò la manera de treballar.

console.table és la diferència entre entendre un array de sis objectes d'una ullada i no entendre'l. Accepta un segon argument amb les columnes que vols:

Les columnes de la taula de DevTools s'ordenen en prémer la capçalera. Ordenar per estat i comptar és més ràpid que qualsevol filter escrit a mà.

console.count respon a la pregunta més freqüent d'una interfície: per què això s'executa tres vegades?

Aquest resultat ja és un diagnòstic: hi ha tres oients diferents reaccionant al mateix esdeveniment, o l'esdeveniment fa bombolla i es gestiona dues vegades. Sense count, aquest error es manifesta només com a "va una mica lent".

console.assert és una afirmació que només parla quan s'incompleix. És perfecta per vigilar invariants coneguts, com els números canònics del backlog:

console.group converteix un abocador de línies en un arbre plegable:

Amb console.groupCollapsed() el grup apareix ja plegat, que és el que vols quan registres una cosa que passa moltes vegades.

Aquest petit truc estalvia més temps del que sembla. Compara:

En envoltar les variables amb claus fas servir l'abreviatura de propietats d'ES6 (04-01): { responsable } és { responsable: responsable }. El resultat és un objecte on cada valor ve etiquetat amb el nom de la seva variable, i a més es mostra plegable i inspeccionable a la consola. Adopta'l com a norma: no costa res i elimina la classe sencera d'errors de "estic llegint el registre d'una altra variable".

Dos complements del mateix estil:

copy() no és JavaScript estàndard: és una de les funcions d'utilitat de la consola de DevTools, juntament amb $0 (l'últim element seleccionat a l'inspector), $_ (l'últim resultat) i $$('selector') (un querySelectorAll que retorna un array de debò). Només funcionen escrites a mà a la consola, mai al teu codi.

console.log et diu el valor del que se't va acudir imprimir. El depurador et deixa mirar-ho tot, en el moment exacte, i a més seguir avançant. La diferència de potència és enorme.

La manera més ràpida d'entrar al depurador és la paraula clau debugger:

Amb les DevTools obertes, l'execució es congela en aquesta línia i pots inspeccionar id, nou, this i tota la resta. Amb les DevTools tancades, la sentència no fa res.

debugger té un avantatge (és una línia, funciona sempre, sobreviu a un canvi de fitxer) i un perill seriós: si s'escola a producció, congela l'aplicació a qualsevol que tingui les eines obertes. A la lliçó següent configuraràs una regla d'ESLint (no-debugger) que impedeix exactament això.

L'habitual, però, és no tocar el codi: al panell Sources (Chrome/Edge) o Depurador (Firefox), obres el fitxer i prems el número de línia. Apareix un marcador blau: aquest és un punt d'interrupció normal.

Aquí és on el depurador deixa de ser "un console.log més elegant" i es converteix en una altra cosa. Aquests són els sis tipus i quan fer servir cadascun:

El condicional és el que més temps estalvia en aquest projecte. La funció pintarTargeta s'executa sis vegades per render; aturar-se a les sis és inútil. Amb la condició tasca.id === 3 t'atures només a la que t'interessa:

La condició és una expressió JavaScript normal avaluada a l'àmbit d'aquella línia. Truc poc conegut: si escrius console.count('pas') com a condició, no s'atura mai (perquè retorna undefined, que és fals) però sí que executa el comptador. Això és exactament el que fa un logpoint, que és la versió oficial de la idea.

El logpoint mereix un paràgraf propi perquè substitueix el 80 % dels console.log que la gent escriu:

Avantatges respecte a escriure el console.log al fitxer: no modifiques el codi, no cal recarregar, no hi ha risc d'oblidar-lo en un commit, i funciona igual sobre codi de tercers o minificat. Quan acabes, esborres el punt i no queda rastre.

Els punts per esdeveniment resolen la pregunta "quin codi s'executa quan premo aquest botó?" en una aplicació que no coneixes. Actives Mouse → click, prems el botó, i el depurador et deixa dins del gestor, amb la pila de crides completa. A Nómada Tasques això et portaria directament a l'oient delegat de js/vista/controlador.js, amb esdeveniment.target ja disponible.

Els punts per petició (XHR/fetch Breakpoints) s'aturen just abans que surti una petició la URL de la qual contingui el text que indiquis —per exemple tasques—. Serveixen per inspeccionar el body que estàs a punt d'enviar abans que el servidor el rebutgi, i per descobrir qui dispara una petició inesperada: la pila de crides t'ho diu.

Els punts per canvi del DOM són la solució al clàssic "aquesta classe es treu sola". A l'inspector, clic dret sobre el node → Break on → attribute modifications, i el depurador s'atura a la línia de JavaScript que modifica aquell atribut. Hi ha tres variants:

Un cop aturat, controles l'execució amb quatre botons. Entendre'ls bé és el que separa fer servir el depurador de patir-lo:

La regla pràctica és senzilla:

• Fes servir step over per defecte. Vas llegint el flux de la funció actual sense perdre't a les crides.
• Fes servir step into només quan sospitis de la funció que estàs cridant.
• Fes servir step out tan bon punt t'adonis que has entrat on no volies (típicament, dins d'una funció de llibreria).

Amb reconciliar, pintarTargeta i map pel mig, és fàcil acabar vint fotogrames dins de codi aliè. Per evitar-ho existeix Ignore List (abans blackboxing): marques un fitxer o un patró com a ignorat i el depurador no hi entra mai ni el mostra a la pila. Marca-hi les teves dependències i la pila es torna llegible a l'instant.

Quan l'execució està aturada, la meitat dreta del panell és on passa la depuració de debò.

Scope mostra les variables agrupades per àmbit, i és la comprovació empírica de tot el que vas estudiar a 03-04 i 03-05:

Aquest bloc Closure és literalment l'entorn capturat del qual parlava 03-04, llistat amb nom i contingut. Si alguna vegada vas dubtar que els closures existeixen físicament, aquí els tens.

Watch és una llista d'expressions que es reavaluen a cada pas. No estàs limitat a variables: pots vigilar càlculs complets.

Veure horesObertes canviar de 45 a 39 al pas exacte en què passa és una informació impossible d'obtenir amb registres solts.

Call Stack és la pila de crides: qui ha cridat qui fins a arribar aquí. Es llegeix de dalt a baix, del més recent al més antic:

Prement qualsevol fotograma et trasllades a ell amb el seu Scope corresponent, sense perdre l'aturada. És la manera de respondre "amb quins arguments m'han cridat?" quan el problema no és aquí sinó a qui ha cridat.

I una funció poc coneguda i molt útil: Restart frame. Clic dret sobre un fotograma → Restart frame torna a executar aquella funció des del principi, amb els mateixos arguments. Si has passat de llarg la línia interessant amb un F10 de més, no cal recarregar la pàgina i repetir els deu clics que t'hi van portar: reinicies el fotograma i hi tornes a passar. (Amb un advertiment: els efectes secundaris que ja van passar —una petició enviada, un setItem fet— no es desfan.)

Un error sense capturar imprimeix una cosa així:

Es llegeix així:

• Primera línia: tipus d'error i missatge. Aquí ja saps que és una regla R6 incomplerta.
• Línia 1 de la pila: on es va llançar. tasca.js:71:13 = fitxer, línia 71, columna 13.
• Línies següents: la cadena de crides cap enrere. L'última sol ser el punt d'entrada real.
• HTMLUListElement.<anonymous>: una funció anònima adjuntada com a oient a un <ul>. És l'oient delegat de 06-04.

L'error més habitual en llegir una pila és fixar-se només en la primera línia. El lloc on es llança gairebé mai és el lloc on hi ha l'error. Aquí l'error es llança a Tasca, però la causa és a controlador.js:38: algú va intentar reobrir una tasca ja acabada perquè el botó no estava desactivat. La primera línia diu què ha passat; les de sota diuen per què.

«Pause on exceptions» (la icona ⏸ amb el rombe, al panell Sources) fa que el depurador s'aturi en l'instant en què es llança l'error, amb tot el context viu. Té dos nivells:

La segona és la joia amagada. Nómada Tasques captura errors en diversos llocs (el try/catch del formulari, el catch del repositori que descarta dades corrompudes, l'ambReintents). Si un error s'està empassant en un d'aquests catch, activar «pause on caught exceptions» et porta directament al throw original. Això sí: activa-la només mentre investigues, perquè també s'aturarà en errors capturats que són perfectament normals.

Aquí és on el depurador clàssic solia rendir-se. Quan un setTimeout, una promesa o un await reprenen l'execució, la pila de crides original ja s'ha buidat —és exactament el mecanisme del bucle d'esdeveniments que vas estudiar a 05-07—. Sense ajuda, la pila mostraria només això:

Inútil: no diu qui ha demanat aquella petició. Per això els navegadors moderns mantenen piles asíncrones, que cusen el fotograma actual amb el que va programar la tasca:

Ara sí: la petició va néixer d'un clic al controlador. Quatre consells concrets per depurar asincronia en aquest projecte:

• Posa el punt d'interrupció després de l'await, no abans. Abans només veus la promesa pendent; després veus el valor resolt.
• Fes servir un punt condicional a ambReintents amb la condició intent > 1: t'atures només quan alguna cosa ja ha fallat una vegada.
• Al panell Network activa la columna Initiator. Igual que la pila asíncrona, et diu quina línia ha disparat cada petició.
• Compte amb les curses que el mateix depurador provoca. En aturar l'execució cinc segons, un timeout de 8 s pot vèncer. Si sospites d'una condició de cursa, prefereix logpoints a aturades.

Un patró molt útil per a l'asincronia és mesurar on se'n va el temps sense frenar res:

El finally garanteix que el timeEnd s'executi encara que la petició falli; si no, un error deixaria el temporitzador obert i el següent console.time avisaria d'una etiqueta duplicada.

El codi que es desplega no és el que escrius. Un empaquetador l'uneix, el minifica i reanomena les variables, així que un error a producció es veu així:

t, línia 1, columna 24817. Sense informació addicional, aquesta pista no val res.

Un source map és un fitxer (app.4f3a1b.js.map) que conté el diccionari de traducció entre el codi generat i l'original: quina posició del fitxer minificat correspon a quin fitxer, línia, columna i nom de variable del codi font. El navegador el carrega si troba el comentari final:

I aleshores el mateix error es mostra així:

Tres decisions pràctiques sobre source maps:

Tingues present que un source map reconstrueix el teu codi font. Publicar-lo equival a publicar el codi sense minificar. No és un error de seguretat per si mateix —la seguretat mai ha de dependre d'ofuscació—, però és una decisió conscient que cal prendre.

A DevTools, si un source map no carrega, la pestanya Sources mostra un avís a la consola (DevTools failed to load source map). Les tres causes habituals: el .map no es va desplegar, la ruta del comentari final és incorrecta, o el servidor el retorna amb un 404 després d'una configuració de memòria cau agressiva.

El Mòdul 7 va omplir Nómada Tasques de peticions. Quan una falla, el panell Network respon en segons el que el codi no et pot explicar:

• Filtra per Fetch/XHR per veure només les teves peticions, sense imatges ni CSS.
• La columna Status distingeix el que fetch no distingeix: un 200 amb cos buit, un 404, un 500, o (failed) per a una fallada de transport.
• La pestanya Headers mostra el que vas enviar i el que va arribar, inclosa la capçalera Content-Type que fa fallar el demanarJson quan arriba HTML.
• La pestanya Payload ensenya el cos del POST tal com va sortir: aquí es descobreixen els undefined que JSON.stringify elimina en silenci.
• La pestanya Timing desglossa el temps: Stalled, Waiting (TTFB), Content Download. Si el TTFB és de 4 s, no és culpa del teu JavaScript.

Tres funcions del panell que convé conèixer:

Copy as fetch. Clic dret sobre una petició → Copy → Copy as fetch. Enganxa el resultat a la consola i reprodueixes la petició exacta, amb les seves capçaleres, tantes vegades com vulguis. És la millor manera d'aïllar si el problema és al servidor o al teu codi: si la petició copiada funciona a la consola i no a l'aplicació, l'error és teu.

Throttling. El selector de xarxa (No throttling / Slow 4G / Offline) simula connexions lentes. És imprescindible per provar dues coses que vas escriure al Mòdul 7 i que en local no es veuen mai: els estats de "carregant" de 07-03 i el funcionament sense connexió del service worker de 07-05. En una xarxa local d'1 ms, l'estat de càrrega apareix i desapareix abans de renderitzar-se.

Preserve log. Marca aquesta casella si la petició que investigues provoca una navegació o una recàrrega; sense ella, el registre s'esborra i la petició culpable desapareix.

Per a tot el de 07-01 i 07-05, el panell Application és la finestra directa a l'estat persistit:

El valor de localStorage es pot editar allà mateix: fas doble clic al valor, canvies el JSON i recarregues. És la manera més ràpida de comprovar com reacciona el teu codi a dades corrompudes, a un format de versió antiga, o a un tauler buit… sense escriure ni una línia. I Clear site data et torna a un arrencada neta, que és l'estat en què has de reproduir qualsevol error abans de donar-lo per bo.

L'emulador de dispositiu de les DevTools canvia la mida i simula el tàctil, però no és Safari en un iPhone ni Chrome en un Android de gamma baixa. Els errors de debò —un 100vh que es menja la barra d'adreces, un esdeveniment tàctil que no fa bombolla, una API que no existeix en aquella versió— només es veuen a l'aparell.

La inspecció remota connecta les DevTools del teu ordinador a la pàgina que s'executa al telèfon:

• Android + Chrome: activa les Opcions de desenvolupador i la Depuració per USB al telèfon, connecta'l per cable i obre chrome://inspect#devices a l'ordinador. La pestanya del telèfon apareix a la llista; prems inspect i tens les DevTools completes, inclosos el depurador i el panell Network.
• iOS + Safari: activa Configuració → Safari → Avançat → Inspector web a l'iPhone i Safari → Configuració → Avançat → Mostra el menú Desenvolupament al Mac; el dispositiu apareix sota el menú Desenvolupament.

I per provar Nómada Tasques al mòbil cal que el telèfon arribi al teu servidor de desenvolupament. Dues vies:

L'opció B importa per un detall de 07-05: els service workers exigeixen HTTPS excepte a localhost. I localhost al mòbil és el mateix mòbil, no el teu portàtil. Sense túnel HTTPS no podràs depurar la PWA en un dispositiu real.

Apliquem el mètode complet a un error real.

El part d'incidència. La Marta escriu: «He creat la tasca Revisar els extintors amb el formulari i després he premut Començar i no fa res. Les altres sí que funcionen.»

Pas 1 · Reproduir. Primer, una arrencada neta (Clear site data). Després, la seqüència exacta:

1. Obrir l'aplicació amb el backlog canònic (6 tasques).
2. Prémer Començar a la tasca 2 → funciona.
3. Crear una tasca nova amb el formulari.
4. Prémer Començar a la tasca nova → no passa res.

Reproduït, i amb una pista d'or: falla només a les tasques creades durant la sessió. Les del backlog van bé.

Pas 2 · Aïllar. És del formulari o de la creació? Provem de crear una tasca des de la consola, sense tocar el formulari:

El formulari queda descartat: el problema és a les tasques que vénen de crearTasca, és a dir, de l'API.

Pas 3 · Hipòtesi. El flux del clic és: controlador llegeix li.dataset.id → crida tauler.canviarEstat(id, ...) → cercarPerId(id) compara amb t.id === id. I dataset sempre retorna cadenes. Per a les tasques del backlog, id és un número al model; per a les de l'API… la hipòtesi concreta és:

Tasca.desDeJSON està desant id com a cadena per a les tasques que arriben del servidor, i cercarPerId fa servir ===, que no converteix tipus (01-07). Per això cercarPerId('7') retorna null i no troba la tasca.

Espera: si retornés null, Tauler.canviarEstat llançaria ErrorDeValidacio. Per què no veiem res? Perquè el controlador captura aquest error per mostrar-lo, i el catch l'escriu en un contenidor que està ocult. Segona part de la hipòtesi: l'error es llança i s'empassa.

Pas 4 · Comprovar. Dues comprovacions, cap no modifica el codi:

• Activar Pause on caught exceptions, prémer el botó. El depurador s'atura… al throw de Tauler.canviarEstat. Hipòtesi B confirmada.
• Posar un logpoint a la línia de cercarPerId amb {id, tipusId: typeof id, ids: this.tasques.map((t) => [t.id, typeof t.id])}:

Confirmadíssim. L'id del model és una cadena '7', el dataset també retorna cadena, però el controlador feia Number(li.dataset.id) abans de cridar, així que compara 7 === '7' → false.

Pas 5 · Corregir la causa. Tres arranjaments possibles, i només un és el correcte:

I de passada, el catch que s'empassava l'error deixa de ser silenciós: si el contenidor d'errors està ocult, es mostra. Un error que ningú veu és un error que existeix dues vegades.

Pas 6 · Prevenir. La prova que hauria d'existir, i que escriuràs a 08-03:

El part. L'Iván: «He filtrat pel meu nom per veure les meves tasques, he tancat el portàtil, i en tornar només quedaven tres tasques a tot el tauler. Les de la Marta i la Lucía han desaparegut.»

Pas 1 · Reproduir. Amb el backlog canònic: filtrar per Iván (queden 3 visibles), recarregar (F5) → el tauler té 3 tasques i el resum diu 25 h. Reproduïble al 100 %. I és un error de pèrdua de dades, la pitjor categoria: prioritat màxima.

Pas 2 · Aïllar. La pregunta clau: s'ha desat malament, o es llegeix malament? El panell Application la respon sense tocar el codi. Filtrem per Iván (sense recarregar) i mirem Local Storage → nomada:tauler:v1:

Només tres tasques ja escrites. L'error és a l'escriptura, no a la lectura. Acabem de descartar la meitat del recorregut amb una ullada.

Pas 3 · Hipòtesi. Qui crida desar i amb què? Aquí l'eina és console.trace() col·locat com a logpoint a RepositoriLocal.desar, amb l'expressió:

La hipòtesi s'escriu sola:

app.js està desant el que la vista mostra en lloc del tauler complet. En filtrar, la vista té 3 tasques i això és el que es persisteix, esclafant les altres 3.

Pas 4 · Comprovar. Obrim app.js:78:

Algú, en afegir l'encaminador de 07-06, va voler "desar l'estat en filtrar" i va construir un tauler nou amb les tasques visibles. Hipòtesi confirmada amb la línia al davant.

Pas 5 · Corregir. La causa real és conceptual, i mereix enunciar-se: s'ha persistit un valor derivat de la vista com si fos estat del model. El filtre és presentació (06-06) i el seu lloc és la URL (07-06); el tauler és el model i el seu lloc és el magatzem.

Pas 6 · Prevenir. Dues comprovacions per a 08-05, on es proven model i dades junts:

El part. La Lucía: «El resum diu 48 h obertes tot just obrir. Haurien de ser 45; la tasca de l'inventari està feta des de fa una setmana.»

Aquest cas és diferent dels anteriors: no cal reproduir res, falla sempre. I hi ha una cosa molt millor que un part d'incidència: hi ha un oracle. El backlog canònic té números coneguts —48 h totals, 45 h obertes, esforç 124— i el programa en contradiu un.

Pas 2 · Aïllar. Una sola ordre a la consola separa el model de la vista:

El model ja retorna 48. La vista és innocent: només pinta el que li donen. I hi ha un detall revelador: obertes: 5 és correcte (5 tasques obertes de 6), però horesObertes coincideix exactament amb horesTotals. Això no és un error de càlcul, és un error de selecció: s'estan sumant les sis.

Pas 3 · Hipòtesi.

horesObertes està reduint sobre totes les tasques en lloc de sobre les obertes.

Pas 4 · Comprovar. Posem el punt d'interrupció al getter i fem servir Watch amb dues expressions alhora:

L'expressió correcta dóna 45. Mirem el codi:

Un copiar i enganxar. L'error clàssic: dues línies gairebé idèntiques, una d'elles sense adaptar. Sospita sempre de les línies bessones.

Comprovació addicional amb git, per saber quan va entrar i descartar que hi hagués més danys al mateix canvi:

Pas 5 · Corregir.

Pas 6 · Prevenir. Aquest cas és l'argument perfecte per al mòdul sencer. Un error així:

• No llança cap error.
• No trenca cap pantalla.
• És invisible llevat que algú conegui el número correcte.
• I surt d'una capa —el model— que es pot comprovar sense navegador, sense DOM i sense xarxa, amb una funció que rep dades i retorna dades.

Mentrestant, una xarxa de seguretat de trenta segons que ja pots deixar posada, activada per una bandera:

Queda la categoria més difícil: «de vegades, en sortir de l'ascensor, se'm dupliquen les tasques». No hi ha passos, no hi ha pantalla, no hi ha pila. Quatre eines, en ordre d'esforç creixent:

1 · Registre estructurat. Substitueix els console.log solts per un registrador únic que emeti objectes amb context. Els objectes es poden filtrar, comptar i enviar; el text lliure no.

El buffer circular és la clau: quan l'error rar per fi passa, tens les 200 línies anteriors, no només el moment del desastre. Aquest és exactament el context que falta als incidents que no es reprodueixen.

2 · Banderes de diagnòstic. No pots demanar a la Marta que obri les DevTools. Però sí que li pots donar un interruptor:

I un botó «Copiar informe de diagnòstic» que posi al porta-retalls l'historial, el resum del tauler, la versió de l'aplicació i el navigator.userAgent. Un informe així converteix «de vegades falla» en un cas reproduïble.

3 · Reproduir les condicions, no els passos. Els errors intermitents gairebé sempre vénen de quatre llocs: la xarxa (fes servir Slow 4G i Offline), el temps (una tasca que venç avui i no ahir), la concurrència (dues pestanyes obertes amb l'esdeveniment storage de 07-01) i l'estat previ (un localStorage d'una versió antiga). Provoca aquestes condicions deliberadament i molts "irreproduïbles" es tornen fiables.

4 · Monitoratge d'errors. Per al que passa a l'ordinador d'una altra persona, la solució de la indústria és un servei de monitoratge (Sentry, Rollbar, Bugsnag i similars). El mecanisme essencial cap en deu línies, i entendre'l importa més que el proveïdor concret:

El que un servei afegeix sobre això: agrupa incidències idèntiques, aplica els source maps de l'apartat 12 per mostrar el teu codi original, desa la traça d'accions prèvies de l'usuari, i avisa quan apareix un error nou després d'un desplegament. Dos advertiments imprescindibles: no enviïs dades personals al context (ni títols de tasca, si poden contenir informació sensible), i respecta la normativa de protecció de dades aplicable.

• Canviar el codi abans d'entendre l'error. Si no pots explicar per què falla, el teu arranjament és una aposta. Primer la hipòtesi comprovada, després l'edició.
• Depurar en un estat brut. Un localStorage amb dades de tres experiments anteriors produeix errors fantasma. Reprodueix sempre des de Clear site data, i en una finestra d'incògnit si sospites d'una extensió.
• Confondre on es llança l'error amb on hi ha l'error. Llegeix la pila sencera, de baix a dalt. El culpable sol estar dos fotogrames més avall que el throw.
• Oblidar que dataset retorna cadenes. És la font del cas 1 i de la meitat dels errors d'identitat en aplicacions amb DOM. Normalitza els tipus a la frontera, sempre.
• console.log d'un objecte i creure que en veus el valor d'aleshores. La consola mostra objectes en viu: en desplegar-lo pots estar veient el seu estat actual, no el del moment del registre. Si necessites la foto, registra structuredClone(obj) (04-08) o JSON.stringify(obj).
• Posar el punt d'interrupció abans de l'await. Posa'l després: abans només veuràs una promesa pendent.
• Deixar debugger o registres de depuració en un commit. Es resol tot sol a la lliçó següent, amb no-debugger i no-console a ESLint més un hook de Git.
• Tapar errors amb try { … } catch {} buit. Un catch buit converteix un error sorollós en un de silenciós, que és infinitament pitjor. Si de veritat vols ignorar alguna cosa, escriu per què en un comentari.
• Consell: escriu la hipòtesi en una nota abans de comprovar-la. Obliga a concretar i evita la deriva d'anar mirant coses a l'atzar. En acabar tindràs a més el material del post mortem.
• Consell: si portes més d'una hora sense avançar, explica-ho a algú. El rubber duck debugging funciona perquè verbalitzar obliga a fer explícites les suposicions. La meitat de les vegades la solució apareix a mitja explicació.
• Consell: Ctrl/Cmd + P al panell Sources obre qualsevol fitxer pel nom, i Ctrl/Cmd + Maj + P és la paleta d'ordres de les DevTools. Amb aquestes dues dreceres deixaràs de buscar fitxers a l'arbre.

Exercici 1 — Diagnòstic amb el mètode. Un company reporta: «En prémer dues vegades ràpid sobre Començar a la tasca 1, la targeta es queda en en-curs però el resum diu que hi ha 4 tasques obertes en lloc de 5, i a la consola apareix un ErrorDeValidacio: Transició no permesa: "en-curs" → "en-curs"». Redacta el diagnòstic complet seguint els sis passos: passos de reproducció, cas mínim aïllat, hipòtesi falsable, quin instrument de DevTools faries servir per comprovar-la (indica el tipus exacte de punt d'interrupció i la seva condició), en quina capa corregiries, i quina prova escriuries per prevenir-ho.

Exercici 2 — Un mòdul de registre amb nivells i buffer. Escriu js/util/registre.js complet amb: quatre nivells (debug, info, warn, error), un llindar configurable per bandera (?diag=1 a la URL, persistit a localStorage), un identificador de sessió estable durant tota la visita, un buffer circular de les últimes 200 línies, i abocarInforme() que retorni un objecte amb l'historial, el resum del tauler, la versió de l'aplicació i el userAgent, llest per copiar al porta-retalls. Ha de sortir per console.debug/info/warn/error segons el nivell perquè el filtre de la consola funcioni.

Exercici 3 — Instrumentar el flux d'un clic. Sense modificar el codi de l'aplicació, descriu la configuració de DevTools que et permetria seguir el recorregut complet d'un clic a Començar de la tasca 3 —des de l'oient delegat fins a l'escriptura a localStorage— registrant a cada punt els valors rellevants i sense aturar mai l'execució. Indica el fitxer, la línia aproximada i l'expressió exacta de cada logpoint, i què esperaries veure a la consola si tot funciona bé.

Solució 1

Solució 2

Solució 3

Has canviat la manera d'enfrontar-te a un error. Ja no es tracta de mirar el codi fins que alguna cosa sembli sospitosa, sinó de recórrer sis passos: reproduir de manera fiable, aïllar fins al cas mínim, formular una hipòtesi falsable, comprovar-la amb un instrument, corregir la causa a la capa correcta i prevenir amb una prova. I saps que quan el terreny és gran, la bisecció —al flux de dades, a la història amb git bisect o al mateix codi— converteix una cerca lineal en una de logarítmica.

Coneixes la consola sencera i no només console.log: table per veure sis tasques d'una ullada, count per descobrir els renders duplicats, assert per vigilar invariants com les 45 h obertes, group per no ofegar-te en línies, trace per saber qui ha cridat, i el truc de les claus console.log({variable}) que etiqueta cada valor amb el seu nom. I domines el depurador de debò: la sentència debugger i els seus riscos, els sis tipus de punt d'interrupció —normal, condicional, de registre, per esdeveniment, per petició i per canvi del DOM—, la navegació amb step over, into i out, els panells Scope (on els closures de 03-04 són per fi visibles), Watch amb expressions calculades i Call Stack amb el seu Restart frame. Saps llegir un stack trace de baix a dalt, activar «Pause on caught exceptions» per caçar els errors que s'empassen els catch, seguir una pila asíncrona cosida a través dels await de 05-07, i per què sense source maps un error de producció no diu res. I tens el panell Network amb el seu Copy as fetch i el seu throttling, el panell Application per al localStorage i el service worker del Mòdul 7, i la inspecció remota per al mòbil de debò.

Sobretot, has resolt tres errors reals amb el mètode al davant: un id que arribava com a cadena des de l'API i feia fallar el === de 01-07 —corregit a la frontera de dades, no al model ni a la vista—; un filtre que persistia les tasques visibles en lloc del tauler complet, confonent un valor derivat de la vista amb l'estat del model; i un horesObertes que sumava sobre totes les tasques i retornava 48 en lloc de 45, un error silenciós que cap pantalla delatava. I has vist què fer quan l'error no es reprodueix: registre estructurat amb buffer circular, banderes de diagnòstic activables per URL, reproducció de condicions en lloc de passos, i una nota sobre els serveis de monitoratge que apliquen els teus source maps als errors d'altres persones.

Els tres casos comparteixen un final incòmode: tots tres s'han tancat amb una prova «pendent d'escriure». I tots tres, a més, tenien un avís previ que ningú va veure. L'id barrejant tipus, el catch buit que s'empassava l'error, les dues línies bessones on una no es va adaptar: són exactament el tipus de problema que una màquina pot assenyalar abans d'executar res, llegint el codi. Abans d'automatitzar les comprovacions de comportament convé automatitzar les de forma, perquè són més barates i atrapen una família sencera d'errors elles soles. Això és el següent: Qualitat de Codi: ESLint, Prettier i Convencions, on configuraràs un analitzador estàtic sobre Nómada Tasques, arreglaràs els avisos que apareguin —inclòs, amb tota seguretat, algun debugger oblidat d'aquesta lliçó— i posaràs un guardià a Git perquè res d'això no torni a arribar al repositori.