Code review madaniyati: jamoani o'stiradigan review qanday bo'ladi

Kichik jamoada tim lead bo'lganimda birinchi tushungan narsam shu bo'ldi: code review — kodni tekshiruvdan o'tkazish emas, jamoani o'qitishning eng arzon vositasi. Bizda junior ko'p, senior kam — bu mahalliy jamoalarning odatiy holati. Har bir PR — real kod ustida, real kontekstda dars o'tish imkoniyati. Review'ni "qorovul" sifatida qursangiz, junior kod yozishdan qo'rqadigan bo'lib qoladi. "Ustoz" sifatida qursangiz — olti-yetti oyda ko'zga ko'rinarli o'sadi. Bu maqolada o'zim jamoada joriy qilgan va amalda ishlagan yondashuvlarni yozaman.

Review nimani qidiradi — ustuvorlik tartibi

Hamma komment bir xil og'irlikda emas. Men jamoaga aniq tartib berganman, yuqoridan pastga:

1. To'g'rilik va xavfsizlik. Kod ishlaydimi, edge case'lar qoplanganmi, SQL injection yoki kodga yozib qo'yilgan token yo'qmi. Shu darajada muammo topilsa, qolgan bandlarni muhokama qilib o'tirmaymiz — avval shu tuzatiladi.
2. Arxitekturaga moslik. Bu kod loyihaning mavjud tuzilishiga tushyaptimi? Service qatlamida turishi kerak bo'lgan mantiq controller'ga yozilgan bo'lsa, hozir to'g'ri ishlasa ham, olti oydan keyin qimmatga tushadi.
3. O'qilishi. Boshqa odam bu kodni kontekstsiz tushuna oladimi: nomlash, funksiya hajmi, murakkab shartlar.
4. Uslub. Bo'sh joylar, qavslar, import tartibi. Bu darajani odamga umuman bermang — linter va formatter'ga topshiring. Odam vergul joyini muhokama qilsa, arxitekturaga vaqt qolmaydi.

Oxirgi band eng ko'p vaqt asraydi: uslub bahsi — review'ning eng katta vaqt yutqizuvchisi. Biz Prettier va ESLint'ni CI'da majburiy qilganimizdan keyin kommentlar soni kamaydi, lekin har bir kommentning qiymati oshdi.

PR hajmi: 400 qatordan keyin review o'ladi

800 qatorlik PR'ni hech kim chin dildan o'qimaydi — ko'z yugurtiradi-da "LGTM" bosadi. Tajribamda 200–400 qator — reviewer diqqatini oxirigacha ushlab turadigan chegara. Kichik PR madaniyatini joriy qilishda menga uch narsa ishladi:

• Task'ni bo'lish odati. Katta feature'ni bitta ulkan PR emas, ketma-ket kichik PR'lar zanjiri sifatida rejalash: avval model va migration, keyin service, keyin endpoint, oxirida UI.
• Feature flag. Tugallanmagan funksiyani flag ortida merge qilish mumkin — shunda "hammasi tayyor bo'lguncha kutaman" degan bahona yo'qoladi.
• Qoidani yozib qo'yish. Biz jamoada "PR 400 qatordan oshsa, avval bo'lish mumkinligini muhokama qilamiz" degan yozma kelishuvga keldik. Qoida yozilgan bo'lsa, uni eslatish shaxsiy tanbeh emas, jarayonning bir qismi bo'ladi.

Komment ohangi: hukm emas, savol

Texnik jihatdan to'g'ri komment ham noto'g'ri ohangda yozilsa, zarar keltiradi: muallif himoyaga o'tadi, muhokama kod haqida emas, ego haqida bo'lib qoladi. Shuning uchun bizda asosiy qoida — hukm emas, savol. Bir xil fikrni ikki xil aytish mumkin. Real misol, o'zimizning review'lardan:

Yomon: "Bu noto'g'ri. Bo'sh massivda yiqiladi, qayta yozing."

Yaxshi: "Bu yerda items bo'sh massiv bo'lib kelsa nima bo'ladi? Menimcha reduce initial value'siz xato otadi — tekshirib ko'rasizmi?"

Ikkinchi shakl uch ish qiladi: muallifni himoyaga majburlamaydi, o'zi o'ylab topishga undaydi va reviewer adashgan bo'lsa ham noqulay vaziyat yuzaga kelmaydi — savol ayblov emas.

Yana ikkita kelishuv ohangni tartibga soladi:

• nit: prefiksi. Mayda, didga oid taklif oldiga nit: yozamiz — muallif uni bajarishga majbur emas. Masalan: "nit: bu ikki if'ni bitta early return qilsa ham bo'lardi".
• Majburiy va taklifni ajratish. Merge'ni bloklaydigan komment aniq belgilanadi — "blocking:" prefiksi yoki request changes. Qolgani taklif. Muallif qaysi kommentni bajarish shartligini taxmin qilib o'tirmasligi kerak.

Junior'ga review: to'g'rilab berma, yo'naltir

Eng keng tarqalgan xato — junior kodini o'zingiz "to'g'ri variant"ga ko'chirib berish. U copy-paste qiladi va hech narsa o'rganmaydi. Buning o'rniga yo'nalish bering: "Bu funksiya uchta ish qilyapti. Qaysi qismini alohida ajratish mumkin deb o'ylaysiz?" Javobni o'zi topish jarayoni — o'rganishning aynan o'zi. Ha, bunga ko'proq vaqt ketadi. Lekin bu vaqt o'qitishga investitsiya, shunchaki review xarajati emas.

Va birinchi PR'larda ijobiy narsani ham ayting. "Test yozibsiz, zo'r — ko'pchilik birinchi PR'da buni unutadi" degan bitta jumla junior'ning review'ga munosabatini butunlay o'zgartiradi. Faqat kamchiliklar ro'yxatini olgan odam keyingi safar PR ochishdan cho'chiydi — bu esa aynan bizga kerak bo'lmagan natija.

Author tomoni: review sizdan boshlanadi

Review sifati faqat reviewer'ga bog'liq emas. Muallif sifatida uchta odat:

• PR description. Uch savolga javob bering: nima o'zgardi, nega o'zgardi (task havolasi yetarli emas — bir jumla kontekst yozing) va qanday tekshirildi. Reviewer kontekstni o'zi qazib topishga vaqt sarflamasin.
• Self-review. PR ochgach, birinchi reviewer o'zingiz bo'ling: diff'ni boshdan-oxir o'qib chiqing. Men shu odat tufayli kommentlarning yarmini reviewer ko'rmasidan o'zim tuzataman — unutilgan console.log, chala nomlangan o'zgaruvchi, ortiqcha fayl.
• Kommentni shaxsiy qabul qilmaslik. Review kodga qaratilgan, sizga emas. "Kodim — bu men" degan tuyg'udan qutulish oson emas, lekin shart: eng tez o'sadigan dasturchilar kommentni hujum emas, sovg'a sifatida qabul qiladiganlardir.

Jarayon: SLA, navbatchi va LGTM kasalligi

Madaniyat faqat ohangdan iborat emas — uni ushlab turadigan uchta tashkiliy qoida:

• Review SLA — 24 soat. PR ochilgandan keyin bir sutka ichida birinchi javob bo'lishi shart. Kutish uzaygan sari muallif kontekstni unutadi, branch eskiradi, merge conflict'lar yig'iladi. Muhimi: 24 soat ichida to'liq review emas, birinchi javob — "ko'rdim, ertaga qarab beraman" ham javob hisoblanadi, muallif holatni bilib turadi.
• Navbatchi reviewer. Kichik jamoada hamma band bo'lsa, PR havoda osilib qoladi. Haftalik navbatchilik — shu hafta review'ga birinchi javobgar odam — bizda bu muammoni yechdi.
• LGTM shtampiga qarshi ritual. O'qimasdan approve bosish — jamoaviy kasallik. Biz kichik qoida kiritdik: approve qilishdan oldin kamida bitta savol yoki mazmunli izoh yozish shart. Savol topolmadingizmi — demak diff'ni o'qimagansiz. Shu ikki daqiqalik ritual review'ni qaytadan jonlantirdi.

Xulosa

Code review — jamoaning eng qimmat umumiy vaqtlaridan biri va bu investitsiyaning qaytimi to'g'ridan-to'g'ri madaniyatga bog'liq. Uslubni linter'ga bering, PR'ni kichik qiling, hukm o'rniga savol bering, junior'ga tayyor javob emas, yo'nalish ko'rsating, muallif sifatida reviewer'ning vaqtini asrang. Bularning hech biri texnik jihatdan murakkab emas — hammasi odat masalasi. Lekin natijasi o'lchanadigan darajada real: review sifati qanday bo'lsa, jamoaning o'sish tezligi ham shunday bo'ladi.