Koʻrib chiqish — bu nima, code review va PR tekshiruvi qanday ishlaydi

Code review nima

Code review — bu kodni birlashtirishdan oldin hamkasblar tomonidan tizimli tekshirishdir. Git kontekstida bu degani: dasturchi oʻzgarishlar bilan pull request yaratadi, sharhlovchilarni tayinlaydi va ular diff-ni oʻrganadi, sharhlar qoldiradi va qaror chiqaradi. Sharhlovchi oʻzgarishlarni talab qilishi (Request Changes), PR-ni maʻqullashi (Approve) yoki umumiy sharh qoldirishi mumkin.

Code review besh maqsadni koʻzlaydi: kod sifatini oshirish (nuqsonlarni ishlab chiqarishga chiqishdan oldin aniqlash), bilimlarni tarqatish (sharhlovchi yangi yondashuvlarni oʻrganadi, muallif fikr-mulohaza oladi), standartlarga rioya qilish (code style va arxitektura qarorlariga muvofiqlikni tekshirish), bus factor-ni kamaytirish (kodni faqat bitta dasturchi bilmaydi) va masʻuliyat madaniyatini qurish (muallif kod tekshirilishini bilib, aniqroq yozadi).

Code reviewning aksi — blind commit: dasturchi oʻzgarishlarni reviewsiz umumiy tarmoqqa suradi. Bunday yondashuv faqat bir foydalanuvchili loyihalarda yoki keyingi review bilan shoshilinch hotfixlar uchun joizdir. Professional jamoaviy ishlanmada code review har qanday oʻzgarish, jumladan hujjatlar va konfiguratsiya tuzatishlari uchun majburiy bosqichdir.

Code reviewda nima tekshiriladi

Code review tizimli boʻlishi kerak, tartibsiz emas. Tajribali sharhlovchilar kodni maʻlum tartibda tekshiradi: avval arxitektura va mantiq, keyin testlar, soʻngra xavfsizlik va samaradorlik, va nihoyat — uslub va nomlash. Bu tartib kritik muammolar sharhlovchi charchashidan oldin koʻrinishini taʻminlaydi.

Arxitektura va mantiq: kod vazifani hal qiladimi, keraksiz abstraksiyalar bormi, SOLID va DRY tamoyillariga rioya qilinadimi. Birinchi oʻqishda tushunish qiyin boʻlgan murakkab kod — refaktoring talab qiladigan signaldir. Sharhlovchi kod vazifada koʻrsatilgan ishni aniq bajarishiga va oʻz masʻuliyat sohasidan tashqari yon taʻsirlar yoʻqligiga ishonch hosil qilishi kerak.

Testlar: yangi testlar barcha stsenariylarni qamrab oladimi — ijobiy, salbiy, chegara holatlari. Mavjud testlar oʻzgarishlardan keyin oʻtadimi. Beqaror tushadigan flaky-testlar bormi. Xavfsizlik: SQL inyeksiyalari, XSS, maxfiy maʻlumotlarning loglar yoki API javoblari orqali sizib chiqishi yoʻqligi. Samaradorlik: algoritmlarning samaradorligi, ortiqcha DB soʻrovlari, resurs sizib chiqishi.

• Arxitektura — yechimning toʻgʻriligi, SOLIDga rioya qilish, over-engineering yoʻqligi.
• Mantiq — barcha stsenariylarni boshqarish, jumladan xatolar va chegara holatlari.
• Testlar — yangi oʻzgarishlarni qamrab olish, eski testlarning buzilmaganligi.
• Xavfsizlik — inyeksiyalar, XSS, CSRF, loglar orqali maʻlumot sizib chiqishi.
• Samaradorlik — algoritmlar murakkabligi, N+1 soʻrovlar, xotira sizib chiqishi.

Review hajmi: nega 400 qator maksimal

PR hajmini cheklash — code review samaradorligining eng muhim koʻrsatkichidir. Cisco (2015) tadqiqoti va SmartBear va Googlening keyingi tajribalari koʻrsatdiki: review hajmi 400 qatordan oshganda sharhlovchining nuqsonlarni aniqlash qobiliyati keskin pasayadi. Agar PR 400 qatordan oshsa, undagi xatolar tasodifiy ehtimoldan yuqori boʻlmagan holda aniqlanadi.

Optimal hajm: bitta PR uchun 200-400 qator. Bunday hajmni sharhlovchi 30-60 daqiqada tekshirishi mumkin, diqqatini saqlab. Google toʻliq diqqat bilan bir review raundi uchun 200 qatordan oshmaslikni tavsiya qiladi. Agar oʻzgarishlar koʻp boʻlsa — vazifa bir necha ketma-ket PRlarga boʻlinishi kerak, har biri mantiqiy yakunlangan oʻzgarish kiritadi.

Review vaqti: PR yaratilganidan keyin 24 soat ichida. Agar review bir necha kunga choʻzilsa, vazifa konteksti yoʻqoladi va muallif sharhlarga javob berishda kontekstni tiklashga vaqt sarflaydi. Yuqori code review madaniyatiga ega jamoalar review uchun SLA belgilaydi: masalan, kritik oʻzgarishlar uchun 4 soat va oddiy oʻzgarishlar uchun 24 soat.

Reviewga sharhlarni qanday toʻgʻri yozish kerak

Sharhlarning ohangi — code review samaradorligi uchun juda muhim. "Bu notoʻgʻri" degan izoh himoya reaksiyasini keltirib chiqaradi va muallifga foydali maʻlumot bermaydi. Eng yaxshi ifoda — savol-taklif: "Bu yondashuv haqida nima deb oʻylaysiz?", "Bu yerda NPE boʻlishi mumkin, agar user == nil boʻlsa. Balki guard qoʻshamiz?". Savollar kamroq bosim oʻtkazadi va munozarani ragʻbatlantiradi.

Yaxshi sharhning tarkibi uch qismdan iborat: nima notoʻgʻri, nega bu muammo va qanday tuzatish kerak. Misol: "Bu siklda ichma-ich contains sabab O(n²) ishlatilmoqda, bu 10k+ yozuvlarda sekinlashishi mumkin. O(1) qidirish uchun Set bilan almashtirib koʻring". Bunday ifoda bir vaqtning oʻzida muammoni koʻrsatadi, uning ahamiyatini tushuntiradi va yechim taklif qiladi — muallif taxmin qilishga majbur emas.

GitHub va GitLab suggestions-ni qoʻllab-quvvatlaydi — kod oʻzgarishlari uchun ichki takliflar. Sharhlovchi yozishi mumkin: "```suggestion Qayta ishlashdan oldin boʻsh qatorlarni filtrlash```" — va muallif oʻzgarishni bir marta bosish bilan qoʻllaydi. Bu kichik tuzatishlarni tezlashtiradi va review raundlari sonini kamaytiradi. Katta tuzatishlar uchun suggestionda katta bloklarni joylashtirishdan koʻra umumiy sharh yozish yaxshiroqdir.

# Yaxshi code review sharhi uchun shablon

# YOMON: "Bu kod notoʻgʻri"
# YAXSHI: "Boʻsh javobda maʻlumotni yoʻqotishimiz mumkin.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub suggestion sintaksisi:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Jamoada code review workflow-i

Samarali review workflow-i toʻrt bosqichga asoslanadi. Birinchi — muallif PRni tayyorlaydi: tushunarli nom yozadi (mas., "feat: add password reset screen"), oʻzgarishlar tavsifini, trekerdagi vazifaga havolalarni va test koʻrsatmalarini qoʻshadi. Ikkinchi — muallif auto-assign (CODEOWNERS asosida) yoki qoʻlda sharhlovchilarni tayinlaydi.

Uchinchi bosqich — sharhlovchi kodni tekshiradi va sharhlar qoldiradi. Toʻrtinchi — muallif tuzatishlar kiritadi, sharhlarga javob beradi va qayta reviewni soʻraydi. Davr maʻqullash olinmaguncha takrorlanadi. Maʻqullashdan keyin muallif merge qiladi (yoki bot merge qiladi). Mergify yoki GitHub Auto-merge orqali avtomatlashtirish yakuniy bosqichni tezlashtiradi.

Workflowning muhim elementi — stale PRlarni boshqarish. Agar PR 3 kundan ortiq reviewsiz qolsa, jarayon bloklanadi. Yechimlar: sharhlovchilarni rotatsiya qilish (agar tayinlangan sharhlovchi mavjud boʻlmasa), Slack/Teams orqali bildirishnomalar, review vaqt chegarasi (SLA). Baʻzi jamoalarda 7 kundan ortiq reviewsiz PR avtomatik ravishda yopiladi va muallif main bilan sinxronlashdan keyin yangi PR yaratadi.

• PR yaratish — tushunarli nom, tavsif, vazifaga havolalar, UI oʻzgarishlarida ekran tasvirlari.
• Tayinlash — CODEOWNERS orqali auto-assign yoki 1-2 sharhlovchini qoʻlda tanlash.
• Review — tartibda tekshirish: arxitektura → mantiq → testlar → xavfsizlik → uslub.
• Tuzatishlar — muallif barcha sharhlarga javob beradi, blocking issueslarni tuzatadi, re-review soʻraydi.
• Merge — maʻqullash va yashil CIdan keyin muallif yoki bot birlashtirishni amalga oshiradi.

Code reviewning odatiy xatolari

Birinchi xato — yuzaki review. Sharhlovchi diff-ni yuzaki koʻrib chiqadi, mantiqqa kirmaydi va Approve bosadi. Sabablar: katta PR, deadline, charchoq. Natijalar: buglar ishlab chiqarishga tushadi. Yechim: agar sifatli reviewga vaqt boʻlmasa — rasmiy maʻqullash oʻrniga "Bugun tekshira olmayman, ertaga qoldiring" deb yozing.

Ikkinchi xato — haddan tashqari tanqid (nitpicking). Sharhlovchi formatlash uslubi, oʻzgaruvchilar nomlanishi, mayda detallar haqida oʻnlab sharhlar qoldiradi. Bu muallifni motivatsiyasiz qoldiradi va reviewni choʻzadi. Yechim: StyleGuide va linterlar uslubni avtomatik tekshirishi kerak. Reviewda odam mantiq, arxitektura va xavfsizlikni tekshiradi.

Uchinchi xato — savolsiz review. Agar sharhlovchi faqat Request Changes va Approve qoʻysa, lekin savol bermasa, yangi narsa oʻrganish imkoniyatini boy beradi. Code review sogʻligʻining eng yaxshi koʻrsatkichi — har ikki tomon yangi narsa oʻrganadigan munozaralarning mavjudligidir. Agar review ishtirokchilardan birining monologi boʻlsa — jarayon buzilgan.

• Yuzaki review — chuqurlashmasdan Approve. Yechim: vaqt boʻlmasa, review qilmang.
• Nitpicking — linter tekshiradigan uslubni tanqid qilish. Yechim: style checksni avtomatlashtiring.
• Shaxsiy qarash — "men boshqacha yozgan boʻlardim". Yechim: kod ishlashi kerak, sharhlovchiga yoqishi shart emas.
• Choʻzish — 24 soatdan koʻproq review. Yechim: review uchun SLA, buzilishda eskalatsiya.
• Kontekstni eʻtiborsiz qoldirish — vazifani tushunmasdan kod review. Yechim: diffdan oldin PR tavsifini oʻqing.