+994512060920
Bir çox komandada code review iki ifrat formada mövcud olur: ya formal bir addımdır, kimsə "LGTM" (looks good to me) yazıb keçir, kod isə real olaraq oxunmur; ya da gərgin bir sınaqdır, hər PR şəxsi münaqişəyə çevrilir. Halbuki düzgün aparılan code review komandanın əlindəki ən güclü, ən ucuz alətlərdən biridir: səhvləri istehsalata çatmazdan əvvəl tutur, biliyi komanda daxilində yayır və kodun keyfiyyətini zamanla yüksəldir. Bu iki ifratın arasında sağlam bir orta yol var, və bu yazı məhz onu tapmağa kömək edəcək.
Psixoloji Təhlükəsizlik: Görünməyən Amil
Ən yaxşı yazılmış qaydalar belə, komandada etibar olmadıqda işləmir. Proqramçı öz kodunun tənqid ediləcəyindən qorxursa, ya kiçik, riskə girməyən dəyişikliklər edir, ya da rəyi ürəyinə salır və müdafiəyə keçir. Sağlam komandalarda isə səhv, uğursuzluq kimi deyil, öyrənmə fürsəti kimi qəbul edilir. Rəhbərin özü öz kodunu review-a göndərəndə, komandanın gözü qarşısında rəy alanda, bu mədəniyyət daha sürətlə formalaşır və bütün komanda üçün nümunə olur.
Bu yazıda yaxşı code review-un əsas prinsiplərini, nələrə diqqət etməli olduğunuzu, rəyi necə yazmalı olduğunuzu və komandanızda tətbiq edə biləcəyiniz praktiki qaydaları izah edəcəyik.
Code Review Nədir və Niyə Vacibdir?
Code review, bir proqramçının yazdığı kodun, istehsalata (production) çıxmazdan əvvəl komandanın digər üzvləri tərəfindən nəzərdən keçirilməsi prosesidir. Məqsəd təkcə səhv tapmaq deyil: kodun oxunaqlılığını yoxlamaq, komanda standartlarına uyğunluğunu təmin etmək və ən vacibi, biliyi tək bir insanın başında saxlamaq əvəzinə komanda daxilində yaymaqdır. Kodu yazan adam işdən ayrılanda, onun məntiqini yalnız o özü bilməməlidir, əks halda layihə tək bir insandan asılı vəziyyətə düşür.
Tədqiqatlar göstərir ki, code review həyata keçirən komandalar istehsalata çatan səhvlərin sayını kəskin azaldır, çünki ikinci bir göz həmişə birincinin görmədiyini görür. Bu, avtomatlaşdırılmış testlərlə birlikdə işləyən, amma onu əvəz etməyən ayrı bir keyfiyyət qatıdır.
Yaxşı Code Review-un Əsas Prinsipləri
- Kiçik PR-lar daha yaxşıdır: 500 sətirlik bir dəyişikliyi ciddi nəzərdən keçirmək demək olar ki, mümkün deyil. İnsan diqqəti müəyyən həcmdən sonra kəskin azalır.
- Sürətli reaksiya vacibdir: PR günlərlə cavabsız qalırsa, proqramçı artıq başqa tapşırığa keçib, konteksti itirir. Yaxşı komandalar 24 saat ərzində ilk rəyi verməyi hədəfləyir.
- Məntiqə fokuslanın, üsluba yox: Boşluq, mötərizə yerləşməsi kimi məsələlər insan müzakirəsinə deyil, avtomatik alətlərə həvalə edilməlidir.
- Rəy konstruktiv olmalıdır: Məqsəd müəllifi tənqid etmək deyil, kodu birlikdə yaxşılaşdırmaqdır.
Nələrə Diqqət Etmək Lazımdır?
Effektiv bir baxış aşağıdakı sualları ardıcıl olaraq cavablandırmalıdır, hər dəyişiklik üçün eyni çərçivədən keçərək:
- Düzgünlük: Kod real olaraq tələb olunan işi görürmü? Edge case-lər (sərhəd halları) nəzərə alınıbmı?
- Oxunaqlılıq: Altı ay sonra bu koda baxan başqa bir proqramçı onu asanlıqla anlaya biləcəkmi? Təmiz kod prinsipləri məhz bu sualın cavabını asanlaşdırır.
- Testlər: Yeni məntiq üçün test yazılıbmı, mövcud testlər pozulmayıbmı?
- Təhlükəsizlik: İstifadəçi girişi yoxlanılırmı, həssas məlumat loglanmırmı, icazə yoxlamaları düzgün yerdədirmi?
- Performans: Lazımsız təkrarlanan sorğular, səmərəsiz dövrlər və ya yaddaş sızmaları varmı?
- Arxitektura uyğunluğu: Bu dəyişiklik layihənin ümumi strukturuna uyğundurmu, yoxsa gələcəkdə problem yaradacaq bir qısa yoldurmu?
PR-ı Necə Kiçik Saxlamaq Olar?
Böyük funksiyaları belə kiçik, məntiqi hissələrə bölmək mümkündür. Məsələn, yeni bir funksiya üzərində işləyirsinizsə, əvvəlcə verilənlər bazası dəyişikliyini, sonra backend məntiqini, daha sonra interfeys hissəsini ayrı-ayrı PR-lar şəklində göndərmək olar. Bu, təkcə baxışı asanlaşdırmır, həm də problem aşkarlandıqda hansı hissənin səbəb olduğunu tapmağı sürətləndirir. Ümumi qayda kimi, 200-400 sətirdən böyük PR-lar bölünməyə namizəddir. Bir üstünlük də var: kiçik PR-lar daha tez birləşdirilir (merge), bu da komandanın işinin ilişib qalmasının qarşısını alır.
Rəy Yazarkən Necə Ünsiyyət Qurmaq Lazımdır?
Code review-un ən çox nəzərdən qaçırılan tərəfi texniki deyil, insani tərəfdir. "Bu səhvdir" demək əvəzinə "Bu halda X baş versə nə olar?" deyə sual vermək, eyni fikri daha az müdafiə tələb edən formada çatdırır. Rəy müəllifə deyil, koda yönəlməlidir: "sən səhv etmisən" əvəzinə "bu hissə belə oxunsa daha aydın olar" formatı, komandada etibarı qoruyur. Eyni zamanda, yalnız problemi göstərmək kifayət etmir, mümkünsə konkret həll təklifi də əlavə etmək, müəllifin vaxtına hörmətdir və prosesi sürətləndirir.
Həm də unutmayın: müsbət rəy bildirmək də vacibdir. Yaxşı yazılmış bir hissəni qeyd etmək, komandanı yalnız səhv axtaran deyil, birlikdə yaxşılaşan bir mühit kimi hiss etdirir.
Avtomatlaşdırma Nəyi Öz Üzərinə Götürməlidir?
İnsan diqqətini dəyərli saxlamağın ən sadə yolu, təkrarlanan yoxlamaları avtomatlaşdırmaqdır. Formatlaşdırma, adlandırma qaydaları, əsas təhlükəsizlik skanları və testlərin keçməsi kimi məsələlər CI/CD Pipeline daxilində avtomatik yoxlanılmalıdır. Bu sayədə insan baxışı yalnız avtomatın tuta bilmədiyi məsələlərə, yəni məntiqə, arxitekturaya və oxunaqlılığa fokuslana bilir. Əgər komandanız hələ də üslub müzakirələrinə vaxt sərf edirsə, bu, pipeline-da həll olunmalı bir boşluqdur.
Ən Çox Buraxılan Səhvlər
Ən çox rast gəlinən problem "rubber-stamping"dir, yəni kodu real oxumadan təsdiqləməkdir. Bu, adətən komanda həddindən artıq yükləndikdə və ya PR-lar çox böyük olduqda baş verir. İkinci ciddi səhv, əksinə, həddindən artıq kiçik detallara ("nitpicking") ilişib qalmaqdır, bu da müəllifi yorur və prosesi yavaşladır. Üçüncüsü, review-u yalnız bir nəfərə həvalə etməkdir, bu, "bus factor" riskini artırır, yəni həmin insan olmayanda kimsə kodu real qiymətləndirə bilmir. Dördüncüsü isə rəyi ego məsələsinə çevirməkdir: kim daha çox bilir sualı, kodun necə yaxşılaşacağı sualından daha vacib olmamalıdır. Bu səhvlərin hər biri, texniki bacarıqdan çox, komanda mədəniyyətinin nəticəsidir.
AI Kod Yazma Alətləri Code Review-u Necə Dəyişir?
AI kod yazma alətləri geniş yayıldıqca, kodun yazılma sürəti artıb, amma bu, review-un əhəmiyyətini azaltmır, əksinə artırır. AI tərəfindən yazılan kod sintaktik cəhətdən düzgün görünə bilər, amma məntiqi səhvlər, təhlükəsizlik boşluqları və ya layihənin arxitekturasına uyğunsuzluq ehtiva edə bilər. Bu, birbaşa Technical Debt yaratma riskini artırır, çünki kod tez yazılır, amma yavaş anlaşılır. Qayda dəyişmir: kodu kim və ya nə yazırsa yazsın, insan onu anlamalı və sahiblənməlidir, əks halda komanda öz başa düşmədiyi kodu istehsalata buraxmış olur.
Komandanız Üçün Praktiki Qaydalar
- Hər PR-a 24 saat ərzində ilk rəyi verin, hətta tam nəzərdən keçirməyə vaxtınız olmasa belə, qısa bir qeyd buraxın.
- PR-ları 400 sətirdən kiçik saxlamağa çalışın, mümkün olduqda böyük dəyişiklikləri bölün.
- Üslub və formatlaşdırma qaydalarını avtomatik alətlərə həvalə edin, bunları insan müzakirəsindən çıxarın.
- Hər layihədə ən azı iki nəfər hər kod hissəsini başa düşsün, tək nəfərə bağlı olmayın.
- Rəyi sual formasında yazın, hökm formasında yox.
- Yaxşı yazılmış kodu da qeyd edin, yalnız problemi deyil.
- AI tərəfindən yazılmış kodu da eyni ciddiliklə, hətta bir az daha diqqətlə nəzərdən keçirin.
Tez-tez Verilən Suallar
Kiçik komandalarda da code review lazımdırmı?
Bəli, hətta iki nəfərlik komandada da faydalıdır. İkinci göz həmişə əlavə dəyər yaradır, komandanın ölçüsündən asılı olmayaraq, çünki hər proqramçının öz kor nöqtələri var.
Bir PR-ı nəzərdən keçirmək nə qədər vaxt aparmalıdır?
Ümumi qayda kimi, saatda 200-400 sətirdən çox kodu ciddi nəzərdən keçirmək çətindir. Bundan sürətli baxış, çox güman ki, səthi qalır.
Review edən şəxs kod haqqında razılaşmazlığa düşəndə nə etməli?
Uzun mübahisə əvəzinə, qısa bir söhbətlə (zəng və ya birbaşa danışıq) məsələni sürətlə həll etmək, yazılı mübahisədən daha effektivdir.
Bütün kodu ciddi review etmək lazımdırmı, kiçik dəyişikliklər də daxil olmaqla?
Riskin səviyyəsinə görə fərqləndirmək olar. Bir sətirlik mətn düzəlişi ilə ödəniş məntiqindəki dəyişiklik eyni ciddiliklə yoxlanılmamalıdır, amma hər dəyişiklik ən azı bir nəzər salınmalıdır.
Review edən şəxs özü də səhv edə bilərmi?
Əlbəttə. Code review mükəmməllik zəmanəti vermir, riski azaldır. Elə buna görə də testlər və CI yoxlamaları insan baxışını əvəz etmir, tamamlayır.
Nəticə
Code review komandanın gündəlik işini yavaşlatmaq üçün deyil, sürətləndirmək üçün var: bu gün tutulan bir səhv, sabah istehsalatda yaranacaq bir problemdən qat-qat ucuzdur. Uğurlu code review mədəniyyəti nə tam sərbəstlik, nə də ifrat sərtlikdir, komandanın birlikdə öyrənməsi və kodun keyfiyyətini paylaşılan bir məsuliyyət kimi görməsidir. Bu mədəniyyəti qurmaq vaxt aparır, amma nəticəsi hər layihədə özünü doğruldur.
Komandanızın kod keyfiyyəti prosesini necə gücləndirə biləcəyinizi araşdırmaq istəyirsinizsə, Crocusoft komandası ilə əlaqə saxlayaraq məsləhət ala bilərsiniz.
