Dasturlash kitobi/15-QISM — Kasbiy konikmalar45 daqiqa

15.5-bob: Debugging metodologiyasi

15-QISM — Kasbiy ko'nikmalar · 5-mavzu

1. Kirish va motivatsiya

Har dasturchi kunining katta qismini xatolarni tuzatishga (debugging) sarflaydi — yangi kod yozishga emas. Kod hech qachon birinchi marta mukammal ishlamaydi (xatolar — bug — muqarrar). Va qanday debug qilish — havaskor va professional dasturchini ajratuvchi muhim ko'nikma. Havaskor tasodifan debug qiladi (kodni o'zgartiradi, ishlaydimi ko'radi, yana o'zgartiradi — "trial and error" — vaqt isrofi, ko'pincha yangi xato qo'shadi); professional tizimli debug qiladi (muammoni aniqlaydi, gipoteza quradi, tekshiradi — usul bilan — tez, ishonchli).

Debugging — bu detektivlik (xato — jinoyat, siz — detektiv). Tasodifan emas, dalil bilan ishlaysiz: xato qaerda (joy)? Qachon (sharoit)? Nima sababdan (sabab)? Bu bobda debuggingni san'at emas, metodologiya (takrorlanadigan usul) sifatida ko'ramiz — har dasturchi o'rgana oladigan tizimli yondashuv. Va vositalar (debugger, breakpoint, DevTools, log) — bu metodologiyani kuchaytiradi (taxmin o'rniga ko'rish). Tajribali dasturchi tezroq debug qiladi — bilimi ko'p emas, balki usuli yaxshi (tizimli, vositalar bilan).

Bu bob: debugging nima va tafakkur (tizimli vs tasodifan), tizimli jarayon (qadamlar), vositalar (debugger, breakpoint, DevTools, console), texnikalar (binary search, rubber duck, log), keng xato turlari (va qanday topish), Node.js/VS Code debugger (--inspect, launch.json, breakpoint/watch/call stack/step, debugger), stack trace o'qish, nozik xatolar (closure, this, off-by-one, race, memory leak), heisenbug/flaky va performance debugging, production debugging (monitoring, log, source map), yaxshi yordam so'rash, va debugging best practices — mavzuni to'liq va amaliy qamrab oladi.

O'xshatish: Debugging — bu shifokor tashxisi. Yomon shifokor tasodifan dori beradi ("buni sinab ko'r" — ishlamasa boshqasini) — bemorni xavf ostiga qo'yadi. Yaxshi shifokor tizimli (simptomlar — xato xabari; tekshiruvlar — log/debugger; gipoteza — sabab taxmini; tasdiqlash — tekshirish) — aniq tashxis, keyin davolash. Debugging ham shunday: tasodifan kodni o'zgartirish (yomon shifokor — "sinab ko'r") xavfli (yangi xato, vaqt isrofi); tizimli (simptom tekshiruv gipoteza tasdiqlash tuzatish) — aniq, tez. Va vositalar (debugger — rentgen, log — analiz) — ko'rishga yordam beradi (taxmin emas — dalil). Eng yaxshi "shifokorlar" (dasturchilar) — tizimli, vositalar bilan, sabr bilan (panika emas — usul).

Nega muhim?

Vaqtning katta qismi — debugging (yangi kod emas — xato tuzatish — kunlik ish).
Tizimli > tasodifan — usul bilan tez (trial-and-error — sekin, yangi xato).
Professional belgi — qanday debug qilish (bilim emas — usul) ajratadi.
Har joyda — debugging har til, framework, darajada (universal ko'nikma).

2. Nazariya — chuqur tushuntirish

2.1. Debugging tafakkuri (tizimli vs tasodifan)

text

  DEBUGGING TAFAKKURI — tizimli (usul) vs tasodifan (trial-and-error):

   TASODIFAN (yomon — havaskor):
   kodni o'zgartir  ishlaydimi?  yo'q  boshqasini o'zgartir  ...
   "balki bu?" — taxmin, sababsiz; vaqt isrofi; yangi xato qo'shadi
   muammoni TUSHUNMASDAN tuzatishga urinish

   TIZIMLI (yaxshi — professional):
   muammoni TUSHUN (qaerda, qachon, nima)  GIPOTEZA (sabab taxmini) 
    TEKSHIR (dalil — log/debugger)  TASDIQLA/RAD ET  tuzat
   DALIL bilan (taxmin emas); sababni topib tuzatish

  ASOSIY TAMOYIL:
   "Sabab"ni top, "simptom"ni emas (xato KO'RINISHI emas, MANBAI)
   Bir o'zgartirish bir vaqtda (ko'p o'zgartirsa — qaysi ta'sir qildi noaniq)
   Taxmin qilma — TEKSHIR (kod "shunday qiladi" — log bilan tasdiqla)

   Tizimli debug — tushungipotezatekshirtasdiqla (dalil bilan, sabab top)
   Tasodifan (trial-and-error) — taxmin, sababsiz, vaqt isrofi (havaskor)

Debugging tafakkuri (tizimli vs tasodifan) — debugging'ning asosiy yondashuvi. Tasodifan (trial-and-error — yomon, havaskor): kodni o'zgartir ishlaydimi yo'q boshqasini o'zgartir ... — "balki bu?" (taxmin, sababsiz), vaqt isrofi (ko'p urinish), va ko'pincha yangi xato qo'shadi (muammoni tushunmasdan o'zgartirish — boshqa narsani buzadi). Bu — muammoni tushunmasdan tuzatishga urinish (ko'r-ko'rona). Tizimli (yaxshi, professional): muammoni tushun (qaerda — joy, qachon — sharoit, nima — simptom) gipoteza (sabab taxmini — "ehtimol bu funksiya null qaytaryapti") tekshir (dalil — log/debugger bilan — taxminni tasdiqla) tasdiqla yoki rad et (dalil to'g'rimi) tuzat. Bu — dalil bilan (taxmin emas — ko'rib), sababni topib tuzatish. Asosiy tamoyil: (1) "sabab"ni top, "simptom"ni emas (xato ko'rinishi — masalan "sahifa oq" — emas, manbai — "ma'lumot null, render xato" — sababni tuzat, simptomni emas — aks holda qaytadi); (2) bir o'zgartirish bir vaqtda (ko'p o'zgartirsa — qaysi biri ta'sir qildi noaniq — bitta o'zgartir, tekshir); (3) taxmin qilma — tekshir (kod "shunday qiladi" deb o'ylama — log bilan tasdiqla — kod kutgandek ishlayaptimi). Ikki nuqta: (1) tizimli debug — tushun gipoteza tekshir tasdiqla (dalil bilan, sabab top); (2) tasodifan (trial-and-error) — taxmin, sababsiz, vaqt isrofi (havaskor). Tizimli debugging — takrorlanadigan usul (har xatoda bir xil jarayon — tushun, gipoteza, tekshir) — tajriba bilan tezlashadi (lekin usul — asos). Tasodifan — ba'zan ishlaydi (omad), lekin sekin va ishonchsiz (sababni bilmaysiz — qaytadi). Professional dasturchi tizimli (dalil bilan — detektiv kabi — 1.1). Eng muhim almashtirish — "balki bu?" (taxmin) "tekshiraman" (dalil). Debugging — fikrlash usuli (kod bilimi emas — metodologiya).

2.2. Tizimli debugging jarayoni

text

  TIZIMLI DEBUGGING JARAYONI (qadamlar — har xatoda):

  1. QAYTA HOSIL QIL (reproduce):
   xatoni QANDAY chaqirish? (aniq qadamlar — har safar chiqsin)
   qayta hosil bo'lmasa — debug qiyin (avval reproduce)

  2. TUSHUN (lokalizatsiya):
   xato qaerda? (qaysi fayl/funksiya/qator — xato xabari, stack trace)
   qachon? (qanday ma'lumot/sharoit — har doim? ba'zan?)

  3. GIPOTEZA (sabab taxmini):
   "ehtimol X sababli" (kod mantiqiga asoslangan taxmin)

  4. TEKSHIR (dalil):
   log/debugger — gipotezani tasdiqla (X haqiqatan shundami?)
   bir o'zgartirish bir vaqtda

  5. TUZAT + TASDIQLA:
   sababni tuzat  xato yo'qoldimi?  test (qaytmasin)

  6. O'YLA (oldini olish):
   nega bo'ldi? Qanday oldini olish? (test, tip — 7-QISM)

   Jarayon — reproduce  tushun  gipoteza  tekshir  tuzat  oldini olish
   Avval REPRODUCE (qayta hosil bo'lmasa debug qiyin); SABABNI tuzat (simptom emas)

Tizimli debugging jarayoni — har xatoda qo'llaniladigan qadamlar. Olti qadam: (1) qayta hosil qil (reproduce): xatoni qanday chaqirishni aniqla (aniq qadamlar — har safar chiqsin — masalan "login qil, savatga qo'sh, checkout bos — xato"); agar xato qayta hosil bo'lmasa (ba'zan chiqadi, ba'zan yo'q — "heisenbug") — debug qiyin (avval ishonchli reproduce — keyin debug); (2) tushun (lokalizatsiya — xatoni toraytirish): xato qaerda? (qaysi fayl/funksiya/qator — xato xabari va stack trace — eng muhim ma'lumot — qaysi qatorda), qachon (qanday ma'lumot/sharoit — har doimmi? faqat ba'zi ma'lumotdami?); (3) gipoteza (sabab taxmini): "ehtimol X sababli" (kod mantiqiga asoslangan taxmin — masalan "ehtimol user null, shuning uchun user.name xato"); (4) tekshir (dalil): log yoki debugger bilan gipotezani tasdiqla (X haqiqatan shundami — console.log(user) — null ekanini ko'r), bir o'zgartirish bir vaqtda 2.1-bob; (5) tuzat + tasdiqla: sababni tuzat (null tekshiruvi qo'sh) xato yo'qoldimi test (qaytmasin — 11.17); (6) o'yla (oldini olish): nega bo'ldi? Qanday oldini olish (test qo'sh, TypeScript tip — 7-QISM — null xavfini kompilyatorda tut). Ikki nuqta: (1) jarayon — reproduce tushun gipoteza tekshir tuzat oldini olish (tizimli — har xatoda); (2) avval reproduce (qayta hosil bo'lmasa debug qiyin — birinchi qadam), sababni tuzat (simptom emas — qaytmasin). Bu jarayon — debugging'ning "retsepti" (har xatoda bir xil — usul). Eng muhim — reproduce (qayta hosil — debug'ning poydevori — chiqarib bo'lmasa, tuzatib bo'lmaydi) va stack trace (xato qaerda — eng tez lokalizatsiya). Oldini olish (6-qadam) — ko'pincha o'tkazib yuboriladi, lekin muhim (bir xato tuzatilsa — test qo'sh — qaytmasin — yoki tip qo'sh — bunday xato boshqa joyda ham bo'lmasin). Bu jarayon panikani (xato!) usulga aylantiradi (tizimli — qadamlar).

2.3. Debugging vositalari (debugger, breakpoint)

text

  DEBUGGING VOSITALARI — taxmin o'rniga KO'RISH:

  1. DEBUGGER (eng kuchli — kodni TO'XTATIB tekshirish):
   breakpoint — qatorda to'xtaydi (o'sha paytda o'zgaruvchilarni ko'rish)
   step over/into — qator-qator yurish (kod oqimini kuzatish)
   o'zgaruvchilar paneli — har o'zgaruvchi qiymati (real vaqt)
   VS Code debugger (Node), Chrome DevTools (brauzer)

  2. CONSOLE.LOG (oddiy, tez — lekin cheklangan):
  console.log("user:", user);          // qiymatni ko'r
  console.log("bu yergacha yetdi");     // oqim — qaysi qatorga yetdi
  console.table(array);                 // massiv/obyekt jadval
  console.trace();                      // stack trace (qaerdan chaqirildi)

  3. DEVTOOLS (brauzer):
   Network (so'rovlar — API javobi, status)
   Elements (DOM, CSS — UI muammosi)
   Console (xato, log)
   Sources (debugger, breakpoint)

   Vositalar — debugger (to'xtatib tekshir — kuchli), console.log (tez), DevTools (brauzer)
   Debugger > console.log (kuchli — to'xtatib, har o'zgaruvchi; lekin log tez/oson)

Debugging vositalari (debugger, breakpoint) — taxmin o'rniga ko'rish. Vositalar debugging'ni kuchaytiradi (taxmin — "kod shunday qiladi" — o'rniga ko'rish — "kod aslida nima qiladi"). (1) Debugger (eng kuchli — kodni to'xtatib tekshirish): breakpoint (qatorga qo'yiladi — kod o'sha qatorga yetganda to'xtaydi — o'sha paytdagi barcha o'zgaruvchilar qiymatini ko'rasiz), step over/into (qator-qator yurish — step over keyingi qator, step into funksiya ichiga — kod oqimini kuzatish), o'zgaruvchilar paneli (har o'zgaruvchi qiymati — real vaqtda — to'xtagan paytda). Vositalar: VS Code debugger (Node.js — 5-QISM), Chrome DevTools (brauzer). (2) console.log (oddiy, tez — lekin cheklangan): console.log("user:", user) (qiymatni ko'r), console.log("bu yergacha yetdi") (oqim — qaysi qatorga yetdi — yetmagan bo'lsa, undan oldin xato), console.table(array) (massiv/obyekt — jadval — o'qish oson), console.trace() (stack trace — qaerdan chaqirildi). (3) DevTools (brauzer — frontend): Network (so'rovlar — API javobi, status — 13.4 — ma'lumot keldimi, xato status), Elements (DOM, CSS — UI muammosi — nega element ko'rinmaydi), Console (xato, log), Sources (debugger, breakpoint — brauzerda). Ikki nuqta: (1) vositalar — debugger (to'xtatib tekshir — eng kuchli), console.log (tez, oson), DevTools (brauzer — Network/Elements/Console); (2) debugger > console.log (kuchli — to'xtatib, har o'zgaruvchi, qator-qator; lekin console.log tez/oson — kichik tekshiruvga). Vositalar — debugging'ning "ko'zlari" (taxmin emas — ko'rish). Debugger eng kuchli (kodni to'xtatib, ichiga qarab — lekin ko'p dasturchi console.log bilan cheklanadi — debugger'ni o'rgansa tezroq debug). console.log — eng tez (kichik tekshiruv — "bu qiymat nima?"), lekin chekli (har tekshiruv uchun log qo'shish, o'chirish). DevTools — frontend uchun muhim (Network — API muammosi, Elements — UI muammosi). To'g'ri vosita — muammoga qarab (debugger — murakkab oqim; console.log — tez qiymat; Network — API; Elements — UI). Vositalar metodologiyani 2.2-bob kuchaytiradi (tekshir qadami — vosita bilan — dalil).

2.4. Debugging texnikalari

text

  DEBUGGING TEXNIKALARI — muammoni topish usullari:

  1. BINARY SEARCH (yarimga bo'lish — katta kodda):
   muammo qaerda noaniq?  o'rtaga log/breakpoint qo'y 
    muammo oldindami keyinmi?  yarmini chiqar  takrorla
   katta kod tez torayadi (log2 — 1000 qator  ~10 tekshiruv)

  2. RUBBER DUCK (o'rdakka tushuntirish):
   muammoni OVOZ chiqarib (yoki yozib) tushuntir (o'rdakka, hamkasbga)
   tushuntirayotganda ko'pincha o'zi topiladi ("voy, bu yerda!")
   muammoni SO'ZLASH — boshqacha ko'rish

  3. DIFF (nima o'zgardi?):
   "kecha ishlardi, bugun yo'q"  git diff (nima o'zgardi?)
   so'nggi o'zgarish — ko'pincha sabab (git bisect — avtomatik)

  4. MINIMAL REPRODUCE (sodda holatda):
   murakkab kodni soddalashtir (muammo qoladigan eng kichik holat)
   ko'pincha soddalashtirishda sabab topiladi

  5. O'QI (xato xabarini):
   xato xabari + stack trace — ko'pincha sababni AYTADI (o'qib chiq!)

   Texnikalar — binary search (yarimga), rubber duck (tushuntir), diff (nima o'zgardi)
   Eng oddiy — xato xabarini O'QI (ko'pincha javob shu yerda); minimal reproduce

Debugging texnikalari — muammoni topishning amaliy usullari. Besh texnika: (1) binary search (yarimga bo'lish — katta kodda): muammo qaerda ekani noaniq bo'lsa — kodning o'rtasiga log/breakpoint qo'y muammo undan oldinmi keyinmi aniqla muammosiz yarmini "chiqar" qolgan yarmida takrorla tez torayadi (1000 qator ~10 tekshiruv — log2(1000) — 3-QISM binary search mantiqi); (2) rubber duck (o'rdakka tushuntirish — mashhur texnika): muammoni ovoz chiqarib (yoki yozib) tushuntir (rezina o'rdakka, hamkasbga, yoki shunchaki o'zingizga) — tushuntirayotganda ko'pincha o'zingiz topasiz ("voy, bu yerda i o'rniga j yozdim!") — chunki muammoni so'zlash uni boshqacha ko'rishga majbur qiladi (kodni o'qish emas — tushuntirish); (3) diff (nima o'zgardi?): "kecha ishlardi, bugun yo'q" git diff (so'nggi o'zgarishlar — nima o'zgardi?) — so'nggi o'zgarish ko'pincha sabab; git bisect (avtomatik — qaysi commit buzdi — binary search commit'lar bo'yicha — 4-QISM); (4) minimal reproduce (sodda holatda): murakkab kodni soddalashtir (muammo qoladigan eng kichik holat — ortiqcha qismlarni olib tashla) — ko'pincha soddalashtirishda sababni topasiz (yoki muammo yo'qolsa — olib tashlangan qismda edi); (5) xato xabarini o'qi: xato xabari + stack trace ko'pincha sababni aytadi (Cannot read property 'name' of undefined — user undefined — aniq) — lekin ko'p dasturchi o'qimay panika qiladi (o'qib chiq — javob shu yerda). Ikki nuqta: (1) texnikalar — binary search (yarimga), rubber duck (tushuntir), diff (nima o'zgardi), minimal reproduce; (2) eng oddiy — xato xabarini o'qi (ko'pincha javob shu yerda — o'qimay panika qilma), minimal reproduce. Bu texnikalar — turli holatlarga (katta kod — binary search; "kecha ishlardi" — diff; chalkash — rubber duck; murakkab — minimal reproduce). Rubber duck — eng kam baholangan, lekin kuchli (tushuntirish — o'z xatoni ko'rsatadi — bepul, har joyda). Xato xabarini o'qish — eng oddiy, lekin ko'p o'tkazib yuboriladi (panika — "xato!" — o'qimay qidiradi — xato xabari javobni aytadi). Bu texnikalar metodologiyani 2.2-bob to'ldiradi (qanday topish — amaliy usullar).

2.5. Keng xato turlari va topish

text

  KENG XATO TURLARI — va qanday topish:

  1. SYNTAX (sintaksis — kod noto'g'ri yozilgan):
   kompilyator/linter darrov ko'rsatadi (qator + xabar) — eng oson
   "Unexpected token", missing bracket — o'qib tuzat

  2. RUNTIME (ishlash paytida — null, undefined, type):
   "Cannot read property of undefined" — eng keng
   ma'lumot kutilgandek emas (null/undefined) — log + tip (7-QISM)

  3. LOGIC (mantiq — kod ishlaydi, lekin NOTO'G'RI natija):
   eng qiyin (xato yo'q, lekin natija xato) — kutilgan vs haqiqiy
   off-by-one (< vs <=), noto'g'ri shart, noto'g'ri formula

  4. ASYNC (asinxron — vaqt/tartib):
   race condition, await unutilgan, Promise tutilmagan
   ma'lumot "kech" keladi (13.5: 2.2 waterfall)

  5. INTEGRATSIYA (qismlar birga — API, DB):
   Network tab (API javobi), DB so'rov, CORS 13.6-bob, env (13.10)

   Xato turlari — syntax (linter), runtime (null — log/tip), logic (eng qiyin — natija)
   Logic xato eng qiyin (kod ishlaydi, natija noto'g'ri) — kutilgan vs haqiqiy solishtir

Keng xato turlari va topish — xato turlarini tanish va mos topish usuli. Besh tur: (1) syntax (sintaksis — kod noto'g'ri yozilgan): kompilyator/linter (15.3) darrov ko'rsatadi (qator + xabar — "Unexpected token", missing bracket) — eng oson (o'qib tuzat — IDE qizil chizadi); (2) runtime (ishlash paytida — null, undefined, type): "Cannot read property 'x' of undefined" — eng keng — ma'lumot kutilgandek emas (null/undefined — masalan API null qaytardi, lekin kod obyekt kutdi) — log (ma'lumot nima) + TypeScript tip (7-QISM — null xavfini kompilyatorda tut); (3) logic (mantiq — kod ishlaydi, lekin noto'g'ri natija): eng qiyin (xato xabari yo'q — kod ishlaydi, lekin natija xato — masalan jami noto'g'ri hisoblandi) — kutilgan vs haqiqiy solishtir (nima kutganding, nima chiqdi — farqni top); keng logic xatolar — off-by-one (< vs <= — bir element kam/ortiq), noto'g'ri shart (&& vs ||), noto'g'ri formula; (4) async (asinxron — vaqt/tartib): race condition (tartib noto'g'ri), await unutilgan (Promise — ma'lumot kelmasdan ishlatildi), Promise tutilmagan (xato yo'qoldi) — ma'lumot "kech" keladi (13.5: 2.2 — async muammolar); (5) integratsiya (qismlar birga — API, DB): Network tab (API javobi — keldimi, status — 13.4), DB so'rov, CORS 13.6-bob, env (13.10 — yo'q env). Ikki nuqta: (1) xato turlari — syntax (linter darrov), runtime (null — log/tip), logic (eng qiyin — natija), async, integratsiya; (2) logic xato eng qiyin (kod ishlaydi, natija noto'g'ri — xato xabari yo'q) — kutilgan vs haqiqiy solishtir (farqni top). Xato turini tanish — mos topish usulini beradi (syntax — linter o'qi; runtime — log/stack trace; logic — kutilgan vs haqiqiy; async — tartib/await; integratsiya — Network/DB). Logic eng qiyin (vositalar kam yordam — kod "ishlaydi" — faqat natija noto'g'ri — kutilganni bilish kerak). Runtime eng keng (null/undefined — TypeScript ko'pini oldini oladi — 7-QISM — null xavfi kompilyatorda). Xato turini tezda tanish (xabar/holatga qarab) — tez debug (mos usul). Bu — debugging tajribasi (xato turlarini tanish — qaysi usul).

2.6. Production debugging

text

  PRODUCTION DEBUGGING — ishlab turgan ilovada (qiyinroq — kira olmaysiz):

  MUAMMO: production'da debugger yo'q (foydalanuvchi mashinasi/server)
   faqat KEYIN ma'lumot (log, monitoring) — real vaqt kuzatish qiyin

  VOSITALAR (production):
  1. STRUKTURALI LOG (winston/pino — 5.12):
   kontekst bilan (kim, qachon, nima) — keyin qidiriladigan
  2. ERROR TRACKING (Sentry — 13.10):
   xato avtomatik (stack trace, foydalanuvchi, sharoit) — darrov xabar
  3. MONITORING (metrics, log agregatsiya):
   anomaliya (ko'p xato, sekinlik) — naqsh
  4. SESSION REPLAY (foydalanuvchi sessiyasi — qanday bo'ldi)

  PRODUCTION DEBUGGING JARAYONI:
   Sentry'da xato  stack trace + kontekst  reproduce (local)  tuzat  deploy

   Production debug — log + error tracking (Sentry) + monitoring (debugger yo'q)
   Strukturali log (kontekst) — production'da ko'z; reproduce (local)  tuzat

Production debugging — ishlab turgan ilovada xato topish (qiyinroq). Muammo: production'da (foydalanuvchi brauzeri, yoki server — sizning kontrolingizda emas) debugger yo'q (kodni to'xtatib bo'lmaydi — foydalanuvchini kutib turolmaysiz), faqat keyin ma'lumot (log, monitoring — voqea bo'lgandan keyin tahlil) — real vaqt kuzatish qiyin. Vositalar (production): (1) strukturali log (winston/pino — 5.12 — kontekst bilan — kim, qachon, nima — keyin qidiriladigan — masalan "user123 02:00'da checkout'da xato" — tahlil uchun); (2) error tracking (Sentry — 13.10, 14.9 — xato avtomatik to'planadi — stack trace, foydalanuvchi, brauzer, sharoit — darrov xabar — siz bilasiz); (3) monitoring (metrics, log agregatsiya — ELK, Datadog — anomaliya — ko'p xato, sekinlik — naqsh — 14.8: Misol 5); (4) session replay (foydalanuvchi sessiyasi yozuvi — qanday qadamlar — xato qanday yuz berdi — "video"). Production debugging jarayoni: Sentry'da xato ko'r (stack trace + kontekst — qaysi foydalanuvchi, qanday ma'lumot) reproduce (local'da o'sha sharoitni qayta hosil — 2.2) tuzat deploy. Ikki nuqta: (1) production debug — log + error tracking (Sentry) + monitoring (debugger yo'q — keyin ma'lumot); (2) strukturali log (kontekst) — production'da "ko'z" (real vaqt kuzatish yo'q — log tahlil), reproduce (local'da) tuzat. Production debugging — local'dan qiyinroq (kira olmaysiz — faqat log/monitoring). Shuning uchun yaxshi log (strukturali, kontekstli — 5.12) va error tracking (Sentry — 13.10) kritik (production'da "ko'z" — bularsiz xato sezilmaydi yoki sababsiz). Jarayon: error tracking (xato + kontekst) local reproduce (o'sha sharoit) tizimli debug 2.2-bob tuzat deploy. Production'da debug — log/monitoring sifatiga bog'liq (yaxshi log — tez topish; log yo'q — "qora quti" — sababsiz). Bu — 13.10 (monitoring) + 14.9 (logging — A09)ning debugging tomoni (production xato topish). Yaxshi monitoring/log — production debugging'ning poydevori (kira olmaysiz — log orqali ko'rasiz).

2.7. Best practices va debugging zehni

text

  DEBUGGING BEST PRACTICES va ZEHNI:

  ZEHN (mentalitet):
   SABR (panika emas — usul; xato — normal, hal qilinadi)
   KAMTARLIK ("kod to'g'ri, kompilyator xato" — deyarli HAR DOIM kod xato)
   QIZIQUVCHANLIK (nega? — sababni tushunish — keyingi safar biladi)
   SHUBHA (taxminni tekshir — "bu shunday ishlaydi" deb ishonma)

  BEST PRACTICES:
   Xato xabarini O'QI (ko'pincha javob — 2.4)
   Reproduce (avval — 2.2)
   Bir o'zgartirish bir vaqtda 2.1-bob
   Tizimli (gipoteza  tekshir — 2.2)
   Vositalardan foydalan (debugger > log — 2.3)
   Tuzatgach — test (qaytmasin — 11.17)
   Charchaganda — tanaffus (yangi ko'z bilan ko'pincha topiladi)
   Yordam so'ra (uzoq qiynalsa — boshqa ko'z — rubber duck/hamkasb)

   Zehn — sabr, kamtarlik (kod xato), shubha (tekshir); best — o'qi, reproduce, tizimli
   Charchaganda tanaffus; uzoq qiynalsa yordam so'ra (yangi ko'z — tez topadi)

Best practices va debugging zehni — debugging'ning yakuni (zehn + amaliyot). Zehn (mentalitet — debugging'ning yarmi): (1) sabr (panika emas — usul — xato normal (har dasturchi kuni), hal qilinadi — vahima debug'ni buzadi); (2) kamtarlik ("kod to'g'ri, kompilyator/kutubxona xato" deb o'ylama — deyarli har doim kod (sizning) xato — kutubxona/kompilyator sinalgan — avval o'z kodingizni shubha qil); (3) qiziquvchanlik (nega? — sababni tushunish — faqat tuzatish emas — keyingi safar biladi, takrorlamaydi); (4) shubha (taxminni tekshir — "bu funksiya shunday ishlaydi" deb ishonma — log bilan tasdiqla — 2.1). Best practices: (1) xato xabarini o'qi (ko'pincha javob — 2.4); (2) reproduce (avval — 2.2); (3) bir o'zgartirish bir vaqtda 2.1-bob; (4) tizimli (gipoteza tekshir — 2.2); (5) vositalardan foydalan (debugger > log — 2.3); (6) tuzatgach — test (qaytmasin — 11.17); (7) charchaganda — tanaffus (yangi ko'z bilan — ko'pincha tanaffusdan keyin darrov topiladi — miya fonda ishlaydi); (8) yordam so'ra (uzoq qiynalsa — boshqa ko'z — rubber duck yoki hamkasb — yangi nuqtai nazar — ko'pincha tez topadi). Ikki nuqta: (1) zehn — sabr (panika emas), kamtarlik (kod xato — kutubxona emas), shubha (tekshir); best — o'qi, reproduce, tizimli, test; (2) charchaganda tanaffus (yangi ko'z), uzoq qiynalsa yordam so'ra (boshqa ko'z — tez topadi). Debugging — texnik (vositalar, texnikalar — 2.3, 2.4) + zehniy (sabr, kamtarlik, shubha — 2.7). Zehn ko'pincha muhimroq (panika — yomon debug; sabr + usul — yaxshi). Eng keng zehniy xato — "kod to'g'ri, boshqa narsa xato" (kamtarlik yo'q — soatlab noto'g'ri joyda qidirish — kutubxona, kompilyator — aslida o'z kodi). Tanaffus va yordam — kam baholangan, lekin kuchli (charchagan miya — yomon ko'radi; tanaffus/boshqa ko'z — yangi nuqtai nazar). Debugging — o'rganiladigan ko'nikma (metodologiya + vositalar + zehn — 1.1) — tajriba bilan tezlashadi, lekin usul (tizimli, sabr, dalil) — asos. Bu — har dasturchining kunlik, eng muhim ko'nikmalaridan (kod yozish — yarim ish; debug — yarim ish). Professional dasturchi tez debug qiladi (bilim emas — usul: tizimli, dalil, sabr, vositalar).

2.8. Node.js va VS Code debugger (amaliy sozlash)

text

  NODE.JS DEBUGGER — kodni to'xtatib, ichiga qarab tekshirish:

  1. node --inspect (Chrome DevTools ulash):
   node --inspect index.js        // debugger portini ochadi (9229)
   node --inspect-brk index.js    // birinchi qatorda to'xtaydi (start'ni ko'r)
   chrome://inspect  "inspect"  Chrome DevTools ochiladi (Node kodiga)

  2. VS Code launch.json (F5 bilan ishga tushirish + to'xtash):
   .vscode/launch.json — debug konfiguratsiyasi
   breakpoint qo'y (qator raqami yoniga bosish — qizil nuqta)  F5

  3. DEBUGGER PANELLARI (to'xtagan paytda):
   VARIABLES — barcha o'zgaruvchilar qiymati (Local, Closure, Global)
   WATCH — kuzatiladigan ifoda (masalan user.name — har to'xtashda yangilanadi)
   CALL STACK — chaqiruvlar zanjiri (bu funksiya qaerdan chaqirildi)
   BREAKPOINTS — barcha breakpoint'lar ro'yxati (yoqish/o'chirish)

  4. QADAM TUGMALARI:
   Continue (F5)      — keyingi breakpoint'gacha davom
   Step Over (F10)    — keyingi qator (funksiya ichiga KIRMASDAN)
   Step Into (F11)    — funksiya ICHIGA kirish (chaqirilgan funksiyani kuzat)
   Step Out (Shift+F11) — joriy funksiyadan CHIQISH (chaqiruvchiga qaytish)

   node --inspect (Chrome) yoki launch.json (VS Code — F5) — Node debugger
   Watch (kuzat) + Call Stack (qaerdan) + Step (qator-qator) — kuchli tekshir

Node.js va VS Code debugger — kodni to'xtatib, ichiga qarab tekshirishning amaliy sozlanishi (2.3 debugger'ning konkret ishlatilishi). console.log — tez, lekin har tekshiruvga log qo'shib-o'chirish kerak; debugger kodni to'xtatib, o'sha paytdagi barcha holatni bir joyda ko'rsatadi (log yozmasdan). (1) node --inspect (Chrome DevTools'ni Node kodiga ulash): node --inspect index.js — debug portini (9229) ochadi; node --inspect-brk index.js — kod boshida (birinchi qator) to'xtaydi (ishga tushishni kuzatish uchun); keyin brauzerda chrome://inspect "inspect" bosilsa — Chrome DevTools Node kodiga ulanadi (frontend emas — backend kodi). (2) VS Code launch.json (eng qulay — F5 bilan): .vscode/launch.json faylida debug konfiguratsiyasi (masalan "type": "node", "program": "${workspaceFolder}/index.js"); kod qatorining chap tomoniga bosib breakpoint (qizil nuqta) qo'yiladi F5 bilan ishga tushirilsa, kod o'sha qatorga yetganda to'xtaydi. (3) panellar (to'xtagan paytda): Variables (barcha o'zgaruvchilar qiymati — Local/Closure/Global — closure o'zgaruvchilarini ham ko'rsatadi — 2.10 uchun muhim), Watch (kuzatiladigan ifoda — masalan user.name yozib qo'ysangiz, har to'xtashda qiymati yangilanadi — takror log yozmaslik), Call Stack (chaqiruvlar zanjiri — bu funksiya qaerdan chaqirildi — stack trace'ning jonli ko'rinishi — 2.9), Breakpoints (barcha breakpoint ro'yxati). (4) qadam tugmalari: Continue (F5 — keyingi breakpoint'gacha), Step Over (F10 — keyingi qator, funksiya ichiga kirmasdan), Step Into (F11 — funksiya ichiga kirish — chaqirilgan funksiyani kuzatish), Step Out (Shift+F11 — joriy funksiyadan chiqish — chaqiruvchiga qaytish). (5) conditional breakpoint (shartli — breakpoint'ga o'ng bosib "Edit Breakpoint" shart, masalan id === 42 — faqat o'sha holatda to'xtaydi — sikl ichida foydali) va logpoint (breakpoint o'rniga — to'xtatmay, faqat ifodani konsolga chiqaradi — console.log qo'shmasdan). (6) debugger operatori: kodga debugger; qatorini yozsangiz — debugger yoqilgan holda kod o'sha yerda to'xtaydi (breakpoint'ning kod-ichi varianti — brauzerda ham, Node'da ham) — lekin commit'dan oldin olib tashlang. Ikki nuqta: (1) node --inspect (Chrome) yoki launch.json (VS Code — F5) — Node debugger'ni ishga tushiradi; (2) Watch (kuzat) + Call Stack (qaerdan) + Step (qator-qator) + conditional breakpoint (shart bilan) — kuchli tekshiruv (log emas — jonli holat). Brauzer uchun bir xil g'oyalar Sources panelida 2.3-bob — breakpoint, conditional/logpoint, step, watch, call stack — bir xil ishlaydi. Debugger o'rganish — bir marta investitsiya (keyin har debug tezroq — log qo'shib-o'chirmasdan).

2.9. Stack trace va xato xabarini o'qish

text

  STACK TRACE O'QISH — xato qaerdan kelganini aytadi (yuqoridan pastga):

  TypeError: Cannot read properties of undefined (reading 'name')
      at formatUser (utils.js:12:20)        ENG YUQORI = xato AYNAN shu yerda
      at renderProfile (Profile.js:34:10)  formatUser'ni chaqirgan (yuqori qatlam)
      at handleClick (App.js:56:5)         renderProfile'ni chaqirgan
      at HTMLButtonElement.onclick         boshlang'ich (foydalanuvchi bosdi)

  O'QISH TARTIBI:
   1-QATOR (xabar): xato TURI (TypeError) + NIMA (undefined'ning 'name'i)
   ENG YUQORI "at": xato AYNAN qaysi fayl:qator:ustun (utils.js:12) — shu yerdan boshlan
   PASTGA: chaqiruvlar zanjiri (qanday yo'l bilan bu yerga kelindi)
   O'Z KODINGIZNI top (node_modules emas — sizning fayl — ko'pincha sabab shu)

   Xabar TURI + ENG YUQORI "at" (fayl:qator) — 90% hollarda javob shu yerda
   Xabarni to'liq o'qing (undefined'ning nimasi? qaysi qiymat kutilgan edi?)

Stack trace va xato xabarini o'qish — eng tez lokalizatsiya usuli (2.2 "tushun" qadamining kaliti), lekin ko'p dasturchi panika qilib o'qimaydi. Stack trace — xato yuz bergan paytdagi chaqiruvlar zanjiri (qaysi funksiya qaysinisini chaqirgan). O'qish: (1) birinchi qator — xato turi (TypeError, ReferenceError, SyntaxError) va nima (Cannot read properties of undefined (reading 'name') — ya'ni undefined bo'lgan narsaning name xususiyatini o'qishga urinildi — demak biror qiymat undefined, lekin obyekt kutilgan); (2) eng yuqori at ... — xato aynan qaysi fayl, qator va ustunda (utils.js:12:20) — bu eng muhim qator (xato shu yerda ro'y berdi — shu yerdan boshlab qarang); (3) pastga tushgan at qatorlari — chaqiruvlar zanjiri (formatUserni renderProfile chaqirgan, uni handleClick, uni tugma bosilishi) — bu qanday yo'l bilan shu holatga kelinganini ko'rsatadi (kontekst); (4) o'z kodingizni toping — stack trace'da ko'pincha node_modules ichidagi qatorlar ham bo'ladi (kutubxona kodi), lekin sabab deyarli har doim sizning faylingizda (2.7 kamtarlik) — kutubxonaga o'tishdan oldingi oxirgi o'z kodingiz qatoriga qarang. Xato xabarini to'liq o'qish: undefinedning nimasi? (name — demak obyekt kutilgan, undefined kelgan — qayerda o'sha qiymat hosil bo'ldi?); is not a function (funksiya deb chaqirildi, lekin funksiya emas — import xatosimi? typo?); is not defined (o'zgaruvchi umuman e'lon qilinmagan — typo yoki import unutilgan). Ikki nuqta: (1) xabar turi + eng yuqori at (fayl:qator) — 90% hollarda javob shu yerda (avval shuni o'qing); (2) xabarni to'liq o'qing (undefined'ning nimasi, qaysi qiymat kutilgan edi — xabar ko'pincha sababni to'g'ridan-to'g'ri aytadi). Stack trace — bepul, avtomatik, aniq (fayl:qator) — o'qimaslik eng keng debugging xatosi (Xato 2 — panika). Source map 2.6-bob production'da minifikatsiyalangan kodni asl qatorlarga qaytaradi (shusiz stack trace o'qib bo'lmaydi — a.js:1:2843).

2.10. Nozik xato turlari: closure, `this`, off-by-one, race, memory leak

text

  NOZIK XATO TURLARI — chalkash, lekin keng uchraydigan:

  1. CLOSURE (sikl ichida var — hammasi oxirgi qiymatni ko'radi):
  for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)); // 3 3 3 (!)
   sabab: var — funksiya-doiraviy, hammasi BIR i'ni ulashadi
   yechim: let (blok-doiraviy — har iteratsiya yangi i)  0 1 2

  2. `this` (kontekst yo'qolishi — oddiy funksiyada):
  button.onclick = obj.method;   // method ichida this — button (obj EMAS!)
   yechim: arrow (() => obj.method()) yoki .bind(obj)

  3. OFF-BY-ONE (< vs <=, i vs i+1):
  for (let i = 0; i <= arr.length; i++)  //  oxirgi: arr[length] = undefined
   yechim: i < arr.length (=< emas)

  4. RACE CONDITION (tartib kafolatlanmagan):
   2 async so'rov, qaysi avval tugashi noaniq  natija o'zgaruvchan
   yechim: await ketma-ket, yoki Promise.all, yoki so'nggi so'rovni belgilash

  5. MEMORY LEAK (tozalanmagan — xotira o'sadi):
   addEventListener/setInterval/subscription — cleanup yo'q  to'planadi
   yechim: removeEventListener/clearInterval (React: useEffect cleanup — 11.11)

   closure(let), this(arrow/bind), off-by-one(<), race(await/Promise.all), leak(cleanup)

Nozik xato turlari — 2.5'dagi turlarning eng chalkash, real hollarda ko'p vaqt yeydigan aniq ko'rinishlari (har biriga misol + qanday topish). (1) closure sikl ichida — for (var i...) setTimeout(() => console.log(i)) — kutilgan 0 1 2, lekin 3 3 3 chiqadi: sabab — var funksiya-doiraviy (barcha callback'lar bitta ini ulashadi, u sikl tugagach 3 bo'ladi); topish — konsolda kutilmagan takror qiymat; yechim — let (blok-doiraviy — har iteratsiya yangi i). (2) this konteksti — button.onclick = obj.method qilsangiz, method ichida this endi obj emas, button (yoki undefined — strict) — chunki oddiy funksiyada this qanday chaqirilganiga bog'liq; topish — this.something undefined; yechim — arrow funksiya (() => obj.method()) yoki .bind(obj). (3) off-by-one — for (let i = 0; i <= arr.length; i++) — <= sababli oxirgi iteratsiyada arr[arr.length] = undefined (bitta ortiqcha); topish — massiv oxirida undefined yoki bitta kam/ortiq natija; yechim — i < arr.length (tekshiring: chegara < bo'lishi kerakmi <= mi). (4) race condition — ikki async so'rov bir vaqtda ketsa, qaysi avval tugashi kafolatlanmagan — masalan tez ketma-ket qidiruvda eski so'rov keyin qaytib, natijani buzadi (natija o'zgaruvchan — ba'zan to'g'ri); topish — vaqti-vaqti bilan noto'g'ri natija (flaky — 2.11); yechim — await bilan ketma-ket, Promise.all (parallel, lekin tartibli natija), yoki so'nggi so'rovni belgilab eskisini bekor qilish (AbortController). (5) memory leak — addEventListener, setInterval, obuna (subscription) tozalanmasa — to'planib, xotira asta o'sadi (uzoq ishlaganda sekinlashuv/qulash); topish — DevTools Memory profileri (heap snapshot — nima o'smoqda), vaqt o'tishi bilan xotira grafigi ko'tarilishi; yechim — removeEventListener, clearInterval, React'da useEffect cleanup (return funksiyasi — 11.11). Ikki nuqta: (1) closure — let, this — arrow/bind, off-by-one — <, race — await/Promise.all/AbortController, leak — cleanup; (2) bular chalkash (kod "ishlaydi"gandek, lekin nozik shart buzilgan) — race va leak eng qiyin (heisenbug/flaky — 2.11). Bu xatolar 2-QISM (closure, this), 3-QISM (off-by-one), 13.5 (race) va 11.11 (React cleanup) bilan bog'liq — debugging tomoni: har birini tanish (naqsh) va topish usulini bilish.

2.11. Heisenbug, flaky testlar va performance/xotira debugging

text

  HEISENBUG / FLAKY va PERFORMANCE debugging:

  HEISENBUG (kuzatganda o'zgaradi/yo'qoladi):
   log/debugger qo'shsa xato yo'qoladi (vaqt/tartib o'zgardi — race belgisi)
   asosan async/race/tozalanmagan holat — 2.10 (4)

  FLAKY TEST (ba'zan o'tadi, ba'zan yo'q):
   sabab: race, tartibga bog'liqlik, tashqi holat (vaqt, tarmoq, DB)
   yechim: deterministik qil (vaqtni mock, tartibni kafolatla, izolyatsiya)

  PERFORMANCE (sekin — nima sekin NOANIQ):
   o'lchov: DevTools Performance (flame graph — qaysi funksiya vaqt yedi)
   Node: node --prof yoki console.time("x")...console.timeEnd("x")
   optimallash FAKAT o'lchagach (taxmin qilma — profiler dalil)

   Heisenbug/flaky = ko'pincha race 2.10-bob — deterministik qil (mock, izolyatsiya)
   Performance — avval O'LCHA (profiler/timer), keyin optimallash (taxmin emas)

Heisenbug, flaky va performance debugging — eng chalkash, aniqlash qiyin holatlar. (1) Heisenbug (nomi fizikadan — Heisenberg noaniqlik prinsipi): xato kuzatilganda o'zgaradi yoki yo'qoladi — masalan console.log yoki breakpoint qo'shsangiz xato yo'qoladi (chunki log vaqtni biroz o'zgartiradi — async tartib boshqacha bo'ladi). Bu deyarli har doim race condition yoki tozalanmagan/ulashilgan holat belgisi 2.10-bob — kod vaqt/tartibga bog'liq. Topish — log o'rniga tartibni kafolatlash (await), yoki holatni izolyatsiya qilish. (2) Flaky test (ba'zan o'tadi, ba'zan yiqiladi — bir xil kodda): sabab — race, testlar tartibiga bog'liqlik (bir test boshqasidan qolgan holatga tayanadi), yoki tashqi holat (joriy vaqt, tarmoq, DB holati); yechim — testni deterministik qilish: vaqtni mock qilish (Date.nowni belgilash), tartibni kafolatlash, har testni izolyatsiya (o'z ma'lumoti bilan — 11.17). Flaky test yomon (ishonchni yo'qotadi — "yana yiqildi, qayta ishga tushir" — asosiy xatoni yashiradi). (3) Performance debugging (sekin — lekin nima sekinligi noaniq): birinchi qoida — avval o'lchang, keyin optimallashtiring (taxmin qilib noto'g'ri joyni optimallash — vaqt isrofi); o'lchov vositalari — brauzerda DevTools Performance paneli (yozib olib, flame graph — qaysi funksiya qancha vaqt yegani), Node'da node --prof (profil fayli) yoki oddiy console.time("x") ... console.timeEnd("x") (ikki nuqta orasidagi vaqt); DevTools Memory (heap snapshot — xotira o'sishi — 2.10 leak). Optimallash faqat dalil bilan (profiler eng sekin joyni ko'rsatadi — o'shani tuzat — qolganiga tegma). Ikki nuqta: (1) heisenbug/flaky — ko'pincha race 2.10-bob belgisi — deterministik qiling (mock, izolyatsiya, await); (2) performance — avval o'lchang (profiler/timer — dalil), keyin optimallashtiring (taxmin emas — 2.1 tamoyili performance'ga ham). Bu holatlar debugging'ning eng ilg'or qismi — sabr va tizimli o'lchov (dalil bilan — taxmin emas) hal qiladi.

2.12. Yaxshi yordam so'rash (savol berish)

text

  YAXSHI YORDAM SO'RASH — uzoq qiynalganda (2.7 "yordam so'ra"):

  YOMON savol: "Kodim ishlamayapti, yordam bering!"   ma'lumot yo'q
  YAXSHI savol (javob berish oson):
   NIMA qilmoqchisiz (maqsad)
   NIMA qildingiz (kod — minimal reproduce — 2.4)
   NIMA KUTGANDINGIZ vs NIMA CHIQDI (aniq — xato xabari to'liq)
   NIMANI SINAB KO'RDINGIZ (izlanish — takror savolni oldini oladi)

   Yaxshi savol = maqsad + minimal kod + kutilgan/haqiqiy + xato xabari + sinovlar
   Ko'pincha yaxshi savol YOZAYOTGANDA javobni o'zingiz topasiz (rubber duck — 2.4)

Yaxshi yordam so'rash — uzoq qiynalganda 2.7-bob samarali savol berish (bu 06-bob "hujjat o'qish va texnik kommunikatsiya" bilan chambarchas — savol berish san'ati). Yomon savol ("kodim ishlamayapti, yordam bering") — javob beruvchida ma'lumot yo'q (nima qilmoqchi, qanday kod, qanday xato — bilinmaydi — javob bera olmaydi). Yaxshi savol to'rt qismdan: (1) maqsad (nima qilmoqchisiz — kontekst); (2) minimal kod (nima qildingiz — muammoni ko'rsatuvchi eng kichik kod — 2.4 minimal reproduce — ortiqchasiz); (3) kutilgan vs haqiqiy (nima kutgandingiz, nima chiqdi — xato xabarini to'liq joylashtiring — skrinshot emas, matn); (4) sinovlar (nimani sinab ko'rdingiz — izlanish ko'rsatilsa, javob beruvchi takrorlanmaydi va yordamga tayyorroq bo'ladi). Bu tuzilma Stack Overflow, jamoa chati yoki hamkasbdan so'rashda bir xil ishlaydi. Ikki nuqta: (1) yaxshi savol = maqsad + minimal kod + kutilgan/haqiqiy + xato xabari + sinovlar (javob berishni osonlashtiradi); (2) ko'pincha savolni yozayotganda (muammoni tartibga solayotganda) javobni o'zingiz topasiz — bu rubber duck effekti 2.4-bob. Yaxshi savol berish — kasbiy ko'nikma (tez javob oladi, hurmat qozonadi) va o'z-o'zini debug qilishning davomi.

3. Sintaksis — debugging ma'lumotnoma

text

JARAYON 2.2-bob:    reproduce  tushun  gipoteza  tekshir  tuzat  oldini olish
DEBUGGER 2.3-bob:   breakpoint + step over/into + o'zgaruvchilar (VS Code/DevTools)
CONSOLE 2.3-bob:    console.log/table/trace/dir; "bu yergacha yetdi"
TEXNIKA 2.4-bob:    binary search | rubber duck | git diff/bisect | minimal reproduce
XATO O'QISH 2.9-bob:xato xabari + stack trace (eng yuqori at: fayl:qator — javob shu)
NODE DBG 2.8-bob:   node --inspect | launch.json (F5); watch/call stack/step; debugger;
NOZIK 2.10-bob:     closure(let) | this(arrow/bind) | off-by-one(<) | race | leak(cleanup)
PROFIL 2.11-bob:    Performance (flame graph) | console.time; avval o'lcha, keyin tuzat
PRODUCTION 2.6-bob: log (pino) + Sentry (error) + monitoring; source map; reproduce local
ZEHN 2.7-bob:       sabr, kamtarlik (kod xato), shubha (tekshir); tanaffus, yordam (2.12)

4. Batafsil misollar

Har misol: Maqsad + senariy + "Bu nima ko'rsatadi".

Misol 1 — Tizimli debug jarayoni (2.2)

Maqsad: Real xatoni tizimli jarayon bilan topish — reproduce'dan tuzatishgacha. Bu metodologiyaning amaliy ko'rinishi.

text

XATO: "Sahifa oq, console'da: Cannot read property 'name' of undefined"

 TASODIFAN (yomon):
 "balki user yo'q?"  user.name ni user?.name qil  ishladi (lekin NEGA?)
 simptom tuzaldi, sabab noaniq (boshqa joyda qaytishi mumkin)

 TIZIMLI (yaxshi):
1. REPRODUCE: /profile sahifasi  har doim oq (aniq)
2. TUSHUN: stack trace  ProfilePage.tsx:12  `{user.name}` xato
3. GIPOTEZA: "user undefined — ehtimol fetch null qaytardi yoki kech keldi"
4. TEKSHIR: console.log("user:", user)  undefined (tasdiqlandi)
    console.log("response:", res.status)  404! (sabab — user topilmadi)
5. TUZAT (SABAB): 404 holatini boshqar:
   if (!user) return <NotFound />;   // sabab (user yo'q) boshqarildi
6. OLDINI OLISH: 404/null holat testi qo'sh; TypeScript tip (user: User | null)

Bu nima ko'rsatadi: Bu — tizimli debug jarayoni (metodologiya amalda — 2.2). Xato: sahifa oq + Cannot read property 'name' of undefined. Tasodifan (yomon): "balki user yo'q?" user.name ni user?.name (optional chaining) qil ishladi — lekin sabab noaniq (nega user undefined? — fetch muammosimi? 404? race? — bilmaymiz — boshqa joyda (masalan user.email) qaytishi mumkin — simptom tuzaldi, sabab qoldi). Tizimli (yaxshi — 6 qadam): (1) reproduce — /profile har doim oq (aniq — ishonchli reproduce); (2) tushun — stack trace o'qi (ProfilePage.tsx:12 — {user.name} xato — aniq joy va qator); (3) gipoteza — "user undefined — ehtimol fetch null qaytardi yoki kech keldi" (taxmin); (4) tekshir — console.log("user:", user) undefined (tasdiqlandi); chuqurroq — console.log("response:", res.status) 404 (sabab topildi — user topilmadi — DB'da yo'q — fetch 404 qaytardi, lekin kod buni boshqarmadi); (5) tuzat (sabab) — 404/null holatini boshqar (if (!user) return <NotFound /> — sabab — user yo'q — boshqarildi); (6) oldini olish — 404/null holat testi qo'sh (11.17 — qaytmasin), TypeScript tip (user: User | null — kompilyator null xavfini eslatadi — 7-QISM). Farq: tasodifan — user?.name (simptomni yashirdi — sahifa oq emas, lekin user yo'q — bo'sh ko'rsatadi — noto'g'ri); tizimli — sababni topdi (404 — user yo'q) va to'g'ri boshqardi (NotFound sahifa). Nega tizimli yaxshi: sababni topadi (404 — user yo'q), to'g'ri yechim (NotFound — foydalanuvchiga aniq), va oldini oladi (test, tip). Tasodifan — simptomni yashiradi (?. — sabab qoladi — boshqa joyda qaytadi, yoki bo'sh ko'rsatadi — yomon UX). Bu — metodologiyaning kuchi (dalil bilan sababni topish — taxmin emas). Stack trace (2-qadam — eng tez lokalizatsiya) va tekshir (4-qadam — console.log bilan dalil — 404) — kalit. Bu jarayon har xatoda (tizimli — usul).

Misol 2 — Binary search bilan topish (2.4)

Maqsad: Katta funksiyada muammoni binary search bilan tez topish. Bu katta kodda samarali lokalizatsiya.

tsx

// XATO: bu 200-qatorli funksiya noto'g'ri natija beradi (qaerda noaniq)
function processData(input) {
  // ... 50 qator (1-bosqich)
  // ... 50 qator (2-bosqich)
  // ... 50 qator (3-bosqich)
  // ... 50 qator (4-bosqich)
  return result;   // result noto'g'ri
}

// BINARY SEARCH (yarimga bo'lib toraytirish):
function processData(input) {
  // ... 1-2 bosqich (100 qator)
  console.log("o'rtada:", intermediateResult);   //  O'RTAGA log
  //  kutilgandek bo'lsa  muammo KEYINGI yarmida (3-4 bosqich)
  //  noto'g'ri bo'lsa  muammo OLDINGI yarmida (1-2 bosqich)
  // ... 3-4 bosqich (100 qator)
  return result;
}

// Aniqlangach — o'sha yarmni yana yarimga (75-qator  25  12  topildi)
// 200 qator  ~8 tekshiruv (log2(200) ≈ 7.6) — tez!

Bu nima ko'rsatadi: Bu — binary search bilan muammo topish (katta kodda — 2.4). Xato: 200-qatorli funksiya (processData) noto'g'ri natija beradi, lekin qaerda (qaysi qator) noaniq — 200 qatorni birma-bir tekshirish sekin. Binary search (yarimga bo'lib toraytirish — 3-QISM binary search mantiqi): (1) funksiyaning o'rtasiga (100-qator — 2-bosqich oxiri) console.log("o'rtada:", intermediateResult) qo'y; (2) o'rtadagi natija kutilgandekmi tekshir: agar kutilgandek (to'g'ri) muammo keyingi yarmida (3-4 bosqich — 100-200 qator); agar noto'g'ri muammo oldingi yarmida (1-2 bosqich — 1-100 qator); (3) aniqlangach — o'sha yarmni yana yarimga (masalan 1-100 o'rta 50 ... 25 12 topildi). Natija: 200 qator ~8 tekshiruv (log2(200) ≈ 7.6 — har tekshiruv yarimga kamaytiradi — 200 100 50 25 12 6 3 1) — birma-bir (200 tekshiruv)dan ancha tez. Nega bu samarali: katta kodda muammo qaerda noaniq bo'lsa — binary search logarifmik (200 qator — 8 tekshiruv emas, 200 emas) — har tekshiruv qidiruv maydonini yarimga kamaytiradi. Bu 3-QISM binary search (massiv)ning debugging'ga qo'llanishi (kod — "massiv", muammo — "qidiriladigan element"). Qachon: katta funksiya/fayl, muammo qaerda noaniq (xato xabari aniq joy bermasa — masalan logic xato — 2.5 — natija noto'g'ri, lekin qaysi qator?). Qanday: o'rtaga tekshiruv (log/breakpoint) qaysi yarmda takrorla. git bisect 2.4-bob — bu binary search'ning commit'lar bo'yicha versiyasi (qaysi commit buzdi — minglab commit ~10 tekshiruv). Binary search — debugging'ning samarali texnikasi (katta kod/tarix — tez toraytirish). Bu — algoritmik fikrlash (3-QISM)ning amaliy qo'llanishi (debugging'da).

Misol 3 — Async xato debug (2.5)

Maqsad: Asinxron xatoni (await unutilgan) topish va tuzatish. Bu eng chalkash, keng async muammosi.

tsx

//  XATO: ma'lumot kelmasdan ishlatiladi (await unutilgan):
async function getUser(id) {
  const user = db.user.findUnique({ where: { id } });   //  await YO'Q!
  console.log(user.name);   // xato: user — Promise (Pending), .name undefined
  return user;
}
// simptom: "Cannot read property 'name' of undefined" yoki kutilmagan natija

// DEBUG (tizimli):
// 1. console.log("user:", user)  Promise { <pending> } (!! — Promise, ma'lumot emas)
// 2. GIPOTEZA: "user — Promise — await unutilgan"
// 3. TEKSHIR: findUnique async (Promise qaytaradi) — await kerak

//  TUZATILGAN:
async function getUser(id) {
  const user = await db.user.findUnique({ where: { id } });   // await qo'shildi
  console.log(user.name);   // endi user — ma'lumot
  return user;
}

// BOSHQA ASYNC XATOLAR:
//  Promise tutilmagan: .catch() yoki try/catch yo'q  xato yo'qoladi
//  race condition: 2 so'rov, tartib noaniq  natija o'zgaruvchan
//  ESLint: @typescript-eslint/no-floating-promises (await unutilgan — 15.3)

Bu nima ko'rsatadi: Bu — async xato debug (await unutilgan — eng keng async muammosi — 2.5). Xato: getUserda db.user.findUnique (Promise qaytaradi — async) awaitsiz chaqirilgan user — Promise (ma'lumot emas — hali kelmagan — pending) user.name — undefined (Promise'ning namei yo'q) xato. Debug (tizimli — 2.2): (1) console.log("user:", user) Promise { <pending> } (!! — bu kalit — user ma'lumot emas, Promise — darrov sabab ko'rinadi); (2) gipoteza — "user Promise — await unutilgan"; (3) tekshir — findUnique async (Promise qaytaradi — ORM — 6.12) — await kerak. Tuzatilgan: const user = await db.user.findUnique(...) (await qo'shildi — endi user — haqiqiy ma'lumot — Promise hal bo'lgach). Boshqa async xatolar: (1) Promise tutilmagan (.catch() yoki try/catch yo'q — async xato yo'qoladi — "unhandled rejection" — ko'rinmaydi); (2) race condition (2 so'rov bir vaqtda — tartib noaniq — natija o'zgaruvchan — ba'zan to'g'ri, ba'zan yo'q — eng chalkash); (3) ESLint — @typescript-eslint/no-floating-promises (qoida — await unutilgan Promise'ni topadi — 15.3 — vosita bu xatoni oldini oladi). Nega async qiyin: async xatolar chalkash (kod "ishlaydi"gandek, lekin ma'lumot kech/yo'q/tartib noto'g'ri — xato joyi aniq emas). Kalit dalil — console.log(user) Promise { pending } (ma'lumot emas — Promise — await unutilgan — darrov sabab). Async debug'da: console.log (Promise'mi yoki ma'lumot?), await tekshir (har async chaqiruv await'mi?), ESLint (no-floating-promises — avtomatik). TypeScript + ESLint ko'p async xatoni oldini oladi (await unutilgan — qoida topadi — 15.3). Bu — async (2-QISM Promise, 13.5)ning debugging tomoni (vaqt/tartib muammolari — eng keng await unutilgan). console.log(Promise) — async debug'ning kalit texnikasi (Promise yoki ma'lumotmi).

Misol 4 — DevTools Network debug (2.3, 2.5)

Maqsad: API integratsiya xatosini DevTools Network bilan topish. Bu frontend-backend muammolarini ko'rsatadi.

text

XATO: "Mahsulotlar ko'rinmaydi" (sahifa bo'sh, console'da xato yo'q)

DEBUG (DevTools Network — 2.3):
1. Network tab och  sahifani yangila  so'rovlarni ko'r
2. /api/products so'rovini top:
   ┌────────────────────────────────────────────┐
   │ Status: 500   (xato — server muammosi)    │   BACKEND xato
   │ yoki Status: 200, lekin Response: []        │   ma'lumot bo'sh (DB?)
   │ yoki Status: 401   auth (token yo'q — 14.6)│
   │ yoki Status: CORS error  CORS 13.6-bob       │
   │ yoki so'rov YO'Q  frontend yubormagan      │
   └────────────────────────────────────────────┘

3. STATUS bo'yicha lokalizatsiya:
    500: backend log'ni ko'r (server xato — DB? kod?)
    200 + bo'sh: DB'da ma'lumot? yoki filtr xato?
    401: token/auth muammosi
    CORS: server CORS sozlamasi 13.6-bob
    so'rov yo'q: frontend kodi (fetch chaqirildimi?)

 Network tab — frontend(so'rov)/backend(javob) chegarasini aniqlaydi (qaysi tomon)

Bu nima ko'rsatadi: Bu — DevTools Network debug (API integratsiya xatosi — 2.3, 2.5). Xato: "mahsulotlar ko'rinmaydi" (sahifa bo'sh, console'da JavaScript xatosi yo'q — bu integratsiya xatosi — frontend-backend chegarasi). Debug (Network tab — eng muhim frontend debugging vositasi): (1) Network tab och sahifani yangila barcha so'rovlarni ko'r; (2) /api/products so'rovini top va statusga qara — turli holatlar turli sababni ko'rsatadi: 500 (server xato — backend muammosi — kod yoki DB), 200 + Response: [] (so'rov ishladi, lekin ma'lumot bo'sh — DB'da yo'q yoki filtr xato), 401 (auth — token yo'q — 14.6), CORS error (server CORS sozlamasi — 13.6), so'rov yo'q (frontend fetchni yubormagan — frontend kodi). (3) status bo'yicha lokalizatsiya (qaysi tomon — frontend yoki backend): 500 backend log (server xato — DB? kod?); 200 + bo'sh DB'da ma'lumot bormi yoki filtr; 401 token/auth; CORS server sozlamasi; so'rov yo'q frontend (fetch chaqirildimi?). Nega Network tab muhim: integratsiya xatosi (frontend-backend) — qaysi tomon aybdor noaniq (frontend yubormadimi? backend xatomi? ma'lumot bo'shmi?). Network tab buni aniqlaydi (so'rov yuborildimi — frontend; javob nima — backend; status — qaysi muammo). Bu chegarani ko'rsatadi (frontend so'rov yubordi backend javob berdi status/javob) — qaysi tomonda muammo. Masalan: so'rov yo'q frontend (fetch chaqirilmadi — frontend debug); 500 backend (server xato — backend debug); 200 + bo'sh DB/ma'lumot (backend/DB debug). Network tab'siz — taxmin ("frontendmi backendmi?"); Network bilan — dalil (status, javob — aniq). Bu — frontend debugging'ning eng muhim vositasi (Network — API muammosi; Elements — UI muammosi; Console — JS xato — 2.3). Integratsiya xatolarida (13.6 — API, CORS, auth) Network tab birinchi qadam (qaysi tomon, qanday status). Bu — full-stack debugging (frontend-backend chegarasi — Network bilan aniqlash).

Misol 5 — Production xato debug (Sentry — 2.6)

Maqsad: Production'da yuz bergan xatoni Sentry orqali topish va reproduce qilish. Bu real-dunyo production debugging.

text

PRODUCTION XATO: ba'zi foydalanuvchilar checkout'da xato (siz ko'rmaysiz)

DEBUG (Sentry — error tracking — 2.6):
1. Sentry'da xato keldi (avtomatik — foydalanuvchi shikoyat qilmasdan):
   ┌─────────────────────────────────────────────────────┐
   │ Error: Cannot read property 'price' of undefined    │
   │ Stack: CheckoutPage.tsx:45  calculateTotal         │
   │ Foydalanuvchi: user_8821 (47 marta sodir bo'ldi)    │
   │ Brauzer: Safari 16 (faqat Safari!)                  │
   │ Kontekst: cart = [{ id: 5, price: undefined }]      │
   └─────────────────────────────────────────────────────┘

2. KONTEKST tahlil:
    faqat Safari (brauzer-xos?) + price undefined (ma'lumot muammosi)
    cart'da bir mahsulot price'siz (eski mahsulot? DB nomutanosiblik?)

3. REPRODUCE (local — Safari + o'sha cart):
    price undefined holatini qayta hosil  xato chiqdi (tasdiqlandi)

4. TUZAT: price undefined holatini boshqar:
   const total = cart.reduce((sum, item) => sum + (item.price ?? 0), 0);

5. DEPLOY + Sentry kuzat (xato yo'qoldimi?)

 Production debug — Sentry (xato+kontekst)  reproduce (local)  tuzat  deploy  kuzat

Bu nima ko'rsatadi: Bu — production xato debug (Sentry — 2.6 — real-dunyo). Production xato: ba'zi foydalanuvchilar checkout'da xato — lekin siz ko'rmaysiz (sizning mashinangizda ishlaydi — faqat ba'zi foydalanuvchida — production'da). Debug (Sentry — error tracking — 13.10, 14.9): (1) Sentry'da xato keldi (avtomatik — foydalanuvchi shikoyat qilmasdan — Sentry to'pladi): Cannot read property 'price' of undefined, stack (CheckoutPage.tsx:45 calculateTotal — aniq joy), foydalanuvchi (user_8821 — 47 marta — keng muammo), brauzer (Safari 16 — faqat Safari! — muhim kontekst), kontekst (cart = [{ id: 5, price: undefined }] — price undefined!); (2) kontekst tahlil — faqat Safari (brauzer-xos?) + price undefined (ma'lumot muammosi) — cart'da bir mahsulot price'siz (eski mahsulot? DB nomutanosiblik? — sabab); (3) reproduce (local — Safari + o'sha cart) — price undefined holatini qayta hosil xato chiqdi (tasdiqlandi — Sentry konteksti bilan local'da reproduce); (4) tuzat — price undefined holatini boshqar (item.price ?? 0 — undefined bo'lsa 0 — xato yo'q); (5) deploy + Sentry kuzat (xato yo'qoldimi — Sentry'da yangi xato kelmasmi). Nega Sentry muhim (production debugging): production'da siz ko'rmaysiz (foydalanuvchi mashinasi — sizning emas), va foydalanuvchi shikoyat qilmaydi (ko'pincha jim ketadi); Sentry avtomatik to'playdi (xato + boy kontekst — stack, foydalanuvchi, brauzer, ma'lumot — 2.6) siz bilasiz, va reproduce uchun kontekst bor (Safari + price undefined — local'da qayta hosil). Kontekst kalit (brauzer — Safari-xos; ma'lumot — price undefined — sababni ko'rsatadi). Sentry'siz — bu xato noma'lum (foydalanuvchi checkout qila olmaydi, jim ketadi — sotuv yo'qoladi — siz bilmaysiz). Sentry bilan — darrov ma'lum (47 marta — keng), kontekstli (sabab), reproduce qilinadigan. Jarayon: Sentry (xato + kontekst) reproduce (local — kontekst bilan) tizimli debug 2.2-bob tuzat deploy kuzat (yo'qoldimi). Bu — production debugging'ning real oqimi (monitoring/error tracking — 13.10, 14.9 — production'da "ko'z"). Yaxshi monitoring (Sentry) — production debugging'ni mumkin qiladi (kira olmaysiz — Sentry orqali ko'rasiz).

5. To'g'ri va noto'g'ri holatlar

1) Yondashuv

text

 tasodifan (trial-and-error — taxmin — 2.1)
 tizimli (gipoteza  tekshir — Misol 1)

2) Xato xabari

text

 o'qimay panika (qidiradi)
 o'qi (ko'pincha javob — 2.4)

3) Tuzatish

text

 simptom (user?.name — sabab qoladi)
 sabab (404 boshqar — Misol 1)

4) O'zgartirish

text

 ko'p o'zgartirish (qaysi ta'sir noaniq)
 bir o'zgartirish bir vaqtda (2.1)

5) Vosita

text

 faqat console.log (chekli)
 debugger + DevTools + Sentry (2.3, 2.6)

6) Zehn

text

 panika, "kod to'g'ri" (kamtarlik yo'q — 2.7)
 sabr, shubha (kod xato — tekshir)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Tasodifan debug

Sababi: usulsiz 2.1-bob. Yechimi: tizimli (reproduce gipoteza tekshir — Misol 1).

Xato 2 — Xato xabarini o'qimaslik

Sababi: panika 2.4-bob. Yechimi: o'qi + stack trace (javob shu yerda).

Xato 3 — Simptom tuzatish

Sababi: sabab tushunmasdan 2.1-bob. Yechimi: sababni top (Misol 1).

Xato 4 — Reproduce'siz debug

Sababi: xato qayta hosil bo'lmaydi 2.2-bob. Yechimi: avval reproduce.

Xato 5 — Async (await unutilgan)

Sababi: Promise ma'lumot deb 2.5-bob. Yechimi: console.log(Promise?) + await (Misol 3).

Xato 6 — Production'da ko'rinmaydi

Sababi: log/monitoring yo'q 2.6-bob. Yechimi: Sentry + log (Misol 5).

Xato 7 — Stack trace'ni e'tiborsiz qoldirish

Sababi: panika, uzun ko'rinadi 2.9-bob. Yechimi: eng yuqori at (fayl:qator) — javob shu.

Xato 8 — Closure sikl (var) — hammasi oxirgi qiymat

Sababi: var funksiya-doiraviy 2.10-bob. Yechimi: let (blok-doiraviy).

Xato 9 — Taxmin bilan optimallashtirish

Sababi: o'lchamasdan 2.11-bob. Yechimi: avval profiler (dalil), keyin tuzat.

Xato 10 — Yomon savol berish

Sababi: ma'lumot yo'q 2.12-bob. Yechimi: maqsad + minimal kod + xato + sinov.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

Barcha kod (0-14 QISM): debugging har joyda (kod yozish + tuzatish).
DevTools (0.5, brauzer): Network/Elements/Console/Sources.
TypeScript (7-QISM): tip — runtime xato (null) oldini.
Test 11.17-bob: xato test (qaytmasin); TDD.
Async (2-QISM, 13.5): Promise/await xatolari.
Monitoring 13.10-bob: Sentry, log — production debug; source map.
Logging (5.12, 14.9): strukturali log (kontekst).
Node.js/VS Code (5-QISM): --inspect, launch.json, breakpoint 2.8-bob.
Closure/this (2-QISM), off-by-one (3-QISM): nozik xatolar 2.10-bob.
React cleanup 11.11-bob: memory leak (useEffect cleanup — 2.10).
Performance 13.9-bob: profiler, flame graph — sekinlik debug 2.11-bob.
Savol berish (06-bob): yaxshi savol — texnik kommunikatsiya 2.12-bob.

8. Eng yaxshi amaliyotlar (best practices)

Tizimli (reproduce gipoteza tekshir — Misol 1).
Xato xabarini o'qi (stack trace — ko'pincha javob — 2.4).
Sababni tuzat (simptom emas — Misol 1).
Bir o'zgartirish bir vaqtda 2.1-bob.
Vositalardan foydalan (debugger > log; Network — Misol 4).
Binary search (katta kod — Misol 2).
Rubber duck (tushuntir — o'zingiz topasiz — 2.4).
Debugger'ni o'rgan (breakpoint/watch/step/conditional — log'dan kuchli — 2.8).
Stack trace'ni o'qi (eng yuqori at — fayl:qator — 2.9).
Nozik xatolarni tanish (closure/this/off-by-one/race/leak — 2.10).
Avval o'lcha, keyin optimallashtir (profiler — dalil, taxmin emas — 2.11).
Tuzatgach test (qaytmasin — 11.17).
Production: Sentry + log + source map (Misol 5, 2.6).
Yaxshi savol ber (maqsad+kod+xato+sinov — 2.12).
Zehn: sabr, kamtarlik, tanaffus, yordam 2.7-bob.

9. Amaliy loyiha: "Debugging Mashqi"

Tizimli debugging'ni mustahkamlash.

Maqsad

Xatoli kodni (o'z loyihangiz buglari yoki berilgan) tizimli debug qil — har xato turini.

Talablar (requirements)

Tizimli jarayon: reproduce gipoteza tekshir tuzat (Misol 1).
Xato xabari: stack trace o'qib lokalizatsiya 2.4-bob.
Vositalar: debugger (breakpoint), console.log, DevTools 2.3-bob.
Runtime xato: null/undefined (Misol 1).
Async xato: await/Promise (Misol 3).
Logic xato: kutilgan vs haqiqiy 2.5-bob.
Network: API integratsiya (Misol 4).
Binary search: katta kod (Misol 2).
Sababni tuzat: simptom emas 2.1-bob.
Test: tuzatgach (qaytmasin — 11.17).

Maslahatlar (hint)

Xato xabarini o'qi (Xato 2).
Reproduce avval (Xato 4).
Sabab (Xato 3).
console.log(Promise?) (Xato 5).
Sabr (Xato — panika emas).

"Tayyor" mezonlari (acceptance criteria)

Tizimli jarayon (har xato).
Stack trace lokalizatsiya.
Vositalar ishlatildi.
Sabab tuzatildi (simptom emas).
Test (qaytmasin).

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda debugging metodologiyasini chuqur o'rgandik:

Tafakkur (tizimli vs tasodifan — 2.1); jarayon 2.2-bob; vositalar (debugger/DevTools — 2.3); texnikalar (binary search/rubber duck — 2.4); xato turlari 2.5-bob; production (Sentry — 2.6); zehn/best practices 2.7-bob; Node/VS Code debugger 2.8-bob; stack trace o'qish 2.9-bob; nozik xatolar (closure/this/off-by-one/race/leak — 2.10); heisenbug/flaky/performance 2.11-bob; yaxshi savol 2.12-bob.

Endi siz tizimli debug qila olasiz: reproduce gipoteza tekshir sababni tuzat (dalil bilan, taxmin emas), vositalar bilan (debugger, DevTools, Sentry), va zehn bilan (sabr, kamtarlik). Bu — har dasturchining kunlik, eng muhim ko'nikmasi.

Keyingi bob — 15.6-bob: Hujjat o'qish va texnik kommunikatsiya. Debuggingni bildik; endi muhim, lekin kam o'rgatiladigan ko'nikmani ko'ramiz: hujjat (documentation) o'qish (rasmiy hujjatdan o'rganish — eng muhim manba), qidirish (muammoga yechim topish — Google/Stack Overflow), texnik yozish (o'z hujjatingiz, README), va savol berish (yaxshi savol — tez javob). Bu — mustaqil o'rganish va kommunikatsiya ko'nikmasi.

Foydalanilgan rasmiy/ishonchli manbalar

"Debugging" (David J. Agans) — debugging'ning 9 tizimli qoidasi
"The Pragmatic Programmer" (Hunt & Thomas) — debugging zehni, rubber duck
"Why Programs Fail" (Andreas Zeller) — ilmiy metod, delta debugging
Node.js rasmiy hujjati — debugging guide (--inspect, Inspector)
Chrome DevTools rasmiy hujjati — Sources, Performance, Memory panellari
VS Code rasmiy hujjati — debugging (launch.json, breakpoint, watch)
MDN — JavaScript xato turlari (TypeError, ReferenceError), stack trace
Sentry rasmiy hujjati — production error tracking va source map
"How to Ask a Good Question" (Stack Overflow) — yaxshi savol tuzilmasi

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!

15.5-bob: Debugging metodologiyasi

1. Kirish va motivatsiya

2. Nazariya — chuqur tushuntirish

2.1. Debugging tafakkuri (tizimli vs tasodifan)

2.2. Tizimli debugging jarayoni

2.3. Debugging vositalari (debugger, breakpoint)

2.4. Debugging texnikalari

2.5. Keng xato turlari va topish

2.6. Production debugging

2.7. Best practices va debugging zehni

2.8. Node.js va VS Code debugger (amaliy sozlash)

2.9. Stack trace va xato xabarini o'qish

2.10. Nozik xato turlari: closure, this, off-by-one, race, memory leak

2.11. Heisenbug, flaky testlar va performance/xotira debugging

2.12. Yaxshi yordam so'rash (savol berish)

3. Sintaksis — debugging ma'lumotnoma

4. Batafsil misollar

Misol 1 — Tizimli debug jarayoni (2.2)

Misol 2 — Binary search bilan topish (2.4)

Misol 3 — Async xato debug (2.5)

Misol 4 — DevTools Network debug (2.3, 2.5)

Misol 5 — Production xato debug (Sentry — 2.6)

5. To'g'ri va noto'g'ri holatlar

6. Keng tarqalgan xatolar va yechimlari

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

8. Eng yaxshi amaliyotlar (best practices)

9. Amaliy loyiha: "Debugging Mashqi"

Maqsad

Talablar (requirements)

Maslahatlar (hint)

"Tayyor" mezonlari (acceptance criteria)

10. Xulosa va keyingi bobga ko'prik

Foydalanilgan rasmiy/ishonchli manbalar

Izohlar (0)

2.10. Nozik xato turlari: closure, `this`, off-by-one, race, memory leak