Code review (kod incelemesi) süreci, yazılım geliştirme dünyasının en önemli kalite kontrol mekanizmalarından biridir. Sadece hataları bulmak için değil, aynı zamanda bilgi paylaşımı ve takım içi iletişim için de kritik bir rol oynar.
Bu süreci daha iyi anlamanı ve Application Security ve Developer ekiplerinin jargonuna hakim olmanı sağlamak için kod incelemelerinde en sık kullanılan terimleri kategorilere ayırarak özetliyoruz:
Genel Kavramlar ve Süreç
1. Pull Request (PR) / Merge Request (MR): Bir geliştiricinin yaptığı kod değişikliklerini, ana projeye (main branch) entegre etmeden önce diğer ekip üyelerinin incelemesine ve onayına sunduğu taleptir.
2. Reviewer (İnceleyici): PR'ı okuyan, olası hataları arayan, kodun kalitesini değerlendiren ve geri bildirim veren kişidir.
3. Author (Yazar): Kodu yazan, değişiklikleri yapan ve inceleme için PR'ı oluşturan geliştiricidir.
4. LGTM (Looks Good To Me): "Bana göre iyi görünüyor" anlamına gelir. İnceleyicinin kodda bir sorun bulmadığını ve PR'ın birleştirilmesi için onay verdiğini ifade eden yaygın bir kısaltmadır.
5. WIP (Work In Progress): "Üzerinde çalışılıyor" anlamına gelir. Kodun henüz tamamlanmadığını ancak erken geri bildirim veya test süreçleri için diğer geliştiricilere açıldığını belirtir.
6. Draft PR (Taslak PR): WIP ile benzer bir amaca hizmet eder. Kod incelemeye veya birleşmeye (merge) henüz hazır değildir.
7. Approve (Onaylama): İnceleyicinin PR'ı kabul etmesi ve değişikliklerin ana koda birleştirilmesinde hiçbir sakınca görmemesidir.
8. Request Changes (Değişiklik Talebi): İnceleyicinin kodda düzeltilmesi zorunlu olan kritik hatalar veya eksikler bulduğunu, bunlar çözülmeden kodun onaylanmayacağını belirtmesidir.
9. Comment (Yorum): Kodu engellemeyen, sadece bilgi vermek, soru sormak veya alternatif bir fikir sunmak amacıyla bırakılan notlardır.
10. Resolve (Çözümleme): Bir inceleyicinin bıraktığı yorumun veya işaret ettiği hatanın, yazar tarafından düzeltilerek konunun kapatılması işlemidir.
Kod Kalitesi ve Prensipler
1. Code Smell (Kod Kokusu): Kodda doğrudan bir çökme yaratmasa da, kötü bir tasarımın veya ileride baş ağrıtacak bakım zorluklarının habercisi olan şüpheli kod yapılarıdır.
2. Technical Debt (Teknik Borç): Zaman kazanmak için hızlıca ve baştan savma yazılan "kestirme" çözümlerin, gelecekte koda bakım yapmayı zorlaştırarak ekibe yüklediği ekstra iş yüküdür.
3. Refactoring (Yeniden Düzenleme): Kodun dışarıdan gözlemlenen davranışını ve işlevini değiştirmeden, iç yapısını daha temiz, okunabilir ve verimli hale getirme işlemidir.
4. DRY (Don't Repeat Yourself): "Kendini tekrar etme" anlamına gelir. Aynı kod bloğunun projenin farklı yerlerine kopyalanmaması, bunun yerine yeniden kullanılabilir fonksiyonlar yazılması gerektiğini savunan prensiptir.
5. WET (Write Everything Twice): DRY prensibinin ihlal edildiği, kod tekrarının bolca bulunduğu durumları ironik bir dille ifade eder.
6. KISS (Keep It Simple, Stupid): Sistemlerin olabildiğince basit ve anlaşılır tutulması gerektiğini, gereksiz karmaşıklıktan kaçınılmasının hata ayıklamayı kolaylaştıracağını belirtir.
7. YAGNI (You Aren't Gonna Need It): Sadece mevcut ihtiyaçlara yönelik kod yazmayı öğütler. "İleride lazım olur" diyerek henüz gereksinim olmayan özellikleri koda eklemekten kaçınmak gerektiğini savunur.
8. SOLID: Nesne yönelimli programlamada yazılımın esnek, genişletilebilir ve sürdürülebilir olmasını sağlayan beş temel tasarım prensibinin baş harflerinden oluşan bir kısaltmadır.
9. Boilerplate Code: Hiçbir veya çok az değişiklikle projenin birçok yerinde tekrar tekrar yazılması gereken standart, kalıplaşmış ve genellikle sıkıcı kod bloklarıdır.
10. Spaghetti Code: Kontrol akışının karmaşık olduğu, nereden başlayıp nerede bittiği anlaşılamayan, okuması ve bakımı adeta bir "spagetti tabağı" gibi iç içe geçmiş kod yapılarıdır.
11. Dead Code (Ölü Kod): Yazılmış ancak programın çalışması sırasında hiçbir senaryoda çağrılmayan veya çalıştırılmayan gereksiz kod parçalarıdır. Review sırasında silinmesi istenir.
12. Magic Numbers/Strings: Koda doğrudan yazılmış, ne anlama geldiği bağlamdan anlaşılamayan sabit sayılar veya metinlerdir. Bunlar yerine anlamlı isimlendirilmiş sabit değişkenler (constants) kullanılmalıdır.
13. Coupling (Bağımlılık): İki farklı sınıfın veya modülün birbirine ne kadar bağımlı çalıştığının ölçüsüdür. Kod incelemelerinde modüllerin birbirinden bağımsız çalışabilmesi (Loose Coupling) teşvik edilir.
24. Cohesion (Uyum): Bir modülün içindeki fonksiyonların birbiriyle ne kadar alakalı ve tek bir amaca yönelik olduğudur. Yüksek uyum (High Cohesion) her zaman hedeflenen bir durumdur.
Versiyon Kontrolü (Git Jargonu)
1. Commit: Yapılan kod değişikliklerinin küçük, anlamlı bir paket olarak versiyon kontrol sistemine (Git) kaydedilmesidir.
2.Diff: Bir dosyanın eski hali ile yeni hali arasındaki satır satır farkları gösteren görünümdür. Reviewer'lar kod incelemesini diff üzerinden yapar.
3.Merge (Birleştirme): PR onaylandıktan sonra, üzerinde çalışılan dalın (branch), ana hedef dala kalıcı olarak entegre edilmesidir.
4. Rebase: Bir dalın başlangıç noktasını, hedef dalın en güncel haline taşıyarak commit geçmişini doğrusal ve çok daha temiz tutma işlemidir.
5. Conflict (Çakışma): İki farklı geliştiricinin aynı dosyanın aynı satırlarında aynı anda değişiklik yapması sonucu Git'in hangi kodu seçeceğini bilemediği durumdur. Manuel olarak çözülmesi gerekir.
6. Squash: PR içindeki birden fazla karmaşık ve küçük commit'i, ana koda birleştirmeden önce tek, temiz ve açıklayıcı bir commit haline getirme işlemidir.
7. Cherry-pick: Başka bir dalda yapılmış spesifik bir commit'i (değişikliği) alıp, o an üzerinde çalışılan dala kopyalama işlemidir.
8. Base Branch (Temel Dal): Değişikliklerin ekleneceği (çoğunlukla `main` , `master` veya `develop` ) hedef ve asıl daldır.
9. Feature Branch: Sadece belirli bir özelliğin veya hatanın geliştirildiği, iş bittiğinde base branch'e merge edilecek olan geçici çalışma dalıdır.
Geri Bildirim ve İletişim Terimleri
1. Nitpick / Nit: Kodun çalışmasını etkilemeyen, ancak değişken isimlendirmesi, gereksiz bir boşluk veya stil tercihi gibi çok ufak detaylara yapılan "kılı kırk yaran" geri bildirimlerdir. Zorunlu bir düzeltme değildir.
2. Blocker (Engelleyici): PR'ın mevcut haliyle kesinlikle onaylanamayacağını ve canlı sisteme çıkmasının sistemi bozacağını (bug, güvenlik açığı vs.) belirten en yüksek öncelikli sorundur.
3. Actionable Feedback (Eyleme Dönüştürülebilir Geri Bildirim): İnceleyicinin "Bu kod kötü olmuş" demek yerine, "Burada X yerine Y kullanırsak performans artar" gibi ne yapılması gerektiğini net açıklayan yapıcı yorumlardır.
4. Scope Creep (Kapsam Kayması): Bir PR'ın asıl amacından sapıp projede ilgisiz dosyaları, özellikleri veya alakasız hataları düzeltmeye başlamasıdır. Kod incelemelerini çok zorlaştırır.
5. Edge Case (Sınır Durumu): Normal kullanıcı senaryolarının dışında kalan, beklenmedik ve nadiren gerçekleşecek olan uç durumlardır. İnceleyiciler, kodun bu sınır durumları yakalayıp yakalamadığını kontrol eder.
Performans ve Güvenlik
1. Memory Leak (Bellek Sızıntısı): Programın kullandığı bilgisayar belleğini (RAM) işi bittiğinde işletim sistemine geri vermemesi sonucu, uygulamanın zamanla yavaşlamasına ve çökmesine yol açan hatadır.
2. Race Condition (Yarış Durumu): Birden fazla işlemin aynı veriye aynı anda, kontrolsüz bir şekilde erişmeye çalışması sonucu verinin bozulması veya uygulamanın öngörülemez davranmasıdır.
3. Bottleneck (Darboğaz): Kodun belirli bir bölümünün veya veritabanı sorgusunun çok yavaş çalışması nedeniyle tüm sistemin yavaşlamasına sebep olan performans tıkanıklığıdır.
4. Vulnerability (Güvenlik Açığı): Kodda kötü niyetli kişilerin sisteme yetkisiz erişim sağlamasına veya verileri manipüle etmesine olanak tanıyan zayıf noktalardır (Örn: SQL Injection).