Vibecoding · 14-dars · 9-sinf (Junior Vibecoder)
Fan: Vibecoding · Muhandislik jarayoni
Kohorta: 9-sinf Junior Vibecoder
Hafta: 3 (2-soat)
Pull Request va Kod Ko'rigi: Kod Qanday Qabul Qilinadi
Birinchi soatda siz branch yaratdingiz va konfliktni yechdingiz. Lekin real jamoada hech kim o'z kodini to'g'ridan-to'g'ri main ga qo'shmaydi. Avval Pull Request ochiladi, keyin boshqa muhandis uni o'qib chiqadi va izoh yozadi. Bugun siz ikkala tomonni ham sinab ko'rasiz: PR yozuvchi va reviewer.
Xatoning narxi
Xato qancha kech topilsa, shuncha qimmat turadi
Yozayotganda
Dasturchi o'zi sezadi va darhol tuzatadi. Narxi — 1 daqiqa.
Kod ko'rigida
Reviewer topadi. Tuzatish — 10 daqiqa. Foydalanuvchi buni umuman ko'rmaydi.
Testlashda
Tester topadi, vazifa qaytariladi, kontekst yo'qolgan. Narxi — 1 kun.
Ishlab turgan saytda
Foydalanuvchi topadi. Shoshilinch tuzatish, obro' zarari, ba'zan pul yo'qotish. Narxi — hafta.
Kod ko'rigi faqat xato uchun emas
- Bilim tarqaladi. Reviewer loyihaning yangi qismini o'rganadi — kasallik yoki ishdan bo'shash loyihani to'xtatmaydi.
- Yagona standart. Kod bir kishi yozgandek ko'rinadi, garchi uni o'n kishi yozgan bo'lsa ham.
- Mas'uliyat bo'linadi. Merge dan keyin kod jamoaniki, bitta odamniki emas.
Pull Request nima
PR — bu so'rov: "mening branchimni main ga qo'shasizmi?"
To'liq yo'l
1. git switch -c fix/valyuta-nol
2. ... kod yoziladi, commitlar qilinadi ...
3. git push
4. GitHub da "Open Pull Request"
5. Reviewer diff ni o'qiydi va izoh yozadi
6. Muallif tuzatadi, yangi commit qo'shadi
7. Reviewer "Approve" beradi
8. Merge -> kod main ga tushdi
9. Branch o'chiriladi
PR nimalardan iborat
- Sarlavha — bitta qatorda nima qilinganini aytadi.
- Tavsif — nega kerak bo'lgani, qanday sinalgani.
- Diff — barcha o'zgarishlar qator-baqator.
- Izohlar — aniq qatorga bog'langan muhokama.
- Tekshiruvlar (CI) — testlar avtomatik ishga tushadi.
Reviewerning asosiy ko'nikmasi
Diff o'qishni bilish — kod ko'rigining yarmi
Unified diff formati
@@ -14,7 +14,9 @@ function hisobla(a, b){
var natija = 0;
- natija = a / b;
+ if (b === 0) {
+ return 'Nolga bo\'lib bo\'lmaydi';
+ }
+ natija = a / b;
return natija;
}
Har belgi nimani anglatadi
- qizil — o'chirilgan qator (eski versiya).
+ yashil — qo'shilgan qator (yangi versiya).
- Belgisiz kulrang — kontekst, o'zgarmagan. U faqat mo'ljal uchun ko'rsatiladi.
@@ -14,7 +14,9 @@ — qaysi qatordan boshlab nechta qator: eski faylda 14-dan 7 ta, yangisida 14-dan 9 ta.
⚠️ Diff ni o'qishdagi asosiy tuzoq
Diff sizga faqat o'zgargan joyni ko'rsatadi. Lekin xato ko'pincha o'zgarish bilan qolgan kod o'rtasidagi bog'liqlikda bo'ladi. Shuning uchun tajribali reviewer diffni o'qib bo'lgach, butun faylni ham ochib ko'radi.
Muallif tomonidan
Kichik PR tez qabul qilinadi. Katta PR haftalab yotadi.
❌ Yomon PR
- 800 qator o'zgarish. Reviewer charchaydi va "LGTM" deb o'qimasdan tasdiqlaydi.
- Bir nechta vazifa aralash: yangi funksiya + refaktoring + dizayn + xato tuzatish.
- Tavsif: "tuzatishlar". Reviewer nimani tekshirishini bilmaydi.
✅ Yaxshi PR
- 50–200 qator. 20 daqiqada diqqat bilan o'qib chiqish mumkin.
- Bitta maqsad. Sarlavhada "va" so'zi bo'lsa — PR ni ikkiga bo'lish kerak.
- Tavsifda: nima, nega, qanday sinaldi. UI o'zgarsa — skrinshot.
- Muallif o'zi birinchi bo'lib diffni o'qib chiqadi.
Reviewerning 4 darajasi
Kodni to'rt daraja bo'yicha o'qing — shu tartibda
1 · To'g'rimi?
Kod aytilgan ishni qiladimi? Chegaraviy holatlar: nol, bo'sh massiv, manfiy son, yo'q internet. Eng muhim daraja.
2 · Xavfsizmi?
Parol yoki API kalit kodda qolganmi? Foydalanuvchi kiritgan ma'lumot tekshirilganmi? (10-darsdagi mavzu.)
3 · O'qilodimi?
O'zgaruvchi nomlari aniqmi? Funksiya juda uzun emasmi? Olti oydan keyin tushunarli bo'ladimi?
4 · Kerakmi?
Bu kod umuman kerakmi? Balki tayyor yechim bor? Bu eng qiyin va eng qimmatli savol.
Tartib muhim
Agar siz bo'sh joy va nuqta-vergul haqida izoh yozishdan boshlasangiz, mantiqiy xatoni o'tkazib yuborasiz — diqqat tugaydi. Shuning uchun avval "to'g'rimi?", eng oxirida "chiroylimi?". Formatlashni odam emas, dastur (Prettier) tekshirsin.
Eng nozik ko'nikma
Izoh kodga yoziladi, odamga emas
❌ Shunday yozilmaydi
"Bu noto'g'ri."
"Nega bunday qilding?"
"Sen JS ni bilmaysan shekilli."
"Qayta yoz."
"Yomon kod."
// Bularda: sabab yo'q, yechim yo'q,
// baho odamga berilgan.
✅ Shunday yoziladi
"Agar b = 0 bo'lsa, bu yer Infinity
qaytaradi. Bo'lishdan oldin tekshiruv
qo'shsak bo'ladimi?"
"Bu funksiya 80 qator. Uni ikkiga
bo'lsak o'qish osonlashadi —
masalan, tekshiruvni ajratib."
// Bularda: muammo + sabab + taklif.
Izohni belgilash: uchta daraja
- nit: (nitpick) — mayda, ixtiyoriy. "nit: bu yerda bo'sh qator ortiqcha". Muallif e'tiborsiz qoldirsa ham bo'ladi.
- savol: — siz tushunmadingiz, ayblamayapsiz. "savol: bu yerda nega 3 soniya?"
- blocking: — bu tuzatilmaguncha merge bo'lmaydi. Faqat haqiqiy muammo uchun ishlatiladi.
Uchta tugma
Ko'rik oxirida reviewer uchta qarordan birini tanlaydi
✅ Approve
Kod tayyor, merge qilsa bo'ladi. nit: izohlar qolishi mumkin — ular merge ga to'sqinlik qilmaydi.
💬 Comment
Savollarim bor, lekin qaror qabul qilmayapman. Odatda boshqa reviewer ham qarashi kerak bo'lganda ishlatiladi.
🔁 Request changes
Merge dan oldin tuzatish shart. Kamida bitta blocking: izoh bo'lishi kerak — aks holda bu adolatsiz.
🛑 Oltin qoida
"Request changes" bosganingizda, nimani tuzatish kerakligi aniq yozilgan bo'lishi shart. Sababsiz rad etish — jamoadagi ishonchni buzadigan eng tez yo'l. Va aksincha: o'qimasdan "Approve" bosish — reviewer sifatida qilish mumkin bo'lgan eng yomon ish.
AI nimani topadi va nimani topmaydi
AI reviewer — birinchi filtr, oxirgi so'z emas
✅ AI yaxshi topadi
- Nolga bo'lish,
null tekshiruvining yo'qligi, massiv chegarasidan chiqish.
- Kodda qolib ketgan parol va API kalitlari.
- Takrorlanuvchi kod, ishlatilmaydigan o'zgaruvchilar.
- Nomlash va formatlash — soniyalarda, charchamasdan.
❌ AI ko'rmaydi
- Biznes mantiqi. Kod ishlaydi, lekin noto'g'ri narsani hisoblaydi — AI buni bilmaydi, chunki talabni ko'rmagan.
- Loyihaning kontekstini. "Bizda bu allaqachon
utils.js da bor" — buni faqat jamoa biladi.
- Kelajakni. "Bu yechim 10 000 foydalanuvchida buziladi" — bu tajriba, matn tahlili emas.
- AI ba'zan ishonch bilan noto'g'ri gapiradi. Uning izohini ham tekshirish kerak.
Laboratoriya · 12 daqiqa
Siz — reviewer: lab/index.html ni oching
1 · O'qish (3 daq)
PR tavsifi va diffni o'qing. Hali hech narsa yozmang — avval butun o'zgarishni tushunib oling.
2 · Xato topish (5 daq)
Diffda 4 ta haqiqiy xato yashiringan. Qatorni bosib izoh qoldiring va blocking / savol / nit deb belgilang.
3 · Qaror (2 daq)
Uchta tugmadan birini bosing. Stend qaroringiz izohlaringizga mos kelishini tekshiradi.
4 · AI bilan (2 daq)
🤖 AI ko'rigi ni bosing va natijalarni solishtiring: AI nimani topdi, siz nimani topdingiz, kim nimani o'tkazib yubordi.
🎯 Asosiy topshiriq
Diffdagi to'rtta xatodan bittasini AI umuman topa olmaydi — chunki u biznes mantiqiga tegishli. Uni toping va varaqaga yozing. Aynan shu — sizning insonni AI dan ustun qiladigan qobiliyatingiz.
PR dan keyin nima bo'ladi
Merge — bu oxiri emas, bu konveyerning boshlanishi
Avtomatik tekshiruvlar (CI)
- PR ochilishi bilan server kodni o'zi yuklab oladi va testlarni ishga tushiradi.
- Test qulasa — PR da qizil belgi chiqadi va merge tugmasi bloklanadi.
- Shuning uchun "mende ishlayapti" degan gap dalil emas.
Merge dan keyin
- Kod
main ga tushadi va odatda avtomatik deploy bo'ladi (6-darsdagi Vercel).
- Branch o'chiriladi — u endi kerak emas, tarix commitlarda qoldi.
- Muammo chiqsa —
git revert bilan bitta commit orqaga qaytariladi.
Uy vazifasi va baholash
Uy vazifasi: ko'rik hisoboti va PR tavsifi (10 ball)
Nima qilish kerak
- Varaqadagi 4 ta xato jadvalini to'ldiring: qator, muammo, belgi (blocking / savol / nit).
- AI topa olmagan xatoni alohida yozing va nega AI uni ko'ra olmasligini tushuntiring.
- Bitta izohni to'liq shaklda yozing: muammo + sabab + taklif.
- O'z loyihangiz uchun PR tavsifi yozing: sarlavha, nima, nega, qanday sinaldi.
Baholash mezoni
- 4 ta xato jadvali — 4 ball
- AI topa olmagan xato va sababi — 2 ball
- To'liq izoh (muammo+sabab+taklif) — 2 ball
- PR tavsifi — 2 ball