Reyv etmək — bu nədir, code review və PR yoxlaması necə işləyir

Code review nədir

Code review — kodun birləşdirilmədən əvvəl həmkarlar tərəfindən sistematik yoxlanılmasıdır. Git kontekstində bu o deməkdir: tərtibatçı dəyişikliklərlə pull request yaradır, rəyçilər təyin edir və onlar diff-i öyrənir, şərhlər qoyur və qərar çıxarır. Rəyçi dəyişiklik tələb edə (Request Changes), PR-i təsdiqləyə (Approve) və ya ümumi şərh qoya bilər.

Code review-in beş məqsədi var: kod keyfiyyətinin yüksəldilməsi (istehsalata düşməzdən əvvəl qüsurların aşkarlanması), biliklərin yayılması (rəyçi yeni yanaşmalar öyrənir, müəllif geribildirim alır), standartlara riayət (code style və arxitektura qərarlarına uyğunluq yoxlanışı), bus factor-un azaldılması (kodu tək tərtibatçı bilmir) və məsuliyyət mədəniyyətinin qurulması (müəllif kodun yoxlanılacağını bilərək daha diqqətli yazır).

Code review-in əksi blind commit-dir: tərtibatçı dəyişiklikləri review-siz ümumi qola ötürür. Bu yanaşma yalnız tək istifadəçili layihələrdə və ya təcili hotfix-lər üçün sonradan review ilə icazəlidir. Peşəkar komanda inkişafında code review hər hansı dəyişiklik üçün məcburi mərhələdir, o cümlədən sənədləşmə və konfiqurasiya düzəlişləri.

Code review-də nə yoxlanılır

Code review sistematik olmalıdır, xaotik yox. Təcrübəli rəyçilər kodu müəyyən ardıcıllıqla yoxlayır: əvvəlcə arxitektura və məntiq, sonra testlər, daha sonra təhlükəsizlik və performans, və yalnız sonda — stil və adlandırma. Bu ardıcıllıq kritik problemlərin rəyçi yorulmazdan əvvəl görünməsini təmin edir.

Arxitektura və məntiq: kod tapşırığı həll edirmi, lazımsız abstraksiyalar varmı, SOLID və DRY prinsiplərinə əməl olunurmu. İlk oxunuşda çətin başa düşülən mürəkkəb kod — refaktorinq tələb edən siqnaldır. Rəyçi kodun tapşırıqda göstərilən işi dəqiq yerinə yetirdiyinə və öz məsuliyyət sahəsindən kənar yan təsirlərin olmadığına əmin olmalıdır.

Testlər: yeni testlər bütün ssenariləri əhatə edirmi — müsbət, mənfi, sərhəd halları. Mövcud testlər dəyişikliklərdən sonra keçirmi. Qeyri-sabit düşən flaky-testlər varmı. Təhlükəsizlik: SQL-inyeksiyalar, XSS, həssas məlumatların loglar və ya API cavabları vasitəsilə sızması. Performans: alqoritmlərin effektivliyi, lazımsız DB sorğuları, resurs sızmaları.

• Arxitektura — həllin düzgünlüyü, SOLID-ə riayət, over-engineering-in olmaması.
• Məntiq — bütün ssenarilərin idarə olunması, o cümlədən səhvlər və sərhəd halları.
• Testlər — yeni dəyişikliklərin əhatəsi, köhnə testlərin sınmaması.
• Təhlükəsizlik — inyeksiyalar, XSS, CSRF, loglar vasitəsilə məlumat sızması.
• Performans — alqoritmlərin mürəkkəbliyi, N+1 sorğuları, yaddaş sızmaları.

Review ölçüsü: niyə 400 sətir maksimumdur

PR ölçüsünün məhdudlaşdırılması — code review effektivliyinin ən vacib metrikasıdır. Cisco (2015) tədqiqatı və SmartBear və Google-un sonrakı təcrübələri göstərdi: review həcmi 400 sətirdən çox olduqda rəyçinin qüsurları aşkarlama qabiliyyəti kəskin şəkildə azalır. PR 400 sətirdən çox olarsa, səhvlər təsadüfi ehtimaldan yüksək olmayaraq aşkarlanır.

Optimal ölçü: bir PR üçün 200-400 sətir. Bu həcm rəyçi tərəfindən 30-60 dəqiqə ərzində yoxlana bilər, konsentrasiyanı qoruyaraq. Google tam konsentrasiya ilə bir review raundu üçün 200 sətirdən çox olmamağı tövsiyə edir. Dəyişikliklər çox olarsa — tapşırıq bir neçə ardıcıl PR-a bölünməlidir, hər biri məntiqi tamamlanmış dəyişiklik gətirir.

Review vaxtı: PR yaradıldıqdan sonra 24 saat ərzində. Review bir neçə günə uzansa, tapşırığın konteksti itir və müəllif şərhlərə cavab verərkən konteksti bərpa etməyə vaxt itirir. Yüksək code review mədəniyyəti olan komandalar review üçün SLA müəyyən edir: məsələn, kritik dəyişikliklər üçün 4 saat, adi dəyişikliklər üçün 24 saat.

Review-ə şərhləri necə düzgün yazmaq olar

Şərhlərin tonu — code review effektivliyi üçün kritik əhəmiyyət daşıyır. "Bu yanlışdır" şərhi müdafiə reaksiyası yaradır və müəllifə faydalı məlumat vermir. Ən yaxşı ifadə — sual-təklifdir: "Bu yanaşma haqqında nə düşünürsən?", "Burada NPE ola bilər, əgər user == nil. Bəlkə guard əlavə edək?". Suallar az təzyiq edir və müzakirəni stimullaşdırır.

Yaxşı şərhin strukturu üç hissədən ibarətdir: nəyin səhv olduğu, bunun niyə problem olduğu və necə düzəldiləcəyi. Nümunə: "Bu dövrədə iç-içə contains səbəbindən O(n²) istifadə olunur, bu 10k+ qeyddə yavaşlada bilər. O(1) axtarış üçün Set ilə əvəz etməyə çalış." Bu ifadə eyni zamanda problemi göstərir, onun əhəmiyyətini izah edir və həll təklif edir — müəllif düşünmək məcburiyyətində qalmır.

GitHub və GitLab suggestions-u dəstəkləyir — kod dəyişiklikləri üçün daxili təkliflər. Rəyçi yaza bilər: "```suggestion Emal etmədən əvvəl boş sətirləri filtrlə```" — və müəllif dəyişikliyi bir kliklə tətbiq edir. Bu kiçik düzəlişləri sürətləndirir və review raundlarının sayını azaldır. Böyük düzəlişlər üçün suggestion-da böyük bloklar qoymaqdansa, ümumi şərh yazmaq daha yaxşıdır.

# Yaxşı code review şərhi üçün şablon

# PİS: "Bu kod yanlışdır"
# YAXŞI: "Boş cavabda məlumat itirə bilərik.
#         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)
# ```

Komandada code review workflow-u

Effektiv review workflow dörd mərhələyə əsaslanır. Birinci — müəllif PR hazırlayır: anlaşılan ad yazır (məs., "feat: add password reset screen"), dəyişikliklərin təsvirini, trekerdə tapşırığa keçidləri və test təlimatlarını əlavə edir. İkinci — müəllif auto-assign (CODEOWNERS əsasında) və ya əl ilə rəyçilər təyin edir.

Üçüncü mərhələ — rəyçi kodu yoxlayır və şərhlər qoyur. Dördüncü — müəllif düzəlişlər edir, şərhlərə cavab verir və təkrar review tələb edir. Dövr təsdiq alınana qədər təkrarlanır. Təsdiqdən sonra müəllif merge edir (və ya bot merge edir). Mergify və ya GitHub Auto-merge vasitəsilə avtomatlaşdırma son mərhələni sürətləndirir.

Workflow-un vacib elementi — stale PR idarəçiliyi. PR 3 gündən çox review-siz qalırsa, proses bloklanır. Həll yolları: rəyçilərin rotasiyası (təyin olunmuş rəyçi əlçatmazdırsa), Slack/Teams vasitəsilə bildirişlər, review vaxt limiti (SLA). Bəzi komandalarda 7 gündən çox review-siz PR avtomatik bağlanır və müəllif main ilə sinxronizasiyadan sonra yeni PR yaradır.

• PR yaradılması — anlaşılan ad, təsvir, tapşırığa keçidlər, UI dəyişikliklərində ekran görüntüləri.
• Təyin — CODEOWNERS vasitəsilə auto-assign və ya 1-2 rəyçinin əl ilə seçimi.
• Review — ardıcıllıqla yoxlama: arxitektura → məntiq → testlər → təhlükəsizlik → stil.
• Düzəlişlər — müəllif bütün şərhlərə cavab verir, blocking issue-ları düzəldir, re-review tələb edir.
• Merge — təsdiq və yaşıl CI-dan sonra müəllif və ya bot birləşməni həyata keçirir.

Code review-in tipik səhvləri

Birinci səhv — səthi review. Rəyçi diff-ə səthi baxır, məntiqə dərindən girmir və Approve basır. Səbəblər: böyük PR, deadline, yorğunluq. Nəticələr: bug-lar istehsalata düşür. Həll: keyfiyyətli review-ə vaxt yoxdursa — formal təsdiq əvəzinə vicdanla "Bu gün yoxlaya bilmərəm, sabaha keçirin" yazın.

İkinci səhv — həddindən artıq tənqid (nitpicking). Rəyçi formatlama stili, dəyişən adlandırması, xırda detallarla bağlı onlarla şərh qoyur. Bu müəllifi motivasiyadan salır və review-i uzadır. Həll: StyleGuide və linterlər stili avtomatik yoxlamalıdır. Review-də insan məntiq, arxitektura və təhlükəsizliyi yoxlayır.

Üçüncü səhv — sualsız review. Rəyçi yalnız Request Changes və Approve qoyursa, lakin sual vermirsə, yeni bir şey öyrənmək fürsətini itirir. Code review sağlamlığının ən yaxşı göstəricisi — hər iki tərəfin yeni bir şey öyrəndiyi müzakirələrin olmasıdır. Review iştirakçılardan birinin monoloqudursa, proses pozulub.

• Səthi review — dərinləşmədən Approve. Həll: vaxt yoxdursa, review etmə.
• Nitpicking — linterlə yoxlanılan stilin tənqidi. Həll: style checks-i avtomatlaşdır.
• Şəxsi qavrayış — "mən başqa cür yazardım". Həll: kod işlək olmalıdır, rəyçinin xoşuna gəlmək məcburiyyətində deyil.
• Uzatma — 24 saatdan çox review. Həll: review üçün SLA, pozuntuda eskalasiya.
• Kontekstin göz ardı edilməsi — tapşırığı anlamadan kod review. Həll: diff-dan əvvəl PR təsvirini oxu.