15.2-bob: Code review madaniyati

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

1. Kirish va motivatsiya

15.1-bobda toza kod yozishni o'rgandik. Lekin real ishda siz yolg'iz emassiz — jamoada ishlaysiz, va kodingiz boshqa odamlar tomonidan tekshiriladi (va siz ham boshqalarning kodini tekshirasiz). Bu — code review (kod ko'rigi): kod asosiy tarmoqqa (main) qo'shilishdan oldin, boshqa dasturchi(lar) uni o'qib, tekshirib, fikr beradi. Bu deyarli har professional jamoada majburiy jarayon (GitHub Pull Request — PR — orqali). Yangi dasturchi uchun code review qo'rqinchli ko'rinishi mumkin ("kodimni tanqid qilishadi"), lekin u aslida — o'rganish va sifat oshirishning eng kuchli vositasi.

Code review nima beradi? (1) Sifat — xatolar, zaifliklar (14-QISM), kod hidlari 15.1-bob ikkinchi ko'z bilan topiladi (yozgan odam ko'rmaydi, tekshiruvchi ko'radi); (2) bilim almashish — jamoa bir-biridan o'rganadi (yangi texnika, naqsh, kod uslubi); (3) umumiy mas'uliyat — kod jamoaniki (bir kishi emas — hamma biladi, hamma mas'ul); (4) izchillik — kod uslubi bir xil bo'ladi (jamoa standartlari). Lekin code review — nozik madaniyat masalasi: noto'g'ri qilinsa (qo'pol tanqid, shaxsiy hujum) — odamlarni ranjitadi, jamoani buzadi; to'g'ri qilinsa (konstruktiv, hurmatli) — jamoani kuchaytiradi, hammani o'stiradi. Bu bob ikkalasini — texnik (nima tekshirish) va madaniy (qanday muloqot) — ochadi.

Bu bob code review madaniyatini to'liq ochadi: code review nima va nega, PR yaxshi yozish (review olishni osonlashtirish), review berish (qanday konstruktiv fikr), review olish (qanday qabul qilish), nima tekshirish (review checklist), review madaniyati (hurmat, balans), va avtomatlashtirish (linter, CI — odam vaqtini tejash).

O'xshatish: Code review — bu maqola muharriri (editor). Yozuvchi (dasturchi) maqola (kod) yozadi, lekin uni nashr qilishdan oldin muharrir (reviewer) o'qiydi — xatolarni topadi (imlo, mantiq — buglar), yaxshilanishlarni taklif qiladi ("bu jumla noaniq" — "bu funksiya chalkash"), va sifatni kafolatlaydi. Yaxshi muharrir yozuvchini tanqid qilmaydi (shaxsan), balki matnni yaxshilaydi (konstruktiv — "bu yerda aniqroq bo'lsa") — yozuvchi o'rganadi, maqola yaxshilanadi. Yomon muharrir esa qo'pol ("bu axlat") — yozuvchini ranjitadi, hech narsani yaxshilamaydi. Code review ham shunday: maqsad — kodni yaxshilash (dasturchini tanqid emas), konstruktiv (o'rgatuvchi), hurmatli. Eng yaxshi jamoalar — har kod review'dan o'tadi (hatto eng tajribali dasturchi ham — hamma xato qiladi), va review — birga o'sish vositasi.

Nega muhim?

• Sifat — ikkinchi ko'z (xato, zaiflik, kod hidi — yozgan odam ko'rmaydi).
• Bilim almashish — jamoa bir-biridan o'rganadi (eng kuchli o'qish vositalaridan).
• Madaniyat — to'g'ri review jamoani kuchaytiradi, noto'g'ri buzadi (nozik).
• Professional norma — har jamoada code review (PR) — ishga tayyor bo'lish.

2. Nazariya — chuqur tushuntirish

2.1. Code review nima va jarayon

  CODE REVIEW — kod asosiy tarmoqqa qo'shilishdan OLDIN tekshirilishi:

  JARAYON (GitHub PR — Pull Request):
  1. Dasturchi branch'da ishlaydi (feature/yangi-xususiyat — 4-QISM)
  2. PR ochadi (o'zgarishlarni main'ga qo'shish so'rovi)
  3. CI ishlaydi (test, lint, build, xavfsizlik — avtomatik — 10.9, 14.9)
  4. Reviewer(lar) kodni o'qiydi, fikr beradi (comment)
  5. Dasturchi fikrlarga javob/tuzatish
  6. Tasdiq (approve)  merge (main'ga qo'shiladi)

  CODE REVIEW NIMA BERADI:
   Sifat (xato, zaiflik, kod hidi — ikkinchi ko'z)
   Bilim almashish (jamoa o'rganadi)
   Umumiy mas'uliyat (kod jamoaniki)
   Izchillik (uslub bir xil)

   Code review — kod main'ga qo'shilishdan oldin tekshiruv (PR — GitHub)
   Beradi — sifat + bilim + mas'uliyat + izchillik (ikkinchi ko'z)

Code review nima va jarayon — code review'ning asosiy oqimi. Code review — kod asosiy tarmoqqa (main/production) qo'shilishdan oldin boshqa dasturchi(lar) tomonidan tekshirilishi. Jarayon (GitHub Pull Request — PR — 4.3): (1) dasturchi alohida branchda ishlaydi (feature/yangi-xususiyat — 4-QISM — main'ni buzmasdan); (2) PR ochadi (o'zgarishlarn main'ga qo'shish so'rovi — Pull Request); (3) CI ishlaydi (test, lint, build, xavfsizlik — avtomatik — 10.9 CI/CD, 14.9 xavfsizlik pipeline); (4) reviewer(lar) kodni o'qiydi, fikr beradi (comment — qator bo'yicha); (5) dasturchi fikrlarga javob/tuzatish (muhokama, o'zgartirish); (6) tasdiq (approve) merge (main'ga qo'shiladi). Code review nima beradi: (1) sifat (xato, zaiflik, kod hidi — ikkinchi ko'z — yozgan odam ko'rmaydi, tekshiruvchi topadi); (2) bilim almashish (jamoa bir-biridan o'rganadi); (3) umumiy mas'uliyat (kod jamoaniki — bir kishi emas); (4) izchillik (uslub bir xil — jamoa standartlari). Ikki nuqta: (1) code review — kod main'ga qo'shilishdan oldin tekshiruv (PR — GitHub — har o'zgarish review'dan o'tadi); (2) beradi — sifat + bilim + mas'uliyat + izchillik (ikkinchi ko'z — yozgan odam ko'rmaydigan narsani topadi). Bu — professional jamoaning standart jarayoni (deyarli har jamoada — kod to'g'ridan main'ga ketmaydi, review'dan o'tadi). CI (avtomatik — test/lint/xavfsizlik) + odam review (mantiq, dizayn, o'qiluvchanlik) — birga sifatni kafolatlaydi. Code review — kod yozish jarayonining ajralmas qismi (yolg'iz yozish emas — jamoa bilan tekshirib).

2.2. PR yaxshi yozish (review olishni osonlashtirish)

  YAXSHI PR — reviewer ishini OSONLASHTIRADI (tez, sifatli review):

  YAXSHI PR BELGILARI:
   KICHIK (200-400 qator — katta PR review qiyin, sifatsiz)
   BITTA maqsad (bir xususiyat/tuzatish — aralash emas)
   ANIQ TAVSIF (nima, nega, qanday — reviewer kontekst tushunsin)
   O'ZI tekshirilgan (PR ochishdan oldin o'zingiz ko'rib chiqing)
   TEST bor (yangi kod — test bilan)
   CI yashil (test/lint o'tgan — reviewer'ni vaqtini tejash)

  PR TAVSIFI (yaxshi):
  ## Nima
  Login formasiga rate limiting qo'shildi
  ## Nega
  Brute force hujumini oldini olish 14.8-bob
  ## Qanday
  Upstash rate limit, 5/daqiqa har IP
  ## Test
  Rate limit test qo'shildi; qo'lda sinab ko'rildi

   Yaxshi PR — kichik, bitta maqsad, aniq tavsif, test, CI yashil (review oson/sifatli)
   Katta PR (1000+ qator) — review qiyin, yuzaki ("LGTM" — o'qilmay) — KICHIK qil

PR yaxshi yozish — review olishni osonlashtirish. Yaxshi PR — reviewer ishini osonlashtiradi (tez, sifatli review olasiz). Yaxshi PR belgilari: (1) kichik (200-400 qator — katta PR review qiyin — reviewer 1000+ qatorni sinchkov o'qiy olmaydi — yuzaki review, "LGTM" — Looks Good To Me — o'qilmay tasdiq); (2) bitta maqsad (bir xususiyat yoki tuzatish — aralash emas — "login + dizayn + refactoring" bir PR'da — chalkash); (3) aniq tavsif (nima, nega, qanday — reviewer kontekst tushunsin — kod nima uchun, qaror nega); (4) o'zi tekshirilgan (PR ochishdan oldin o'zingiz diff'ni ko'rib chiqing — keraksiz, debug kod, xato yo'qmi); (5) test bor (yangi kod — test bilan — 11.17); (6) CI yashil (test/lint/build o'tgan — reviewer buzuq kodni tekshirmasin — vaqt tejash). PR tavsifi (yaxshi): ## Nima (qisqa — "login formasiga rate limiting"), ## Nega (sabab — "brute force oldini"), ## Qanday (yondashuv — "Upstash, 5/daqiqa"), ## Test (qanday sinash). Ikki nuqta: (1) yaxshi PR — kichik, bitta maqsad, aniq tavsif, test, CI yashil (review oson va sifatli); (2) katta PR (1000+ qator) — review qiyin, yuzaki (o'qilmay "LGTM") — kichik qil (katta xususiyatni bir necha kichik PR'ga bo'l). Kichik PR — eng muhim (kichik PR = sinchkov review = yaxshi sifat; katta PR = yuzaki review = xato o'tadi). Bu PR yozuvchining mas'uliyati (reviewer ishini osonlashtirish — o'zi tekshirib, kichik, aniq, test bilan). Yaxshi PR — hurmat (reviewer vaqtini qadrlash) va sifat (sinchkov review imkoni). Code review sifati ko'p jihatdan PR sifatiga bog'liq (yaxshi PR — yaxshi review).

2.3. Review berish (konstruktiv fikr)

  REVIEW BERISH — KONSTRUKTIV, hurmatli fikr (kodni yaxshilash, odamni emas):

   YAXSHI FIKR (konstruktiv):
   "Bu funksiya katta ko'rinadi — kichikroqqa bo'lsak o'qish osonroq bo'larmidi?"
   "Bu yerda null bo'lishi mumkin — tekshirsak yaxshi bo'lardi (NullPointer xavfi)"
   "Yaxshi yondashuv! Bir taklif: nomni `x` o'rniga `count` qilsak aniqroq"
   KOD haqida, savol/taklif shaklida, sababli, hurmatli

   YOMON FIKR (destruktiv):
   "Bu axlat kod" (shaxsiy, qo'pol)
   "Nega bunday yozding?" (ayblovchi)
   "Hammasini qayta yoz" (yo'naltirishsiz)

  FIKR DARAJALARI (ustuvorlik belgila):
   BLOKLOVCHI (must fix — bug, zaiflik) — tuzatilmasa merge yo'q
   TAKLIF (should — yaxshilash) — yaxshi bo'lardi, lekin majburiy emas
   NIT (nitpick — kichik) — "ixtiyoriy: bo'shliq" (belgila — "nit:")
   MAQTOV (yaxshi narsani ham ayt — "bu yondashuv zo'r!")

   Review berish — kod haqida (odam emas), konstruktiv (savol/taklif), sababli, hurmatli
   Ustuvorlik belgila (bloklovchi vs taklif vs nit); maqtov ham (faqat tanqid emas)

Review berish (konstruktiv fikr) — qanday fikr berish (eng nozik qism). Fikr konstruktiv, hurmatli bo'lishi kerak (maqsad — kodni yaxshilash, odamni emas). Yaxshi fikr (konstruktiv): "Bu funksiya katta ko'rinadi — kichikroqqa bo'lsak o'qish osonroq bo'larmidi?" (savol/taklif — qatiy buyruq emas), "Bu yerda null bo'lishi mumkin — tekshirsak yaxshi (NullPointer xavfi)" (sababli — nega), "Yaxshi yondashuv! Bir taklif: x count aniqroq" (maqtov + taklif) — kod haqida, savol/taklif shaklida, sababli, hurmatli. Yomon fikr (destruktiv): "Bu axlat kod" (shaxsiy, qo'pol — ranjitadi), "Nega bunday yozding?" (ayblovchi — himoyaga o'tkazadi), "Hammasini qayta yoz" (yo'naltirishsiz — qanday?). Fikr darajalari (ustuvorlik belgila — reviewer nima muhim, nima ixtiyoriy ekanini ko'rsatsin): (1) bloklovchi (must fix — bug, zaiflik, jiddiy muammo — tuzatilmasa merge yo'q); (2) taklif (should — yaxshilash — yaxshi bo'lardi, lekin majburiy emas); (3) nit (nitpick — kichik — "ixtiyoriy: bo'shliq" — belgila "nit:" — dasturchi bilsin kichik); (4) maqtov (yaxshi narsani ham ayt — "bu yondashuv zo'r!" — faqat tanqid emas — balans). Ikki nuqta: (1) review berish — kod haqida (odam emas), konstruktiv (savol/taklif — buyruq emas), sababli (nega), hurmatli; (2) ustuvorlik belgila (bloklovchi vs taklif vs nit — dasturchi nima muhim biladi), maqtov ham (faqat tanqid emas — balans, motivatsiya). Review berish — eng nozik mahorat (kodni yaxshilash, lekin odamni ranjitmaslik). Savol shakli ("...bo'larmidi?") buyruqdan yaxshiroq (muhokama ochadi — balki dasturchining sababi bor). Maqtov muhim (faqat tanqid — demotivatsiya; maqtov + tanqid — balans, o'rganish). Bu — jamoani kuchaytiradigan review (hurmatli, o'rgatuvchi) — buzadigan emas (qo'pol, ayblovchi).

2.4. Review olish (qanday qabul qilish)

  REVIEW OLISH — fikrni TO'G'RI qabul qilish (o'rganish, himoyalanmaslik):

   YAXSHI QABUL:
   Fikrni O'RGANISH imkoni deb ko'r (tanqid emas — yaxshilanish)
   Kod = siz EMAS (kodga tanqid — sizga emas; ajrat)
   Savol ber (tushunmasang — "nega? qanday yaxshiroq?")
   Rozi bo'lmasang — sababli muhokama (ego emas — dalil)
   Rahmat ayt (reviewer vaqt sarfladi)

   YOMON QABUL:
   Himoyaga o'tish ("men to'g'ri yozdim!")
   Shaxsan qabul qilish (ranjish — "meni tanqid qildi")
   E'tiborsizlik (fikrni o'qilmay yopish)

  REVIEW MUHOKAMASI:
   Kelishmovchilik — normal (muhokama, dalil — eng yaxshi yechim topish)
   Reviewer ham xato qilishi mumkin (ikki tomonli o'rganish)
   Murakkab masala — yuzma-yuz (chat'da emas — tezroq hal)

   Review olish — o'rganish imkoni (tanqid emas); kod ≠ siz (ajrat); savol/muhokama
   Himoyaga o'tmang, shaxsan olmang; rozi bo'lmasangiz — sababli (ego emas — dalil)

Review olish (qanday qabul qilish) — fikrni to'g'ri qabul qilish. Review olish ham mahorat (yangi dasturchi uchun qiyin — "kodimni tanqid qilishadi"). Yaxshi qabul: (1) fikrni o'rganish imkoni deb ko'r (tanqid emas — yaxshilanish — har fikr o'rganish); (2) kod = siz emas (kodga tanqid — sizga emas — ajrat — kod yaxshilanishi sizning yaxshilanishingiz — ego emas); (3) savol ber (tushunmasangiz — "nega? qanday yaxshiroq?" — o'rganish); (4) rozi bo'lmasangiz — sababli muhokama (ego emas — dalil bilan — "men shunday qildim chunki..." — balki sabab bor); (5) rahmat ayt (reviewer vaqt sarfladi — kodingizni o'qib yaxshilashga yordam berdi). Yomon qabul: (1) himoyaga o'tish ("men to'g'ri yozdim!" — muhokamani yopadi); (2) shaxsan qabul qilish (ranjish — "meni tanqid qildi" — kod ≠ siz); (3) e'tiborsizlik (fikrni o'qilmay yopish — sifat yo'qoladi). Review muhokamasi: (1) kelishmovchilik normal (muhokama, dalil — eng yaxshi yechim topish — reviewer va dasturchi birga); (2) reviewer ham xato qilishi mumkin (ikki tomonli — reviewer ham o'rganadi — review — dialog, monolog emas); (3) murakkab masala — yuzma-yuz (chat'da uzoq munozara o'rniga — tez gaplashib hal). Ikki nuqta: (1) review olish — o'rganish imkoni (tanqid emas); kod ≠ siz (ajrat — shaxsan olmang); savol/muhokama; (2) himoyaga o'tmang, shaxsan olmang; rozi bo'lmasangiz — sababli (ego emas — dalil). Review olish — kamtarlik va o'sish (har fikr — yaxshilanish imkoni; ego — to'siq). Eng yaxshi dasturchilar review'ni xohlaydi (o'z kodini yaxshilash — boshqalar topgan narsani). Yangi dasturchi uchun bu odat (kod ≠ siz, fikr = o'rganish) — professional o'sishning kaliti. Review — birga yaxshilanish (reviewer va dasturchi — bir maqsad: yaxshi kod).

2.5. Nima tekshirish (review checklist)

  REVIEW'DA NIMA TEKSHIRISH (avtomatik EMAS — odam ko'radigan):

  AVTOMATIK (CI — odam tekshirmaydi — 2.7):
   Format (Prettier), uslub (ESLint), test o'tadi, build, xavfsizlik (npm audit)

  ODAM TEKSHIRADIGAN (review'ning asosi):
  1. TO'G'RILIK — kod maqsadni bajaradimi? Edge case'lar? (mantiq)
  2. DIZAYN — yondashuv to'g'rimi? Soddaroq usul bormi? (arxitektura)
  3. O'QILUVCHANLIK — tushunarlimi? Nom, struktura 15.1-bob
  4. XAVFSIZLIK — zaiflik bormi? (injection, auth — 14-QISM)
  5. TEST — yetarlimi? Edge case test? 11.17-bob
  6. MA'LUMOT/XATO — ma'lumot to'g'ri? Xato boshqaruvi?
  7. PERFORMANCE — sezilarli muammo? (N+1, keraksiz so'rov)

  TEKSHIRMA (vaqt isrofi):
   Format/bo'shliq (Prettier qiladi — 2.7)
   Uslub (ESLint qiladi)
   odam — MANTIQ, dizayn, xavfsizlik (mashina qila olmaydigan)

   Review'da — to'g'rilik, dizayn, o'qiluvchanlik, xavfsizlik, test (odam ko'radigan)
   Format/uslub — avtomatik (CI); odam — mantiq/dizayn (mashina qila olmaydigan)

Nima tekshirish (review checklist) — review'da odam nima tekshirishi kerak. Muhim: avtomatlashtiriladigan narsani (format, uslub) odam tekshirmasin (mashina qiladi — 2.7), odam mashina qila olmaydigan narsaga fokuslansin (mantiq, dizayn). Avtomatik (CI — odam tekshirmaydi): format (Prettier — 15.3), uslub (ESLint), test o'tadi, build, xavfsizlik (npm audit — 14.9). Odam tekshiradigan (review'ning asosi): (1) to'g'rilik — kod maqsadni bajaradimi? Edge case'lar (chekka holatlar — bo'sh massiv, null, katta son)? — mantiq; (2) dizayn — yondashuv to'g'rimi? Soddaroq usul bormi? — arxitektura (15.1: SOLID); (3) o'qiluvchanlik — tushunarlimi? Nom, struktura 15.1-bob; (4) xavfsizlik — zaiflik bormi? (injection, auth, secret — 14-QISM); (5) test — yetarlimi? Edge case test 11.17-bob?; (6) ma'lumot/xato — ma'lumot to'g'ri ishlanadimi? Xato boshqaruvi bormi?; (7) performance — sezilarli muammo (N+1 so'rov, keraksiz hisoblash — 13.7)? Tekshirma (vaqt isrofi): format/bo'shliq (Prettier qiladi), uslub (ESLint) — bularni odam tekshirsa — vaqt isrofi (mashina yaxshiroq, izchil qiladi). Ikki nuqta: (1) review'da — to'g'rilik, dizayn, o'qiluvchanlik, xavfsizlik, test (odam ko'radigan — mantiq, kontekst); (2) format/uslub — avtomatik (CI — 2.7); odam — mantiq/dizayn (mashina qila olmaydigan — bu yerda odam qiymatli). Bu farq muhim: ko'p review vaqti format/uslub munozarasiga ketadi (vaqt isrofi — bu avtomatlashtiriladi — 15.3 linter), odam esa muhim narsaga (mantiq, xavfsizlik, dizayn — mashina qila olmaydigan) fokuslansin. Linter/formatter 15.3-bob review'ni format munozarasidan ozod qiladi (odam mantiqqa). Review checklist — odam nimaga e'tibor berishini yo'naltiradi (to'g'rilik, xavfsizlik, dizayn — eng qiymatli). Eng yaxshi review — mantiq va dizaynga fokuslangan (format emas — u avtomatik).

2.6. Review madaniyati (hurmat, balans)

  REVIEW MADANIYATI — sog'lom jamoa (hurmat, balans, hamkorlik):

  MADANIYAT PRINTSIPLARI:
   HURMAT (kod haqida, odam emas — 2.3; psixologik xavfsizlik)
   KAMTARLIK (hech kim mukammal emas — hamma xato qiladi; review = o'sish)
   HAMKORLIK (reviewer va dasturchi BIR maqsad — yaxshi kod, raqib emas)
   TEZ (review'ni cho'zma — PR uzoq kutsa, jamoa sekinlashadi — 1 kun ichida)
   TENGLIK (junior ham senior kodini review qila oladi — o'rganish)

  BALANS (haddan oshma):
   Juda qattiq (har nuqta — demotivatsiya, sekin) vs juda yumshoq (sifat yo'q)
   "Yetarli yaxshi" (mukammal emas — ish bajarilsin, lekin sifatli)
   Nit'larni belgila ("nit:" — kichik, ixtiyoriy)

  XATO MADANIYAT BELGILARI:
   Qo'pol/shaxsiy tanqid (ranjitadi)
   Review'ni cho'zish (PR hafta kutadi — bloklaydi)
   "Rubber stamp" (o'qilmay "LGTM" — sifat yo'q)
   Ego janglari (kim haq — eng yaxshi yechim emas)

   Review madaniyati — hurmat, kamtarlik, hamkorlik, tez, tenglik (sog'lom jamoa)
   Balans — qattiq emas, yumshoq emas; "yetarli yaxshi"; ego emas — yaxshi kod

Review madaniyati (hurmat, balans) — sog'lom code review jamoasi. Madaniyat printsiplari: (1) hurmat (kod haqida, odam emas — 2.3 — psixologik xavfsizlik — odamlar qo'rqmasdan kod yozsin, fikr aytsin, xato qilsin); (2) kamtarlik (hech kim mukammal emas — eng tajribali ham xato qiladi — review = o'sish, ayb emas); (3) hamkorlik (reviewer va dasturchi bir maqsad — yaxshi kod — raqib emas — "men sizga qarshi" emas, "biz yaxshi kod uchun"); (4) tez (review'ni cho'zma — PR uzoq kutsa — dasturchi bloklanadi, jamoa sekinlashadi — 1 kun ichida review — yaxshi norma); (5) tenglik (junior ham senior kodini review qila oladi — o'rganish — har kim fikr bera oladi). Balans (haddan oshma): (1) juda qattiq (har kichik nuqta — demotivatsiya, sekin) vs juda yumshoq (hammasini o'tkazib — sifat yo'q); (2) "yetarli yaxshi" (mukammal emas — ish bajarilsin, lekin sifatli — cheksiz mukammallik — vaqt isrofi); (3) nit'larni belgila ("nit:" — kichik, ixtiyoriy — dasturchi bilsin majburiy emas). Xato madaniyat belgilari: qo'pol/shaxsiy tanqid (ranjitadi — psixologik xavfsizlik yo'q), review'ni cho'zish (PR hafta kutadi — bloklaydi), "rubber stamp" (o'qilmay "LGTM" — sifat yo'q — review nomiga), ego janglari (kim haq — eng yaxshi yechim emas — vaqt isrofi). Ikki nuqta: (1) review madaniyati — hurmat, kamtarlik, hamkorlik, tez, tenglik (sog'lom jamoa — odamlar o'sadi); (2) balans — qattiq emas, yumshoq emas ("yetarli yaxshi"); ego emas — yaxshi kod (maqsad). Review madaniyati — jamoa sog'ligining ko'rsatkichi (yaxshi review — odamlar o'rganadi, sifat oshadi, jamoa kuchli; yomon review — qo'rquv, ranjish, sekinlik). Psixologik xavfsizlik (Google tadqiqoti — eng yaxshi jamoalar belgisi) — odamlar qo'rqmasdan xato qil oladi, fikr ayta oladi (review qo'pol bo'lsa — qo'rquv — innovatsiya yo'q). Bu — texnik mahoratdan tashqari (insoniy mahorat — hurmat, hamkorlik). Eng yaxshi jamoalar — review'ni o'sish vositasi qiladi (tanqid emas — birga yaxshilanish).

2.7. Avtomatlashtirish va best practices

  AVTOMATLASHTIRISH — odam vaqtini muhim narsaga (mashina mexanikni qiladi):

  AVTOMATLASHTIRILADIGAN (review'dan olib tashlash):
   FORMAT — Prettier (bo'shliq, qator — avtomatik — 15.3)
   USLUB — ESLint (kod qoidalari — 15.3)
   TEST — CI (avtomatik o'tadi — 10.9)
   XAVFSIZLIK — npm audit, SAST 14.9-bob
   TYPE — TypeScript (tip xatolari)
   bular CI'da (PR yashil bo'lgach odam review)

  ODAM (qiymatli — mashina qila olmaydigan):
   mantiq, dizayn, kontekst, xavfsizlik fikri, o'qiluvchanlik

  BEST PRACTICES:
   Kichik PR (review oson — 2.2)
   Konstruktiv fikr (kod haqida — 2.3)
   O'rganib qabul (kod ≠ siz — 2.4)
   Mantiq/dizayn tekshir (format avtomatik — 2.5)
   Hurmat, tez (madaniyat — 2.6)
   Linter/CI (format/uslub avtomatik — 15.3)

   Avtomatlashtir — format/uslub/test (CI); odam — mantiq/dizayn (qiymatli)
   Best — kichik PR + konstruktiv + o'rganib qabul + hurmat + linter/CI

Avtomatlashtirish va best practices — code review'ni samarali qilish. Avtomatlashtirish — odam vaqtini muhim narsaga yo'naltirish (mashina mexanik narsani qiladi — izchil, tez, charchamaydi). Avtomatlashtiriladigan (review'dan olib tashlash — odam tekshirmasin): format (Prettier — bo'shliq, qator, qoidalar — avtomatik — 15.3), uslub (ESLint — kod qoidalari — 15.3), test (CI — avtomatik o'tadi — 10.9), xavfsizlik (npm audit, SAST — 14.9), type (TypeScript — tip xatolari) — bular CI'da (PR yashil bo'lgach, odam review qiladi — buzuq kodni odam tekshirmaydi). Odam (qiymatli — mashina qila olmaydigan): mantiq (kod to'g'ri ishlaydimi), dizayn (yondashuv to'g'rimi), kontekst (biznes mantiq), xavfsizlik fikri (potensial zaiflik — mashina topa olmaydigan), o'qiluvchanlik (tushunarlimi). Best practices (butun bobni umumlashtiradi): kichik PR (review oson — 2.2), konstruktiv fikr (kod haqida — 2.3), o'rganib qabul (kod ≠ siz — 2.4), mantiq/dizayn tekshir (format avtomatik — 2.5), hurmat va tez (madaniyat — 2.6), linter/CI (format/uslub avtomatik — 15.3). Ikki nuqta: (1) avtomatlashtir — format/uslub/test (CI — mashina); odam — mantiq/dizayn (qiymatli — odam vaqti bu yerda sarflansin); (2) best — kichik PR + konstruktiv + o'rganib qabul + hurmat + linter/CI. Avtomatlashtirish — review sifatini oshiradi (odam format munozarasiga emas — mantiqqa vaqt sarflaydi — qiymatli) va tezlashtiradi (CI darrov — odam keyin). Bu — DevOps/professional jamoaning standarti (linter/CI — format/uslub/test avtomatik; odam — mantiq/dizayn/xavfsizlik). Code review — texnik (nima tekshir — 2.5) + madaniy (qanday muloqot — 2.3, 2.4, 2.6) + avtomatlashtirilgan (mashina mexanikni — 2.7) — uchalasi birga samarali, sog'lom review. Bu — jamoada professional ishlashning asosiy ko'nikmasi (kod yozish + review berish/olish + sog'lom madaniyat).

2.8. Commit, PR va Git/GitHub/GitLab jarayoni (4-QISM cross-ref)

  CODE REVIEW — Git jarayoni ustida quriladi (4-QISM: branch, commit, PR/MR):

  ATOMIK COMMIT (bitta commit — bitta mantiqiy o'zgarish):
   "hammasini tuzatdim" (100 fayl, aralash — history o'qib bo'lmaydi)
   "auth: rate limit qo'shildi" + "auth: rate limit testi" (ajratilgan)
   reviewer commit-commit o'qiy oladi (o'zgarish evolutsiyasini ko'radi)

  CONVENTIONAL COMMIT (standart format — 4-QISM):
  <turi>(<qamrov>): <qisqa tavsif>
  feat(auth): rate limiting qo'shildi        (yangi xususiyat)
  fix(cart): narx yaxlitlash xatosi tuzatildi (tuzatish)
  refactor(api): qidiruv funksiyasi ajratildi (qayta tuzish)
  test / docs / chore / perf / style          (boshqa turlar)
   avtomatik changelog, semantik versiya, o'qish oson

  WIP (Work In Progress — tugallanmagan PR):
   "Draft PR" (GitHub) / "Draft MR" (GitLab) — hali review kutmaydi
   erta fikr uchun ("yondashuvim to'g'rimi?") — to'liq review emas
   tayyor bo'lgach "Ready for review" — reviewer taklif qilinadi

  GITHUB PR ~ GITLAB MR (bir tushuncha, boshqa nom):
   PR (Pull Request) / MR (Merge Request) — branch'ni main'ga qo'shish so'rovi
   CODEOWNERS fayli — qaysi fayl kim tomonidan review qilinishi (avtomatik reviewer)

   Atomik commit + conventional commit — review va history o'qishni osonlashtiradi
   WIP/Draft — erta fikr uchun; PR (GitHub) va MR (GitLab) — bir tushuncha

Commit, PR va Git jarayoni — code review Git ustida quriladi (4-QISM). Atomik commit — bitta commit bitta mantiqiy o'zgarishni o'z ichiga oladi: "hammasini tuzatdim" (100 fayl, aralash — history o'qib bo'lmaydi, revert qiyin) o'rniga "auth: rate limit qo'shildi" + alohida "auth: rate limit testi" — reviewer commit-commit o'qiy oladi (o'zgarish qadamma-qadam ko'rinadi), muammoli commit'ni alohida revert qilish mumkin. Conventional commit (standart format — 4-QISM): <turi>(<qamrov>): <tavsif> — feat (yangi xususiyat), fix (tuzatish), refactor, test, docs, chore, perf, style — bu format avtomatik changelog va semantik versiya (SemVer) generatsiyasiga imkon beradi, va commit tarixini o'qishni osonlashtiradi (reviewer commit turini darrov ko'radi). WIP (Work In Progress) — tugallanmagan PR: GitHub'da "Draft PR", GitLab'da "Draft MR" — hali to'liq review kutmaydi (erta fikr uchun — "yondashuvim to'g'rimi?" — arxitekturaviy qaror bo'yicha erta muhokama, ko'p ish qilingandan keyin qayta yozishdan saqlaydi); tayyor bo'lgach "Ready for review" bosiladi (reviewer taklif qilinadi). GitHub PR va GitLab MR — bir tushuncha, boshqa nom (Pull Request / Merge Request — ikkalasi ham branch'ni asosiy tarmoqqa qo'shish so'rovi — review + muhokama + merge). CODEOWNERS fayli — qaysi fayl/papka kim tomonidan review qilinishini belgilaydi (masalan /auth/ @security-team — auth o'zgarishi avtomatik xavfsizlik jamoasiga yuboriladi) — bu review'ni to'g'ri odamga yo'naltiradi (kontekstni biladigan). Ikki nuqta: (1) atomik commit + conventional commit — review va history o'qishni osonlashtiradi (bitta o'zgarish = bitta commit; standart format); (2) WIP/Draft — erta fikr uchun; PR (GitHub) va MR (GitLab) — bir tushuncha. Yaxshi commit tarixi — yaxshi PR'ning asosi (reviewer diff'ni emas, o'zgarish hikoyasini o'qiydi — nima, qanday ketma-ketlikda). Bu — 4-QISM (Git) bilan bevosita bog'liq (branch commit PR review merge — bir oqim).

2.9. Review formati: sync/async, pair/mob, statuslar, metrika

  REVIEW TURLARI VA FORMATI:

  ASYNC REVIEW (standart — PR orqali, yozma):
   Vaqt moslashuvchan (reviewer o'zi qulay vaqtda), yozma iz (hujjat)
   Sekinroq (oldinga-orqaga yozishma), nozik ohang yo'qolishi mumkin

  SYNC REVIEW (yuzma-yuz / ekran ulashish):
   Tez (murakkab masala — darrov muhokama), ohang aniq
   Iz yo'q, ikkalasi bir vaqtda bo'lishi kerak
   QOIDA: oddiy — async; murakkab/ko'p oldinga-orqaga — sync 2.4-bob

  PAIR / MOB PROGRAMMING (review MUQOBILI):
   Pair — 2 kishi birga yozadi (real-vaqt review — alohida PR review shart emas)
   Mob — butun jamoa birga (murakkab masala, bilim ulashish)
   afzallik: darrov fikr; kamchilik: 2+ odam vaqti bir masalada

  PR STATUSLARI (GitHub/GitLab):
   APPROVE      — tayyor, merge mumkin (roziman)
  ⟳ COMMENT      — fikr bor, lekin bloklamayman (ko'rib chiq)
   REQUEST CHANGES — bloklovchi muammo (tuzatilsin, keyin merge)

  METRIKA (o'lchash — lekin ehtiyot: metrikani o'yinga aylantirmaslik):
   Review vaqti (PR ochilgandan approve'gacha — qancha kutdi)
   PR hajmi (kichikroq — yaxshiroq)
   Fikr soni — sifat ko'rsatkichi EMAS (ko'p ≠ yaxshi)

   Async — standart (yozma, moslashuvchan); sync — murakkab masala (tez)
   Statuslar: approve / comment / request-changes; metrika — vaqt/hajm (ehtiyot)

Review formati — review qanday o'tkaziladi. Async review (asinxron — standart — PR orqali, yozma fikr): reviewer o'ziga qulay vaqtda ko'radi (vaqt moslashuvchan — turli vaqt zonasi, chuqur ish uzilmaydi), yozma iz qoladi (hujjat — keyin qaralishi mumkin) — lekin sekinroq (oldinga-orqaga yozishma) va nozik ohang yozuvda yo'qolishi mumkin ("bu noto'g'ri" — yozuvda qo'polroq eshitiladi). Sync review (sinxron — yuzma-yuz yoki ekran ulashish): tez (murakkab masalani darrov muhokama), ohang aniq (yuz ifodasi, ovoz — kamroq noto'g'ri tushuniladi) — lekin iz qolmaydi va ikkalasi bir vaqtda bo'lishi kerak. Qoida: oddiy o'zgarish — async (samarali); murakkab yoki ko'p oldinga-orqaga muhokama talab qiladigan — sync (2.4 — "yuzma-yuz gaplashsakmi?"). Pair/mob programming (review muqobili): pair programming — ikki kishi bitta kompyuterda birga yozadi (biri yozadi, biri kuzatadi — real-vaqt review — kod yozilayotganda tekshiriladi, alohida PR review ba'zan shart emas); mob programming — butun jamoa birga bitta masala ustida (murakkab arxitektura qarori, bilim ulashish) — afzallik: darrov fikr, umumiy egalik; kamchilik: bir necha odam vaqti bir masalaga sarflanadi (har doim samarali emas — oddiy ish uchun ortiqcha). PR statuslari (GitHub/GitLab): approve (tasdiq — kod tayyor, merge mumkin — roziman), comment (izoh — fikr bor, lekin bloklamayman — dasturchi ko'rib chiqsin, o'zi qaror qilsin), request changes (o'zgartirish so'rash — bloklovchi muammo bor — tuzatilsin, keyin qayta review va merge). Metrika (review'ni o'lchash — jamoa sog'ligini kuzatish): review vaqti (PR ochilgandan approve'gacha — uzoq kutish = bloklash muammosi — 2.6), PR hajmi (kichikroq — yaxshiroq — 2.2), fikr soni — lekin fikr soni sifat ko'rsatkichi emas (ko'p fikr ≠ yaxshi review — nitpicking ham ko'p fikr beradi). Metrikani ehtiyot bilan (Goodhart qonuni — "metrika maqsadga aylansa, u yomon metrika bo'ladi"): agar "review vaqti" metrika bo'lsa — odamlar shoshib "LGTM" bosishi mumkin (rubber-stamp — 2.6); metrika — kuzatish uchun, nazorat/jazolash uchun emas. Ikki nuqta: (1) async — standart (yozma, moslashuvchan); sync — murakkab masala (tez, ohang aniq); pair/mob — real-vaqt muqobili; (2) statuslar: approve / comment / request-changes; metrika — vaqt/hajm (ehtiyot — o'yin qilinmasin). Review formatini masalaga moslash — samaralilik (oddiy — async; murakkab — sync yoki pair) — bitta usul hamma holatga to'g'ri kelmaydi.

3. Sintaksis — review tez ma'lumotnoma

PR 2.2-bob:           kichik (200-400 qator), bitta maqsad, aniq tavsif, test, CI yashil
FIKR BERISH 2.3-bob:  konstruktiv (savol/taklif), sababli, hurmatli; ustuvorlik belgila
FIKR DARAJASI 2.3-bob:bloklovchi (must) | taklif (should) | nit: (kichik) | maqtov
QABUL 2.4-bob:        o'rganish imkoni; kod ≠ siz; savol/muhokama; himoyaga o'tmang
TEKSHIR 2.5-bob:      to'g'rilik, dizayn, xavfsizlik, o'qiluvchanlik (format AVTO)
AVTO 2.7-bob:         Prettier (format), ESLint (uslub), CI (test) — odam emas
MADANIYAT 2.6-bob:    hurmat, kamtarlik, hamkorlik, tez, "yetarli yaxshi"
COMMIT 2.8-bob:       atomik (1 o'zgarish); conventional: feat/fix/refactor/test
WIP 2.8-bob:          Draft PR/MR — erta fikr; PR (GitHub) ~ MR (GitLab)
FORMAT 2.9-bob:       async (standart) | sync (murakkab) | pair/mob (real-vaqt)
STATUS 2.9-bob:       approve | comment | request-changes
CONV. COMMENT:      praise / nit / suggestion / issue / question (belgi + izoh)

4. Batafsil misollar

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

Misol 1 — Yaxshi PR tavsifi (2.2)

Maqsad: Reviewer kontekstni tez tushunadigan PR tavsifi yozish. Bu review'ni tez va sifatli qiladi.

## Nima
Foydalanuvchi profil rasmini yuklash xususiyati qo'shildi.

## Nega
Foydalanuvchilar avatar qo'ya olishni so'rashdi (#142 issue).

## Qanday
- Cloudinary'ga yuklash (server proxy orqali — kalit yashirin, 14.6)
- Rasm validatsiya: faqat jpg/png, max 5MB (xavfsizlik — 14.3)
- Server Action `uploadAvatar` (13.5)
- Optimistic UI (darrov ko'rinadi — 13.5)

## Test
- Validatsiya testlari (noto'g'ri format/hajm rad)
- Qo'lda: yuklash, almashtirish sinab ko'rildi

## Skrinshot
[avatar yuklash UI rasmi]

## Eslatma
SVG'ni qo'shmadim (XSS xavfi — 14.2) — keyingi PR'da sanitizatsiya bilan

Bu nima ko'rsatadi: Bu — yaxshi PR tavsifi (2.2 — review olishni osonlashtirish). Tavsif strukturasi reviewer ishini osonlashtiradi: (1) Nima — qisqa, aniq (avatar yuklash — reviewer darrov biladi nima qilinganini); (2) Nega — sabab (foydalanuvchi so'rovi, issue #142 — kontekst — nega kerak); (3) Qanday — yondashuv (Cloudinary, validatsiya, Server Action — reviewer texnik qarorlarni ko'radi, va xavfsizlik e'tibori — kalit yashirin, format validatsiya — ko'rsatilgan); (4) Test — qanday sinalgan (validatsiya testlari + qo'lda — reviewer ishonadi); (5) Skrinshot — UI o'zgarishi (vizual — reviewer ko'radi); (6) Eslatma — qaror sabablari (SVG qo'shilmagani — XSS xavfi — reviewer bilsin nega yo'q, va kelajak rejasi). Nega bu yaxshi: reviewer kontekst bilan boshlaydi (nima, nega — kod o'qishdan oldin tushunadi), texnik qarorlarni ko'radi (qanday — yondashuv to'g'rimi), va e'tibor nuqtalari berilgan (xavfsizlik, eslatma — reviewer nimaga qarashni biladi). Bu kontekstsiz PR (faqat kod — "avatar qo'shdim")dan ancha yaxshi (reviewer kodni o'qib, nima/nega'ni o'zi taxmin qilishi kerak — sekin, xato). Yaxshi tavsif — reviewer'ga hurmat (vaqtini tejash) va sifat (kontekst bilan yaxshi review). PR tavsifi — kichik harakat (5 daqiqa yozish), lekin katta ta'sir (review tez, sifatli, kam savol). Professional dasturchi har PR'ga aniq tavsif yozadi (kod o'zi yetarli emas — kontekst kerak). Bu — review jarayonining muhim qismi (yaxshi PR — yaxshi review).

Misol 2 — Konstruktiv vs destruktiv fikr (2.3)

Maqsad: Bir muammoni konstruktiv va destruktiv tarzda ko'rsatib, farqni anglash. Bu review madaniyatining yuragi.

HOLAT: kod null tekshirmaydi (potensial xato)

 DESTRUKTIV (ranjitadi, yordam bermaydi):
"Bu kod buziladi. Null haqida o'ylamaganmisan?"
"Yana null tekshirmading."
"Bu noto'g'ri."

 KONSTRUKTIV (kodni yaxshilaydi, hurmatli):
"`user.profile` bu yerda null bo'lishi mumkin (masalan yangi foydalanuvchi) —
 tekshirsak yaxshi bo'lardi, aks holda `Cannot read property` xatosi chiqishi mumkin.
 Masalan: `user.profile?.name ?? 'Mehmon'`"

 farq:
  - DESTRUKTIV: ayblovchi ("o'ylamaganmisan"), sababsiz, yechimsiz
  - KONSTRUKTIV: sababli (nega null), oqibat (qanday xato), yechim (masalan)

BOSHQA MISOLLAR:

 "Bu funksiya juda uzun va chalkash."
 "Bu funksiya 3 ta vazifani bajaryapti (validatsiya, saqlash, email) —
    ularni alohida funksiyaga ajratsak o'qish/test osonroq bo'larmidi? 15.1-bob"

 "Nima uchun Redux ishlatding? Keraksiz."
 "Bu holatda oddiy useState yetarli ko'rinadi — Redux qo'shimcha murakkablik.
    Yoki men nimanidir o'tkazib yuboryapmanmi? (global kerakmi?)"

Bu nima ko'rsatadi: Bu — konstruktiv va destruktiv fikrning farqi (2.3 — review madaniyatining yuragi). Holat: kod null tekshirmaydi (potensial xato — reviewer buni ko'rdi). Destruktiv fikr: "Null haqida o'ylamaganmisan?" (ayblovchi — savol shaklida, lekin hujum — dasturchini himoyaga o'tkazadi), "Bu noto'g'ri" (sababsiz, yechimsiz — nima qilish?). Bu fikrlar muammoni ko'rsatadi, lekin: ranjitadi (shaxsiy — "o'ylamaganmisan"), yordam bermaydi (sababsiz, yechimsiz). Konstruktiv fikr: "user.profile null bo'lishi mumkin (masalan yangi foydalanuvchi) — tekshirsak yaxshi bo'lardi, aks holda Cannot read property xatosi. Masalan: user.profile?.name ?? 'Mehmon'" — bu sababli (nega null — yangi foydalanuvchi), oqibat (qanday xato — Cannot read property), yechim (masalan kod), hurmatli (savol/taklif — "yaxshi bo'lardi"). Farq aniq: destruktiv — ayblovchi, sababsiz, yechimsiz (ranjitadi, o'rgatmaydi); konstruktiv — sababli, oqibatli, yechimli (kodni yaxshilaydi, dasturchini o'rgatadi). Boshqa misollar — bir xil naqsh: destruktiv ("juda uzun va chalkash" — sababsiz tavsif; "nima uchun Redux? keraksiz" — ayblovchi) vs konstruktiv ("3 vazifani bajaryapti — ajratsak osonroq?" — aniq sabab + taklif; "useState yetarli ko'rinadi — yoki men o'tkazib yuboryapmanmi?" — taklif + kamtarlik — balki dasturchining sababi bor). Konstruktiv fikrning formulasi: muammo (aniq) + sabab/oqibat (nega muhim) + taklif/yechim (qanday) + hurmat (savol shakli, kamtarlik). Bu fikr kodni yaxshilaydi (dasturchini ranjitmasdan), va dasturchini o'rgatadi (nega, qanday — keyingi safar biladi). Destruktiv fikr — muammoni ko'rsatadi, lekin zarar (ranjish, himoya). Konstruktiv — eng muhim review mahorati (jamoani kuchaytiradi — hurmat + o'rganish). "Men o'tkazib yuboryapmanmi?" (kamtarlik) — reviewer ham xato qilishi mumkinligini tan oladi (dialog — monolog emas).

Misol 3 — Review fikrlariga javob berish (2.4)

Maqsad: Review fikrlarini professional qabul qilish va javob berish. Bu o'rganish va hamkorlikni ko'rsatadi.

REVIEWER: "Bu funksiya null tekshirmaydi — xato chiqishi mumkin."

 YAXSHI JAVOBLAR:
 "Yaxshi e'tibor! To'g'ri, tuzatdim (optional chaining qo'shdim)."
   (qabul + tuzatish + rahmat)
 "Rahmat! Lekin bu yerda `user` har doim mavjud (auth middleware kafolatlaydi —
   13.6) — shuning uchun null bo'lmaydi. Kommentariya qo'shdim (aniqroq)."
   (sababli muhokama — dalil bilan, ego emas)
 "Tushunmadim — qaysi holatda null bo'lishi mumkin? Misol bera olasizmi?"
   (savol — o'rganish)

 YOMON JAVOBLAR:
 "Men to'g'ri yozdim, null bo'lmaydi." (himoyaga o'tish, sababsiz)
 [javobsiz, fikrni yopish] (e'tiborsizlik)
 "OK" [keyin tuzatmay merge] (soxta qabul)

KELISHMOVCHILIK (normal — hal qilish):
REVIEWER: "Bu yondashuv noto'g'ri, X usulini ishlat."
DASTURCHI: "X usulini o'yladim, lekin Y sababdan bu yondashuvni tanladim
            (performance — X N+1 so'rov qiladi). Lekin agar muhim sabab bo'lsa,
            qayta ko'rib chiqaman. Yuzma-yuz gaplashsakmi?"
 dalil + ochiqlik + murakkabni yuzma-yuz

Bu nima ko'rsatadi: Bu — review fikrlariga professional javob (2.4 — review olish). Reviewer fikriga (null tekshirmaydi) uch yaxshi javob: (1) "Yaxshi e'tibor! Tuzatdim" (qabul + tuzatish + rahmat — reviewer haq, darrov tuzatish — eng oddiy holat); (2) "Rahmat! Lekin bu yerda user har doim mavjud (auth middleware kafolatlaydi) — null bo'lmaydi. Kommentariya qo'shdim" (sababli muhokama — dalil bilan rad — reviewer bilmagan kontekst — auth kafolati, va kod aniqroq qilindi — kommentariya — ego emas, dalil); (3) "Tushunmadim — qaysi holatda null? Misol?" (savol — o'rganish — tushunmasa so'rash). Yomon javoblar: "Men to'g'ri yozdim" (himoyaga o'tish — sababsiz — muhokama yopiladi), [javobsiz] (e'tiborsizlik — sifat yo'qoladi), "OK" + tuzatmay merge (soxta qabul — yomon — ishonchni buzadi). Kelishmovchilik (normal — har review'da bo'lishi mumkin): reviewer "X usulini ishlat" desa, dasturchi dalil bilan javob ("X'ni o'yladim, lekin Y sababdan — performance, X N+1 qiladi"), ochiqlik ("agar muhim sabab bo'lsa, qayta ko'raman"), va murakkabni yuzma-yuz ("yuzma-yuz gaplashsakmi?" — chat'da uzoq munozara o'rniga). Nega bu muhim: review — dialog (monolog emas — reviewer va dasturchi birga eng yaxshi yechim topadi). Yaxshi javob — qabul (reviewer haq bo'lsa) yoki sababli muhokama (dasturchi haq bo'lsa — dalil bilan) yoki savol (tushunmasa). Yomon javob — himoya (ego), e'tiborsizlik (sifat), soxta qabul (ishonchsizlik). Kelishmovchilik normal (ikki professional turli fikr) — uni dalil bilan hal qilinadi (kim baland ovozda emas — kim to'g'ri dalil) va murakkab bo'lsa yuzma-yuz (tez hal). Bu — review olishning professional usuli (o'rganish, hamkorlik, dalil — ego emas). Reviewer va dasturchi — bir maqsad (yaxshi kod), raqib emas.

Misol 4 — Review checklist amalda (2.5)

Maqsad: Real kod o'zgarishini review checklist bo'yicha tekshirib, nima ko'rilishini ko'rsatish. Bu reviewerning fikrlash jarayoni.

PR: "Mahsulot qidiruv API qo'shildi"

REVIEWER FIKRLASH JARAYONI (checklist — 2.5):

1. TO'G'RILIK:
    Qidiruv ishlaydimi? Edge case: bo'sh qidiruv? Maxsus belgilar?
    "Bo'sh qidiruv (`?q=`) holati nima qiladi? Test qo'shsak?"

2. XAVFSIZLIK (14-QISM):
    "Qidiruv so'rovi DB'ga to'g'ridan ketadimi? SQL injection xavfi —
      parametrlangan so'rov kerak 14.3-bob" [BLOKLOVCHI]
    "Rate limit yo'q — qidiruv resurs-og'ir, abuse xavfi 14.8-bob" [TAKLIF]

3. PERFORMANCE:
    "Har qidiruvda butun jadval skanerlanadimi? Index kerak 6.9-bob" [TAKLIF]

4. O'QILUVCHANLIK 15.1-bob:
    "nit: `q` o'rniga `searchQuery` aniqroq" [NIT]

5. TEST:
    "Qidiruv testi yo'q — asosiy holat + edge case qo'shsak?" [TAKLIF]

6. MAQTOV:
    "Pagination yaxshi qo'shilgan! Toza yondashuv."

XULOSA: 1 bloklovchi (SQL injection)  tuzatilsin; qolgani taklif/nit

Bu nima ko'rsatadi: Bu — review checklist amalda (2.5 — reviewerning fikrlash jarayoni). Mahsulot qidiruv API PR'iga reviewer tizimli (checklist bo'yicha) qaraydi: (1) to'g'rilik — qidiruv ishlaydimi, edge case (bo'sh qidiruv, maxsus belgilar)? savol ("bo'sh qidiruv nima qiladi?"); (2) xavfsizlik (14-QISM — eng muhim) — SQL injection xavfi (qidiruv so'rovi DB'ga to'g'ridan? — parametrlangan kerak — 14.3 — bloklovchi — jiddiy zaiflik), rate limit yo'q (resurs-og'ir — 14.8 — taklif); (3) performance — index (butun jadval skanerlanadimi? — 6.9 — taklif); (4) o'qiluvchanlik 15.1-bob — nom (q searchQuery — nit — kichik); (5) test — qidiruv testi (taklif); (6) maqtov — yaxshi narsani ham ayt ("pagination yaxshi qo'shilgan!" — balans). Xulosa: 1 bloklovchi (SQL injection — tuzatilmasa merge yo'q), qolgani taklif/nit (yaxshi bo'lardi, lekin majburiy emas). Nega bu muhim: reviewer tizimli qaraydi (checklist — hech narsani o'tkazib yubormaydi — to'g'rilik, xavfsizlik, performance, o'qiluvchanlik, test) — tasodifiy emas. Va har fikrga ustuvorlik belgilaydi (bloklovchi — SQL injection — jiddiy; taklif — rate limit — yaxshi bo'lardi; nit — nom — kichik) — dasturchi nima muhim, nima ixtiyoriy ekanini biladi (hammasini bir xil ko'rsatsa — chalkash — qaysi muhim?). Maqtov ham (pagination — balans — faqat tanqid emas). Eng muhimi — xavfsizlik (14-QISM)ga e'tibor (SQL injection — bloklovchi — bu review'ning eng katta qiymati — mashina ba'zan topmaydi, odam topadi). Bu — reviewerning ish usuli (checklist — tizimli + ustuvorlik + maqtov). Format/uslub (Prettier/ESLint — 2.7) bu ro'yxatda yo'q (avtomatik — odam mantiq/xavfsizlikga fokuslandi). Bu — sifatli review (tizimli, ustuvorlikli, balansli).

Misol 5 — Review avtomatlashtirilgan oqim (2.7)

Maqsad: CI avtomatik tekshiruvi + odam review'ning birga ishlashini ko'rsatish. Bu odam vaqtini muhim narsaga yo'naltiradi.

PR OCHILGANDA — AVTOMATIK (CI — odam KUTMAYDI):
┌─────────────────────────────────────────────────────┐
│  Prettier (format)      — bo'shliq/qator avtomatik │
│  ESLint (uslub)         — kod qoidalari            │
│  TypeScript (tip)       — tip xatolari             │
│  Test (Vitest)          — funksionallik            │
│  Build                  — kompilyatsiya            │
│  npm audit (xavfsizlik) — zaif paket               │
│  Semgrep (SAST)         — kod zaifligi             │
└─────────────────────────────────────────────────────┘
        (hammasi yashil bo'lgach)
ODAM REVIEW (qiymatli — mashina qila olmaydigan):
 Mantiq (to'g'ri ishlaydimi?)
 Dizayn (yondashuv to'g'rimi?)
 Xavfsizlik fikri (kontekstli zaiflik)
 O'qiluvchanlik (tushunarlimi?)

NATIJA:
 AGAR CI qizil (test yiqildi)  odam vaqt sarflamaydi (avval tuzat)
 CI yashil  odam faqat MUHIM narsaga (format/test emas — mantiq/dizayn)

Bu nima ko'rsatadi: Bu — review avtomatlashtirilgan oqim (CI + odam — 2.7). PR ochilganda — avtomatik (CI — 10.9, 14.9 — odam kutmaydi): Prettier (format), ESLint (uslub), TypeScript (tip), test (Vitest — 11.17), build, npm audit (xavfsizlik — 14.9), Semgrep (SAST) — bularning hammasi avtomatik ishlaydi (har PR'da — izchil, tez). CI yashil bo'lgach — odam review (qiymatli — mashina qila olmaydigan): mantiq (to'g'ri ishlaydimi — biznes mantiq), dizayn (yondashuv to'g'rimi — arxitektura), xavfsizlik fikri (kontekstli zaiflik — mashina topmaydigan), o'qiluvchanlik (tushunarlimi). Natija: (1) agar CI qizil (test yiqildi, lint xato, zaiflik) odam vaqt sarflamaydi (dasturchi avval CI'ni tuzatsin — buzuq kodni odam tekshiraslik — vaqt tejash); (2) CI yashil odam faqat muhim narsaga fokuslanadi (format/test allaqachon tekshirilgan — odam mantiq/dizayn/xavfsizlikga — qiymatli). Nega bu muhim: odam vaqti qimmat (mashina qila olmaydigan ishga sarflansin — mantiq, dizayn, kontekstli xavfsizlik); format/uslub/test — mashina qiladi (izchil, tez, charchamaydi, har PR'da bir xil). Agar odam format/bo'shliq munozarasiga vaqt sarflasa (mashina qiladigan ishni) — bu isrof (va sub'ektiv — "men bunday yoqtiraman" — Prettier ob'ektiv). Avtomatlashtirish odam review'ni kuchaytiradi (odam faqat muhim narsaga — qiymatli fikr) va tezlashtiradi (CI darrov — odam keyin, faqat yashil kodga). Bu — zamonaviy professional jamoaning review oqimi (CI avtomatik filtr + odam qiymatli review). 15.3 (keyingi bob — ESLint/Prettier/Husky) bu avtomatlashtirishni sozlashni ko'rsatadi (format/uslub/pre-commit — odam review'dan oldin). Avtomatlashtirish + odam — birga eng samarali review (mashina mexanikni, odam aqliyni).

Misol 6 — Conventional Comments: fikrga belgi berish (2.3, 2.9)

Maqsad: Har fikrga aniq belgi (label) qo'yib, uning turi va ustuvorligini bir qarashda ko'rsatish. Bu dasturchiga nima majburiy, nima ixtiyoriy ekanini darrov anglatadi.

CONVENTIONAL COMMENTS — <belgi>: <izoh> formati
(conventionalcomments.org — standart, keng qo'llaniladigan):

praise:    "Bu error handling juda toza — kelajakdagi xatolarni oldini oladi."
             (maqtov — yaxshi narsani ataylab ta'kidlash — balans)
nit:       "`i` o'rniga `index` biroz aniqroq bo'lardi." (ixtiyoriy)
             (kichik — dasturchi qabul qilmasligi ham mumkin)
suggestion:"Bu 3 shartni alohida funksiyaga ajratsak, test osonroq bo'larmidi?"
             (taklif — yaxshilash, lekin bloklamaydi)
question:  "Bu yerda `await` yo'q — bu ataylabmi yoki unutildimi?"
             (savol — tushunish, ayblov emas)
issue:     "Bu SQL so'rov parametrlanmagan — injection xavfi 14.3-bob."
             (muammo — jiddiy, tuzatilishi kerak)
blocking:  "issue (blocking): merge'dan oldin tuzatilishi shart."
             (bloklovchi — issue'ga qo'shimcha kuch belgisi)

MISOL — bitta izoh, aniq belgi bilan:
 belgisiz:  "Buni o'zgartirsang yaxshi bo'lardi."
              (dasturchi: majburiymi? ixtiyoriymi? — noaniq)
 belgi bilan: "nit: buni o'zgartirsak yaxshi bo'lardi (ixtiyoriy)."
              (dasturchi: aniq — kichik, majburiy emas)

Bu nima ko'rsatadi: Bu — Conventional Comments (2.3 fikr darajalari va 2.9 formatning amaliy standarti — conventionalcomments.org). Har fikr <belgi>: <izoh> formatida yoziladi, belgi fikrning turini va ustuvorligini bir qarashda ko'rsatadi: praise (maqtov — yaxshi narsani ataylab ta'kidlash — 2.3 balans), nit (kichik, ixtiyoriy — dasturchi rad qilishi mumkin), suggestion (taklif — yaxshilash, bloklamaydi), question (savol — tushunish, ayblov emas — 2.3 savol shakli), issue (jiddiy muammo — tuzatilsin), blocking (issue'ga qo'shimcha — merge'ni bloklaydi). Nega bu muhim: belgisiz fikr noaniq ("buni o'zgartirsang yaxshi bo'lardi" — dasturchi bilmaydi: majburiymi yoki ixtiyoriy? — 2.3 ustuvorlik muammosi); belgi bilan ("nit: ... ixtiyoriy") — dasturchi darrov biladi bu kichik, majburiy emas (o'z vaqtini to'g'ri taqsimlaydi — bloklovchi issue'ga birinchi, nit'ga oxirida yoki umuman e'tibormasdan). Bu — 2.3 (fikr darajalari — bloklovchi/taklif/nit/maqtov) ni standart, mashina o'qiy oladigan shaklga soladi (jamoa bir xil til bilan gaplashadi — har kim "nit:" nimani anglatishini biladi). Katta jamoalarda bu ayniqsa qiymatli (yuzlab reviewer, izchil til). Belgi qo'yish — kichik odat (5 belgi qo'shish), lekin katta aniqlik (dasturchi nima muhim, nima ixtiyoriy ekanini o'ylab qolmaydi). Bu — professional review madaniyatining aniq, o'lchanadigan qismi.

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

1) PR hajmi

 katta (1000+ qator — yuzaki review — 2.2)
 kichik (200-400 — sinchkov — Misol 1)

2) Fikr

 destruktiv ("axlat kod" — 2.3)
 konstruktiv (sababli + yechim — Misol 2)

3) Qabul

 himoyaga o'tish ("men to'g'ri" — 2.4)
 o'rganish/muhokama (Misol 3)

4) Tekshirish

 format/bo'shliq (vaqt isrofi — mashina qiladi)
 mantiq/dizayn/xavfsizlik (odam — 2.5, Misol 4)

5) Ustuvorlik

 hammasi bir xil (qaysi muhim noaniq)
 bloklovchi/taklif/nit belgila (Misol 4)

6) Madaniyat

 qo'pol, sekin, ego (2.6)
 hurmat, tez, hamkorlik

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Katta PR

Sababi: ko'p o'zgarish bir PR 2.2-bob. Yechimi: kichik PR (bir maqsad — Misol 1).

Xato 2 — Destruktiv fikr

Sababi: kodni emas, odamni tanqid 2.3-bob. Yechimi: konstruktiv (sababli + yechim — Misol 2).

Xato 3 — Himoyaga o'tish

Sababi: kod = siz deb olish 2.4-bob. Yechimi: o'rganish imkoni (kod ≠ siz — Misol 3).

Xato 4 — Format munozarasi

Sababi: odam mashina ishini qiladi 2.7-bob. Yechimi: Prettier/ESLint avtomatik 15.3-bob.

Xato 5 — Rubber stamp (o'qilmay LGTM)

Sababi: review nomiga (sifat yo'q). Yechimi: kichik PR + tizimli review (Misol 4).

Xato 6 — Review cho'zilishi

Sababi: PR uzoq kutadi (bloklaydi). Yechimi: tez review (1 kun — 2.6).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• Toza kod 15.1-bob: review'da o'qiluvchanlik tekshiriladi.
• Git (4-QISM): branch, atomik/conventional commit, PR/MR (review jarayoni — 2.8).
• CI/CD 10.9-bob: avtomatik tekshiruv (test/lint/build — 2.7).
• Xavfsizlik (14-QISM): review'da zaiflik tekshiriladi (SQL injection, secret).
• Linter 15.3-bob: format/uslub avtomatik (review'dan oldin — odam mantiqga).
• Test 11.17-bob: PR'da test (review talabi).
• Jamoa ishlash: review — hamkorlik, bilim almashish, umumiy egalik.

8. Eng yaxshi amaliyotlar (best practices)

• Kichik PR (review oson, sinchkov — 2.2, Misol 1).
• Aniq PR tavsifi (nima/nega/qanday — Misol 1).
• Konstruktiv fikr (kod haqida, sababli, yechimli — Misol 2).
• O'rganib qabul (kod ≠ siz — Misol 3).
• Ustuvorlik belgila (bloklovchi/taklif/nit — Misol 4).
• Maqtov ham (faqat tanqid emas — balans — 2.3).
• Mantiq/dizayn tekshir (format avtomatik — 2.5).
• Tez review (1 kun — bloklamasin — 2.6).
• Avtomatlashtir (Prettier/ESLint/CI — odam muhimga — 2.7).
• Hurmat (psixologik xavfsizlik — 2.6).
• Atomik + conventional commit (bitta o'zgarish, standart format — 2.8).
• Conventional Comments (nit/suggestion/issue belgisi — Misol 6).
• Formatni masalaga mosla (oddiy — async; murakkab — sync/pair — 2.9).
• To'g'ri status (approve / comment / request-changes — 2.9).

9. Amaliy loyiha: "Code Review Amaliyoti"

Code review berish va olishni mustahkamlash.

Maqsad

Real PR jarayonini mashq qiling — yaxshi PR yozing, boshqa kodni review qiling, fikrlarni qabul qiling.

Talablar (requirements)

1. PR: kichik, aniq tavsif (nima/nega/qanday — Misol 1).
2. Review berish: boshqa kodni tekshir, konstruktiv fikr (Misol 2).
3. Ustuvorlik: bloklovchi/taklif/nit belgila (Misol 4).
4. Checklist: to'g'rilik/xavfsizlik/dizayn (Misol 4).
5. Maqtov: yaxshi narsani ham ayt 2.3-bob.
6. Qabul: fikrlarga professional javob (Misol 3).
7. Avtomatlashtirish: CI (Prettier/ESLint/test — 2.7).
8. Tez: review cho'zma (1 kun — 2.6).
9. Muhokama: kelishmovchilik — dalil (Misol 3).
10. Madaniyat: hurmat, hamkorlik 2.6-bob.

Maslahatlar (hint)

• Kichik PR (Xato 1).
• Konstruktiv (Xato 2).
• Kod ≠ siz (Xato 3).
• Format avtomatik (Xato 4).
• Maqtov + tanqid (balans).

"Tayyor" mezonlari (acceptance criteria)

• Yaxshi PR (kichik, tavsif).
• Konstruktiv fikr (sababli, yechimli).
• Ustuvorlik belgilangan.
• Professional qabul (o'rganish).
• Maqtov + tanqid balans.
• Hurmat madaniyat.

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

10. Xulosa va keyingi bobga ko'prik

Bu bobda code review madaniyatini chuqur o'rgandik:

• Code review (jarayon — 2.1); PR yozish 2.2-bob; review berish (konstruktiv — 2.3); review olish (o'rganish — 2.4); nima tekshirish 2.5-bob; madaniyat (hurmat — 2.6); avtomatlashtirish 2.7-bob; commit/PR/Git jarayoni (atomik, conventional, WIP — 2.8); review formati (async/sync, pair/mob, statuslar, metrika, Conventional Comments — 2.9, Misol 6).

Endi siz jamoada professional ishlay olasiz: yaxshi PR yozish, konstruktiv fikr berish, fikrlarni o'rganib qabul qilish, va sog'lom review madaniyatiga hissa qo'shish. Bu — texnik mahoratdan tashqari insoniy mahorat (hamkorlik, hurmat).

Keyingi bob — 15.3-bob: ESLint, Prettier, Husky va lint-staged. Code review'ni bildik; endi uni avtomatlashtirishni ko'ramiz: ESLint (kod sifati/xatolar — statik tahlil), Prettier (avtomatik format), Husky (git hooks — commit'dan oldin tekshiruv), va lint-staged (faqat o'zgargan fayllar). Bu — kod sifatini avtomatik, izchil qiladi (qo'lda emas).

Foydalanilgan rasmiy/ishonchli manbalar

• Google Engineering Practices — "Code Review Developer Guide" (reviewer va CL muallifi qo'llanmasi — eng yaxshi amaliyotlar)
• "Software Engineering at Google" (Titus Winters va boshqalar) — code review madaniyati va jarayoni bo'lgan bob
• Conventional Comments spetsifikatsiyasi — fikr belgilari (praise/nit/suggestion/issue/question — Misol 6)
• Conventional Commits spetsifikatsiyasi — commit xabari formati (feat/fix/refactor — 2.8)
• GitHub Docs — "About pull requests", "Reviewing changes in pull requests" (PR, approve/request-changes)
• GitLab Docs — "Merge requests", "Merge request reviews" (MR jarayoni — 2.8)
• Google re:Work — "Psychological Safety" (Project Aristotle — sog'lom jamoa tadqiqoti — 2.6)
• "The Art of Readable Code" (Dustin Boswell, Trevor Foucher) — o'qiluvchanlik review'i
• "The Pragmatic Programmer" (Hunt & Thomas) — jamoa, umumiy egalik, kod sifati