diff-review: Bir Arkadaş İçin Yerel Kod Gözden Geçirme Aracı

diff-review: Bir Arkadaş İçin Yerel Kod Gözden Geçirme Aracı

Kodunuzu ana dala göndermeden önce bir gözden geçirme sürecinden geçirmek, yazılım geliştirmenin temel taşlarından biridir. Peki ya ekipte sadece siz varsanız veya hızlı bir geri bildirim almak istediğinizde ne yapmalı? İşte bu noktada, kişisel projelerinizde veya küçük ekiplerde bile verimliliği artırabilecek ‘diff-review’ gibi yerel, ön-gönderim (pre-push) kod gözden geçirme araçları devreye giriyor. Bu makalede, ‘diff-review’ konseptini ve nasıl bir arkadaşınız için basit ama etkili bir araç oluşturabileceğinizi adım adım inceleyeceğiz. Amacımız, kod kalitesini artırmak, hataları erken yakalamak ve geliştirme sürecini daha akıcı hale getirmektir.

Neden Yerel Bir Kod Gözden Geçirme Aracı?

Modern yazılım geliştirme süreçlerinde kod gözden geçirme (code review), kalitenin sağlanması, bilginin paylaşılması ve hataların erken tespit edilmesi açısından kritik bir öneme sahiptir. Ancak, geleneksel kod gözden geçirme süreçleri genellikle bir sonraki adıma geçmeden önce zaman alabilir ve bazen bir engelleyici faktör haline gelebilir. Özellikle tek kişilik projelerde veya çok küçük ekiplerde, bu süreci daha hızlı ve verimli hale getirmenin yollarını ararız. İşte tam bu noktada, ‘diff-review’ gibi yerel, yani geliştiricinin kendi makinesinde çalışan, bir ön-gönderim (pre-push) mekanizması devreye giriyor. Bu tür bir araç, kodunuzu uzak bir depoya (remote repository) göndermeden (örneğin, Git’in git push komutuyla) önce, değişikliklerinizi otomatik olarak bir gözden geçirme sürecinden geçirmenizi sağlar.

Peki, neden böyle bir araca ihtiyaç duyarız? Öncelikle, geliştirme döngüsünü hızlandırmak isteriz. Bir kodu göndermeden önce, kendi kendimize veya bir arkadaşımıza hızlıca göstermek, olası hataları daha erken yakalamamıza yardımcı olur. Bu, özellikle karmaşık algoritmalar veya kritik iş mantığı içeren kodlarda büyük önem taşır. İkinci olarak, öğrenme ve bilgi paylaşımı açısından da faydalıdır. Eğer bir arkadaşınız için böyle bir araç geliştiriyorsanız, bu süreç hem sizin hem de arkadaşınızın kodlama becerilerini geliştirmesine olanak tanır. Arkadaşınızın kodundaki potansiyel sorunları işaret ederek, onun daha iyi pratikler öğrenmesine yardımcı olabilirsiniz. Aynı şekilde, kendi kodunuzu başkasına inceletmek, sizin de farklı bakış açıları kazanmanızı sağlar.

Üçüncü olarak, kod kalitesini tutarlı tutmak önemlidir. Herkesin kendi kodunu bir gözden geçirme sürecinden geçirmesi, projenin genel kodlama standartlarına uyulmasını kolaylaştırır. Bu, zamanla projenin bakımını ve geliştirilmesini daha yönetilebilir hale getirir. Dördüncü olarak, yerel bir araç, internet bağlantısı gerektirmez. Bu, özellikle seyahat ederken veya internet erişiminin sınırlı olduğu ortamlarda çalışırken büyük bir avantajdır. Son olarak, ‘diff-review’ konsepti, daha büyük kod gözden geçirme platformlarının (GitHub Pull Requests, GitLab Merge Requests gibi) temel mantığını kendi yerel ortamınıza taşımanıza olanak tanır. Bu, daha büyük ekiplerde kullanılacak araçların temelini anlamak için de iyi bir başlangıç noktasıdır.

Kod Gözden Geçirme (Code Review) Nedir ve Neden Önemlidir?

Kod gözden geçirme, bir yazılım geliştirme sürecinde, bir veya daha fazla geliştiricinin, bir başka geliştiricinin yazdığı kodu incelemesi ve geri bildirimde bulunmasıdır. Bu süreç, kodun kalitesini artırmak, hataları en aza indirmek, kodlama standartlarını uygulamak, bilgi paylaşımını teşvik etmek ve yeni geliştiricilerin projeye adaptasyonunu kolaylaştırmak gibi birçok amaca hizmet eder. Basitçe ifade etmek gerekirse, bir başkasının yazdığı kodu okuyarak, potansiyel sorunları, geliştirme alanlarını veya daha iyi alternatifleri belirlemeye çalışmaktır. Bu, tıpkı bir metnin editör tarafından okunması gibi, yazılımın daha iyi, daha güvenli ve daha sürdürülebilir olmasını sağlar.

Kod gözden geçirme, modern yazılım geliştirmenin ayrılmaz bir parçası haline gelmiştir. Bunun birkaç temel nedeni vardır. İlk olarak, insan hatası kaçınılmazdır. Hepimiz hata yapabiliriz. Kod gözden geçirme, bu hataları, kod ana dala (main branch) veya üretim ortamına (production environment) ulaşmadan önce yakalamak için birincil savunma hattıdır. Küçük bir yazım hatası veya mantık hatası, büyük sorunlara yol açabilir. İkinci olarak, kod gözden geçirme, ekip üyeleri arasında bilgi paylaşımını teşvik eder. Bir geliştiricinin yazdığı kodu inceleyen diğer geliştiriciler, farklı yaklaşımları, kütüphaneleri veya en iyi pratikleri öğrenebilirler. Bu, ekip genelinde teknik yetkinliğin artmasına yardımcı olur. Üçüncü olarak, kod gözden geçirme, kodun okunabilirliğini ve bakımını iyileştirir. Kodun anlaşılır olması, gelecekteki değişikliklerin daha kolay yapılmasını sağlar. Dördüncü olarak, kod gözden geçirme, güvenlik açıklarının tespit edilmesine yardımcı olabilir. Güvenlik açıkları genellikle gözden kaçan küçük detaylardan kaynaklanır ve bir ikinci çift göz, bu tür sorunları daha kolay fark edebilir.

Kod gözden geçirme süreci, farklı şekillerde uygulanabilir. En yaygın yöntemlerden biri, Git gibi versiyon kontrol sistemleri (version control systems) üzerinde çekme istekleri (pull requests) veya birleştirme istekleri (merge requests) aracılığıyla gerçekleştirilir. Bir geliştirici, yaptığı değişiklikleri bir dalda (branch) tamamlar ve ardından bu değişiklikleri ana dala birleştirmek için bir istek gönderir. Bu istek, diğer ekip üyeleri tarafından incelenir. Ancak, bu yöntemler genellikle merkezi bir sunucuya (örneğin, GitHub, GitLab, Bitbucket) bağımlıdır ve bir miktar gecikme içerebilir. İşte bu noktada, ‘diff-review’ gibi yerel, ön-gönderim araçları, bu süreci geliştiricinin kendi makinesine taşıyarak daha hızlı bir ilk kontrol imkanı sunar.

diff-review: Temel Konsept ve Mimari

‘diff-review’, temel olarak, bir geliştiricinin Git deposundaki (repository) değişikliklerini (diff) analiz eden ve bu değişiklikler hakkında bir tür “gözden geçirme” çıktısı üreten bir araçtır. Bu, genellikle kodunuzu git push komutuyla uzak bir sunucuya göndermeden önce çalışan bir betik (script) veya küçük bir program aracılığıyla yapılır. Amaç, kodunuzu göndermeden önce olası hataları, stil sorunlarını veya belirli kurallara uymayan kısımları tespit etmektir. Bu, bir arkadaşınız için oluşturulacak basit bir aracın temelini oluşturur.

Bu aracın mimarisi oldukça basittir. Temelde şu adımları izler:

• Değişiklikleri Algılama: Araç, Git’in sağladığı komutları kullanarak, son gönderimden bu yana yapılan değişiklikleri tespit eder. Bu genellikle git diff komutuyla elde edilen çıktıyı analiz ederek yapılır.
• Kod Analizi: Tespit edilen değişiklikler, belirli analiz araçlarına veya özel kontrollere tabi tutulur. Bu analizler, stil kılavuzlarına (style guides) uyumluluk, potansiyel hatalar (örneğin, kullanılmayan değişkenler, yanlış tip dönüşümleri), güvenlik açıkları veya belirli kodlama prensiplerine aykırılıklar gibi konuları kapsayabilir.
• Raporlama: Analiz sonuçları, kullanıcıya anlaşılır bir şekilde sunulur. Bu raporlama, genellikle konsol çıktısı (terminalde gösterilen metin), bir dosya çıktısı veya hatta basit bir web arayüzü şeklinde olabilir.
• Ön-Gönderim Entegrasyonu: Araç, Git’in “pre-push” kancası (hook) ile entegre edilebilir. Bu, git push komutu çalıştırıldığında otomatik olarak tetiklenmesini sağlar. Eğer analiz sonuçları olumsuzsa, gönderim işlemi iptal edilebilir veya kullanıcıya uyarı verilebilir.

Bir arkadaşınız için bu aracı geliştirirken, başlangıç noktanız genellikle bir komut satırı aracı (command-line tool) olacaktır. Bu, kurulumu ve kullanımı en kolay olanıdır. Örneğin, bir Python betiği veya Node.js betiği ile başlayabilirsiniz. Bu betik, Git komutlarını çalıştırabilir ve çıktılarını işleyebilir.

Temel olarak, araç şunları yapmalıdır:

• Mevcut dalın (branch) en son gönderilmiş haline göre değişiklikleri belirle.
• Bu değişiklikleri içeren dosyaları listele.
• Her dosya için, sadece değiştirilen satırları al.
• Bu değiştirilen satırlarda belirli kontrolleri uygula.

Örneğin, bir Python betiği kullanılarak şöyle bir mantık kurulabilir:

import subprocess

def get_staged_changes():
    """
    Staged (hazırlanmış) değişiklikleri alır.
    """
    try:
        result = subprocess.run(['git', 'diff', '--name-only', '--cached'], capture_output=True, text=True, check=True)
        return result.stdout.splitlines()
    except subprocess.CalledProcessError as e:
        print(f"Git komutu hatası: {e}")
        return []

def get_diff_for_file(filename):
    """
    Belirli bir dosya için diff çıktısını alır.
    """
    try:
        result = subprocess.run(['git', 'diff', '--cached', filename], capture_output=True, text=True, check=True)
        return result.stdout
    except subprocess.CalledProcessError as e:
        print(f"Git diff hatası: {e}")
        return ""

def analyze_code_changes(diff_output):
    """
    Basit bir analiz yapar. (Buraya gerçek analizler gelecek)
    """
    issues = []
    lines = diff_output.splitlines()
    for line_num, line in enumerate(lines):
        if line.startswith('+') and not line.startswith('+++'): # Sadece eklenen satırlara bak
            if "print(" in line and "DEBUG" in line: # Basit bir hata kontrolü
                issues.append(f"Satır {line_num}: DEBUG çıktısı tespit edildi.")
    return issues

# Ana iş akışı
if __name__ == "__main__":
    changed_files = get_staged_changes()
    all_issues = {}

    for file in changed_files:
        diff = get_diff_for_file(file)
        if diff:
            issues = analyze_code_changes(diff)
            if issues:
                all_issues[file] = issues

    if all_issues:
        print("Kod Gözden Geçirme Raporu:")
        for file, issues in all_issues.items():
            print(f"\nDosya: {file}")
            for issue in issues:
                print(f"  - {issue}")
        print("\nGönderim engellendi. Lütfen yukarıdaki sorunları giderin.")
        exit(1) # Hata kodu ile çıkış yap
    else:
        print("Tebrikler! Herhangi bir sorun bulunamadı. Gönderim yapabilirsiniz.")
        exit(0) # Başarılı çıkış
    

Bu temel yapı, farklı analizler ekleyerek genişletilebilir. Örneğin, PEP 8 uyumluluğu için flake8, güvenlik için bandit gibi araçların çıktısını entegre edebilirsiniz.

Adım Adım: Bir Arkadaş İçin Basit Bir diff-review Aracı Oluşturma

Şimdi, bu konsepti daha somut hale getirelim ve bir arkadaşınız için basit bir ‘diff-review’ aracı oluşturalım. Bu araç, Git’in pre-push kancasını kullanarak, kodunuzu göndermeden önce belirli kontrolleri yapacak. Amacımız, karmaşık bir kurulum gerektirmeyen, anlaşılır ve özelleştirilebilir bir çözüm sunmak.

1. Ortam Hazırlığı ve Git Kancaları

Git kancaları (Git hooks), Git olayları tetiklendiğinde (commit, push, rebase vb.) otomatik olarak çalışan betiklerdir. pre-push kancası, git push komutu çalıştırıldığında, gönderim gerçekleşmeden hemen önce çalışır. Eğer bu kanca bir hata koduyla çıkış yaparsa, gönderim işlemi iptal edilir.

Bu kancayı kullanmak için, Git deposunun .git/hooks/ dizinine bir betik yerleştirmeniz gerekir. Bu betiğin çalıştırılabilir olması (executable) gerekir ve adı pre-push olmalıdır. Eğer pre-push adında bir dosya zaten varsa, onu yedeklemeniz veya içeriğini yeni betiğinize dahil etmeniz gerekebilir.

Örneğin, bir bash betiği ile başlayabiliriz:

#!/bin/bash

echo "Pre-push kancası çalışıyor..."

# Buraya analiz betiğimizin çağrısı gelecek
# Örneğin, Python betiğimiz 'check_code.py' ise:
# python .git/hooks/check_code.py

# Eğer analiz betiğimiz hata koduyla çıkarsa (exit 1), push'u engelle
if [ $? -ne 0 ]; then
  echo "Kod gözden geçirme başarısız oldu. Push iptal edildi."
  exit 1
fi

echo "Kod gözden geçirme başarılı. Push devam ediyor."
exit 0
    

Bu betiği .git/hooks/pre-push olarak kaydedip, chmod +x .git/hooks/pre-push komutuyla çalıştırılabilir hale getirin.

2. Kod Analiz Betiği (Örnek: Python ile)

Şimdi, yukarıda bahsettiğimiz Python analiz betiğini geliştirelim. Bu betik, sadece eklenen satırlardaki belirli kalıpları arayacak. Örneğin, “TODO:” gibi geliştirme sırasında unutulmuş notları veya “print(“DEBUG”)” gibi hata ayıklama çıktılarını bulabiliriz.

.git/hooks/check_code.py adında bir dosya oluşturalım:

import subprocess
import sys

def get_diff_lines(commit_range):
    """
    Belirtilen commit aralığı için diff çıktısını satır satır alır.
    """
    try:
        # commit_range: HEAD~1..HEAD gibi bir ifade olabilir
        result = subprocess.run(['git', 'diff', commit_range, '--unified=0'], capture_output=True, text=True, check=True)
        return result.stdout.splitlines()
    except subprocess.CalledProcessError as e:
        print(f"Git diff hatası: {e}", file=sys.stderr)
        return None

def analyze_changes(diff_lines):
    """
    Diff satırlarını analiz eder ve sorunları listeler.
    """
    issues = []
    current_file = None
    in_added_section = False

    if diff_lines is None:
        return issues

    for line in diff_lines:
        if line.startswith("diff --git"):
            current_file = line.split(" ")[2][2:] # 'a/' veya 'b/' ön ekini kaldır
            in_added_section = False # Yeni dosya başladığında resetle
        elif line.startswith("---") or line.startswith("+++"):
            continue # Meta satırları atla
        elif line.startswith("@@"):
            # Bu satır, satır numarası bilgisini içerir, şimdilik pas geçiyoruz
            # Daha gelişmiş analiz için kullanılabilir
            in_added_section = True
        elif in_added_section and line.startswith("+") and not line.startswith("+++"):
            # Sadece eklenen satırları kontrol et (ilk karakter '+')
            # "+++ " ile başlayan satırları (yeni dosya header'ı) atla
            if "TODO:" in line:
                issues.append(f"'{current_file}' dosyasında TODO bulundu: {line[1:]}")
            if "print(" in line and "DEBUG" in line:
                issues.append(f"'{current_file}' dosyasında DEBUG print'i bulundu: {line[1:]}")
            # Buraya başka kontroller eklenebilir
            # Örneğin:
            # if "import os" in line and current_file.endswith(".py"):
            #     issues.append(f"'{current_file}' dosyasında 'os' modülü import edildi, dikkatli kullanın.")

    return issues

if __name__ == "__main__":
    # Son commit ile önceki commit arasındaki farkı alıyoruz
    # Daha gelişmiş senaryolar için farklı commit aralıkları kullanılabilir
    commit_range = "HEAD~1..HEAD"
    diff_lines = get_diff_lines(commit_range)

    if diff_lines is None:
        sys.exit(1) # Git hatası durumunda çıkış

    found_issues = analyze_changes(diff_lines)

    if found_issues:
        print("\n--- Kod Gözden Geçirme Uyarısı ---", file=sys.stderr)
        for issue in found_issues:
            print(f"- {issue}", file=sys.stderr)
        print("------------------------------------", file=sys.stderr)
        print("Lütfen yukarıdaki sorunları giderin. Push işlemi engellendi.", file=sys.stderr)
        sys.exit(1) # Hata kodu ile çıkış yap, push'u engelle
    else:
        print("Kod gözden geçirme başarılı. Herhangi bir sorun bulunamadı.", file=sys.stdout)
        sys.exit(0) # Başarılı çıkış, push'a izin ver
    

Bu betiği kaydettikten sonra, chmod +x .git/hooks/check_code.py ile çalıştırılabilir hale getirin. Ardından, .git/hooks/pre-push betiğini aşağıdaki gibi güncelleyin:

#!/bin/bash

echo "Pre-push kancası çalışıyor..."

# Python analiz betiğini çalıştır
python .git/hooks/check_code.py

# Eğer analiz betiği hata koduyla çıkarsa (exit 1), push'u engelle
if [ $? -ne 0 ]; then
  echo "Kod gözden geçirme başarısız oldu. Push iptal edildi."
  exit 1
fi

echo "Kod gözden geçirme başarılı. Push devam ediyor."
exit 0
    

Artık bir değişiklik yapıp, git add . ve git commit -m "Test commit" komutlarıyla kaydedip, ardından git push komutunu çalıştırdığınızda, eğer kodunuzda “TODO:” veya “print(“DEBUG”)” gibi ifadeler varsa, push işlemi engellenecektir.

3. Vaka Analizi: Bir “Arkadaş” Senaryosu

Diyelim ki Ayşe, kendi kişisel projesi üzerinde çalışıyor ve bu projeyi GitHub’a yüklemek istiyor. Ayşe, kodunu göndermeden önce hızlıca kontrol etmek istiyor. Kendi bilgisayarında basit bir pre-push kancası kuruyor. Bu kanca, sadece eklenen satırlarda “TODO:” veya “print(“DEBUG”)” gibi ifadeler varsa push’u engelliyor.

Bir gün Ayşe, karmaşık bir algoritma üzerinde çalışırken bir hata yapar ve koduna hata ayıklama amaçlı birkaç print("DEBUG") ifadesi ekler. Sonra bu değişiklikleri kaydeder ve git push komutunu çalıştırır. Tam bu sırada pre-push kancası devreye girer ve Ayşe’ye şu mesajı gösterir:

Pre-push kancası çalışıyor...

--- Kod Gözden Geçirme Uyarısı ---
- 'algorithm.py' dosyasında DEBUG print'i bulundu: print("DEBUG: Veri işleniyor.")
- 'algorithm.py' dosyasında DEBUG print'i bulundu: print("DEBUG: Sonuç:", result)
------------------------------------
Lütfen yukarıdaki sorunları giderin. Push işlemi engellendi.
    

Ayşe hemen algorithm.py dosyasını açar, eklediği print("DEBUG") ifadelerini temizler ve değişiklikleri tekrar kaydeder. Bu sefer git push komutunu çalıştırdığında, kanca herhangi bir sorun bulmaz ve push başarıyla gerçekleşir. Bu basit senaryo, diff-review aracının nasıl zaman kazandırabileceğini ve hataları nasıl erken yakalayabileceğini göstermektedir.

Bir başka senaryoda, Ayşe’nin arkadaşı Can, Ayşe’nin projesine katkıda bulunmak istiyor. Can, kendi yerel makinesinde Ayşe’nin projesinin bir kopyasını (clone) alır ve üzerinde çalışmaya başlar. Can da aynı pre-push kancasını kullanır. Can, bir özelliği eklerken, bir fonksiyonun amacını tam olarak not almamış ve kodun içine # TODO: Bu fonksiyonun amacını daha sonra netleştireceğim. şeklinde bir yorum bırakmıştır. Can, değişikliklerini kaydeder ve git push komutunu çalıştırır. Kanca devreye girer ve Can’a şu uyarıyı verir:

Pre-push kancası çalışıyor...

--- Kod Gözden Geçirme Uyarısı ---
- 'feature.py' dosyasında TODO bulundu: # TODO: Bu fonksiyonun amacını daha sonra netleştireceğim.
------------------------------------
Lütfen yukarıdaki sorunları giderin. Push işlemi engellendi.
    

Can, bu uyarıyı gördüğünde, bıraktığı TODO yorumunu fark eder ve hemen fonksiyonun ne işe yaradığını açıklayan daha detaylı bir yorum ekler. Ardından tekrar push yapar ve bu sefer sorunsuz bir şekilde kodunu gönderebilir. Bu, hem Can’ın kod kalitesini artırmasına hem de Ayşe’nin projesinin daha düzenli kalmasına yardımcı olur.

Gelişmiş Analizler ve Özelleştirmeler

Oluşturduğumuz temel araç, birkaç basit kontrolle sınırlıydı. Ancak, ‘diff-review’ konsepti çok daha fazlasını yapabilir. Bir arkadaşınız için geliştireceğiniz bu aracı, onun ihtiyaçlarına göre özelleştirebilir ve daha güçlü hale getirebilirsiniz. İşte bazı ileri düzey analizler ve özelleştirme fikirleri:

1. Linter ve Biçimlendirici Entegrasyonu

Kod kalitesini artırmanın en etkili yollarından biri, otomatik kod analiz araçları (linters) ve kod biçimlendiriciler (formatters) kullanmaktır. Bu araçlar, kod stilini standartlaştırır, potansiyel hataları tespit eder ve okunabilirliği artırır.

• Linterlar: Örneğin, Python için flake8 veya pylint, JavaScript için eslint gibi araçlar, kodunuzdaki stil sorunlarını, sözdizimi hatalarını ve mantıksal kusurları bulur. Bu araçların çıktılarını pre-push kancanızla entegre edebilirsiniz. Betiğiniz, bu araçları çalıştırıp çıktısını alacak ve hataları raporlayacaktır.
• Biçimlendiriciler: black (Python), prettier (JavaScript, CSS vb.) gibi araçlar, kodunuzu otomatik olarak belirli bir stil kılavuzuna göre biçimlendirir. Eğer amacınız sadece stil sorunlarını tespit etmekse, bu araçları çalıştırıp değişiklikleri kontrol edebilirsiniz. Eğer amacınız otomatik düzeltme ise, bu araçları pre-commit kancasıyla (commit öncesi çalışan) entegre etmek daha uygun olabilir, ancak pre-push ile de sadece değişiklikleri kontrol edip kullanıcının düzeltmesini isteyebilirsiniz.

Örneğin, Python projesinde flake8‘i kullanmak için check_code.py betiğinizi şöyle güncelleyebilirsiniz:

import subprocess
import sys
import re # Regular expression modülü

# ... (get_diff_lines fonksiyonu aynı kalır) ...

def analyze_changes(diff_lines, filename):
    """
    Diff satırlarını analiz eder ve sorunları listeler.
    """
    issues = []
    if diff_lines is None:
        return issues

    # Sadece değiştirilen satırları alalım
    modified_lines = {} # {satır_numarası: satır_içeriği}
    current_file = None
    current_line_num = 0
    in_added_section = False

    for line in diff_lines:
        if line.startswith("diff --git"):
            current_file = line.split(" ")[2][2:]
            in_added_section = False
        elif line.startswith("---") or line.startswith("+++"):
            continue
        elif line.startswith("@@"):
            match = re.search(r'\+(\d+)', line)
            if match:
                current_line_num = int(match.group(1))
                in_added_section = True
            else:
                in_added_section = False
        elif in_added_section and line.startswith("+") and not line.startswith("+++"):
            # Sadece eklenen satırları kontrol et
            if current_file == filename: # Sadece hedef dosyadaki değişiklikleri al
                modified_lines[current_line_num] = line[1:]
            current_line_num += 1

    # Flake8'i sadece değiştirilen dosyalar üzerinde çalıştır
    if modified_lines:
        try:
            # Flake8'i sadece ilgili satırlara odaklanacak şekilde çalıştırmak karmaşık olabilir.
            # Basitlik için, tüm dosyayı analiz edip, çıktıdaki satır numaralarını kontrol edeceğiz.
            flake8_result = subprocess.run(['flake8', filename], capture_output=True, text=True, check=False)
            for flake_issue in flake8_result.stdout.splitlines():
                # Çıktı formatı: dosya:satır:sütun: kod mesaj
                match = re.match(r'([^:]+):(\d+):(\d+): (.*)', flake_issue)
                if match:
                    issue_file, issue_line, issue_col, issue_code = match.groups()
                    issue_line_num = int(issue_line)
                    # Eğer bu sorun, değiştirilen satırlardan birindeyse ekle
                    if issue_line_num in modified_lines:
                        issues.append(f"'{issue_file}' dosyasında Flake8 hatası (Satır {issue_line}): {issue_code}")
        except FileNotFoundError:
            issues.append("Flake8 kurulu değil veya PATH'te bulunmuyor. Lütfen kurun.")
        except subprocess.CalledProcessError as e:
            issues.append(f"Flake8 çalıştırılırken hata oluştu: {e}")

    # Eski kontrolleri de ekleyelim
    for line_num, line_content in modified_lines.items():
        if "TODO:" in line_content:
            issues.append(f"'{filename}' dosyasında TODO bulundu (Satır {line_num}): {line_content}")
        if "print(" in line_content and "DEBUG" in line_content:
            issues.append(f"'{filename}' dosyasında DEBUG print'i bulundu (Satır {line_num}): {line_content}")

    return issues

if __name__ == "__main__":
    commit_range = "HEAD~1..HEAD"
    diff_lines = get_diff_lines(commit_range)

    if diff_lines is None:
        sys.exit(1)

    # Değiştirilen dosyaları bulalım
    changed_files_output = subprocess.run(['git', 'diff', '--name-only', commit_range], capture_output=True, text=True, check=True).stdout.splitlines()
    
    all_issues = []
    for file in changed_files_output:
        # Sadece Python dosyalarını analiz et (örnek olarak)
        if file.endswith(".py"):
            issues_in_file = analyze_changes(diff_lines, file)
            all_issues.extend(issues_in_file)

    if all_issues:
        print("\n--- Kod Gözden Geçirme Uyarısı ---", file=sys.stderr)
        for issue in all_issues:
            print(f"- {issue}", file=sys.stderr)
        print("------------------------------------", file=sys.stderr)
        print("Lütfen yukarıdaki sorunları giderin. Push işlemi engellendi.", file=sys.stderr)
        sys.exit(1)
    else:
        print("Kod gözden geçirme başarılı. Herhangi bir sorun bulunamadı.", file=sys.stdout)
        sys.exit(0)
    

Bu güncellenmiş betik, sadece değiştirilen satırlardaki sorunları değil, aynı zamanda flake8‘in de bu değiştirilen satırlar için bulduğu sorunları raporlar. Bu, analizlerin daha hedefe yönelik olmasını sağlar.

2. Güvenlik Analizi

Güvenlik, her yazılım projesi için hayati önem taşır. ‘diff-review’ aracı, basit güvenlik kontrolleri için de kullanılabilir. Örneğin, hassas bilgilerin (API anahtarları, parolalar vb.) yanlışlıkla koda eklenip eklenmediğini kontrol edebilirsiniz.

• Gizli Anahtar Tespiti: Basit metin tabanlı kontrollerle, API anahtarları veya parolalara benzeyen kalıpları arayabilirsiniz. Ancak bu yöntem yanıltıcı olabilir.
• Güvenlik Odaklı Linters: bandit (Python için) gibi araçlar, yaygın güvenlik açıklarını tespit etmek için özel olarak tasarlanmıştır. Bu tür araçları da pre-push kancanıza entegre edebilirsiniz.

3. Özel Kurallar ve Yapılandırma

Her proje veya ekip farklı kurallara sahip olabilir. Aracınızı, bu kuralları kolayca yapılandırılabilecek şekilde tasarlamak, onu daha kullanışlı hale getirir. Örneğin:

• Yapılandırma Dosyası: Aracınızın hangi kontrolleri yapacağını, hangi dosyaları dahil edip hariç tutacağını belirten bir yapılandırma dosyası (örneğin, .diffreviewrc veya pyproject.toml içinde bir bölüm) kullanabilirsiniz.
• Kural Setleri: Farklı projeler için farklı kural setleri tanımlayabilirsiniz. Örneğin, bir web projesi için farklı, bir veri bilimi projesi için farklı kurallar geçerli olabilir.

4. Vaka Analizi: Bir Ekip İçin Özelleştirilmiş Kurallar

Bir yazılım şirketinde çalışan Mehmet, ekibinin kod kalitesini artırmak için kendi geliştirdiği ‘diff-review’ aracını kullanıyor. Ekip, Python dilinde çalışıyor ve flake8, black ve bandit araçlarını standart olarak kullanıyor. Mehmet, aracını bu araçlarla entegre ediyor ve ayrıca ekibin kendi belirlediği bazı özel kuralları da ekliyor:

• TODO: yorumları push’u engellemeyecek ama bir uyarı olarak gösterilecek.
• print("DEBUG") ifadeleri ise push’u kesinlikle engelleyecek.
• .env dosyalarının veya gizli anahtar kalıplarının koda eklenmesi push’u engelleyecek.
• bandit‘in bulduğu yüksek ve orta seviye güvenlik açıklarını da push’u engelleyecek şekilde raporlayacak.

Mehmet, bu kuralları bir .diffreviewrc dosyası ile yapılandırıyor. Artık ekipteki her geliştirici, kodunu göndermeden önce bu kurallara tabi tutuluyor. Bu sayede, ekip üyeleri daha temiz, daha güvenli ve daha standart kodlar yazıyor. Örneğin, bir geliştirici yanlışlıkla bir API anahtarını koda yapıştırıp push yapmaya çalıştığında, araç şu şekilde bir çıktı verebilir:

Pre-push kancası çalışıyor...

--- Kod Gözden Geçirme Uyarısı ---
- 'config.py' dosyasında gizli anahtar kalıbı tespit edildi. Lütfen hassas bilgileri koda eklemeyin.
- 'utils.py' dosyasında bandit tarafından orta seviye güvenlik açığı tespit edildi (B305: urllib version check).
------------------------------------
Lütfen yukarıdaki sorunları giderin. Push işlemi engellendi.
    

Bu tür bir entegrasyon, hem geliştirme sürecini hızlandırır hem de projenin genel kalitesini ve güvenliğini önemli ölçüde artırır. Bu, tek kişilik bir projede bile kullanılabileceği gibi, küçük ve orta ölçekli ekipler için de oldukça faydalıdır.

Yerel Gözden Geçirme Araçlarının Avantajları ve Dezavantajları

Yerel kod gözden geçirme araçları, özellikle ‘diff-review’ gibi ön-gönderim (pre-push) mekanizmaları, yazılım geliştirme sürecine önemli katkılar sağlayabilir. Ancak her teknolojide olduğu gibi, bu yaklaşımın da kendine özgü avantajları ve dezavantajları bulunmaktadır. Bu dengeyi anlamak, aracın ne zaman ve nasıl kullanılacağına karar vermede yardımcı olacaktır.

Avantajları

• Hızlı Geri Bildirim: En büyük avantajı, geliştiricilere kodlarını göndermeden hemen önce anında geri bildirim sağlamasıdır. Bu, hataların ve stil sorunlarının çok erken aşamalarda tespit edilmesini sağlar, böylece daha sonraki aşamalarda bu sorunları düzeltmenin maliyeti ve zamanı azalır.
• Geliştirme Döngüsünü Hızlandırma: Geliştiriciler, kodlarını uzak bir sunucuya göndermeden ve bir çekme isteği (pull request) oluşturmadan önce kendi kontrollerini yapabildikleri için, genel geliştirme döngüsü hızlanabilir.
• Bağımsızlık: Bu araçlar genellikle yerel olarak çalışır ve merkezi bir sunucuya veya internet bağlantısına bağımlı değildir. Bu, geliştiricilerin çevrimdışı ortamlarda veya ağ sorunları yaşarken bile kod kalitesini kontrol etmelerini sağlar.
• Özelleştirilebilirlik: Yerel araçlar, geliştiricinin veya ekibin özel ihtiyaçlarına göre kolayca özelleştirilebilir. Belirli kodlama standartları, güvenlik gereksinimleri veya proje bazlı kurallar eklenebilir.
• Öğrenme ve Gelişim: Özellikle yeni başlayan geliştiriciler için, bu araçlar sürekli olarak kodlama standartlarını ve en iyi pratikleri hatırlatır, böylece öğrenme sürecini destekler.
• Daha Az Gürültü: Merkezi kod gözden geçirme sistemlerinde bazen önemsiz stil sorunları veya küçük hatalar için bildirimler gelebilir. Yerel araçlar, bu tür “gürültüyü” geliştiricinin kendi ortamında filtreleyerek, daha önemli geri bildirimlere odaklanmasını sağlayabilir.

Dezavantajları

• Tek Başına Yeterli Değil: Yerel araçlar, ekip üyeleri arasındaki işbirliğini ve bilgi paylaşımını tam olarak yerine koyamaz. Bir geliştiricinin yazdığı kodu başka bir geliştiricinin incelemesi, farklı bakış açıları kazandırır ve kolektif bilgiyi artırır.
• Kurulum ve Bakım Yükü: Her geliştiricinin kendi makinesinde bu araçları kurması ve yapılandırması gerekebilir. Bu, özellikle büyük ekiplerde bir başlangıç yükü oluşturabilir. Ayrıca, araçların güncellenmesi ve bakımı da bir sorumluluktur.
• Kullanıcı İnatçılığı (User Inertia): Geliştiriciler, araç tarafından bildirilen sorunları görmezden gelebilir veya “şimdi zamanım yok” diyerek geçiştirebilir. Aracın itiraz etme (blocking) yeteneği olmasa bile, kullanıcıların bu uyarıları ciddiye alması gerekir.
• Sınırlı Analiz Yeteneği: Yerel araçlar genellikle statik kod analizi (static code analysis) yapar. Çalışma zamanı (runtime) hatalarını, karmaşık mantık hatalarını veya performans sorunlarını tespit etmekte yetersiz kalabilirler.
• Güvenlik Riskleri: Eğer araçlar doğru yapılandırılmazsa veya hassas bilgiler içeren kodları analiz ederken dikkatli olunmazsa, güvenlik riskleri ortaya çıkabilir. Örneğin, bir yapılandırma dosyasında hassas bilgiler saklamak gibi.
• Bağlam Kaybı: Bir kodun neden belirli bir şekilde yazıldığını anlamak için bazen proje bağlamını bilmek gerekir. Yerel araçlar bu bağlamı tam olarak kavrayamayabilir.

Bu dezavantajlara rağmen, ‘diff-review’ gibi yerel araçlar, geleneksel kod gözden geçirme süreçlerini tamamlayıcı olarak kullanıldığında son derece değerlidir. Özellikle tek kişilik projelerde veya bir ekibin başlangıç aşamasında, bu araçlar kod kalitesini önemli ölçüde artırabilir.

Sonuç ve Gelecek Adımlar

‘diff-review’ konsepti, geliştiricilere kodlarını ana dala göndermeden önce kendi yerel ortamlarında hızlı bir kontrol imkanı sunarak yazılım geliştirme sürecini daha verimli hale getirme potansiyeli taşır. Bir arkadaşınız için basit bir ön-gönderim (pre-push) aracı oluşturmak, hem kod kalitesini artırmanın hem de geliştirme alışkanlıklarını iyileştirmenin harika bir yoludur. Temel Git komutları ve basit betikleme yetenekleriyle, stil hatalarını, unutulmuş hata ayıklama çıktılarını ve hatta basit güvenlik açıklarını tespit eden bir araç geliştirebilirsiniz.

Bu makalede, ‘diff-review’ün ne olduğunu, neden önemli olduğunu, temel mimarisini ve adım adım nasıl bir araç oluşturulabileceğini inceledik. Ayrıca, linterlar, biçimlendiriciler ve güvenlik analiz araçları gibi daha gelişmiş özelliklerin nasıl entegre edilebileceğini ele aldık. Yerel gözden geçirme araçlarının avantajları ve dezavantajları da tartışıldı; bu araçların tek başına bir çözüm olmasa da, geleneksel kod gözden geçirme süreçlerini güçlü bir şekilde tamamlayabileceği vurgulandı.

Gelecek adımlar olarak, bu basit aracı daha da geliştirebilirsiniz:

• Daha karmaşık ve yapılandırılabilir kural setleri ekleyin.
• Farklı programlama dilleri için destek ekleyin.
• Basit bir raporlama arayüzü (web tabanlı veya GUI) oluşturun.
• Daha akıllı hata tespiti için makine öğrenimi modellerini araştırın (bu daha ileri düzey bir konudur).
• Ekip için standart bir yapılandırma dosyası oluşturarak herkesin aynı kuralları kullanmasını sağlayın.

Unutmayın, yazılım geliştirme sürekli bir öğrenme ve iyileştirme sürecidir. ‘diff-review’ gibi araçlar, bu süreci daha bilinçli ve daha verimli hale getirmenize yardımcı olur. Kendi aracınızı oluşturarak veya mevcut araçları kullanarak, kod kalitenizi yükseltebilir ve daha sağlam yazılımlar geliştirebilirsiniz.

Sıkça Sorulan Sorular (SSS)

• Soru: ‘diff-review’ aracı, GitHub Pull Request (PR) veya GitLab Merge Request (MR) gibi araçların yerini alabilir mi?
  
  Cevap: Hayır, tam olarak yerini alamaz. Yerel araçlar, kodunuzu göndermeden önceki ilk kontrol katmanıdır. PR/MR’lar ise ekip üyeleri arasındaki işbirliği, bilgi paylaşımı ve daha kapsamlı geri bildirim için gereklidir. Yerel araçlar, bu süreci daha verimli hale getirir, ancak onun yerini tutmaz.
• Soru: Hangi programlama dilleri için ‘diff-review’ araçları oluşturulabilir?
  
  Cevap: Temel olarak herhangi bir programlama dili için oluşturulabilir. Git’in diff çıktısını analiz edebilen ve söz konusu dilin statik analiz araçlarına erişebilen herhangi bir betik dili (Python, Node.js, Ruby, Bash vb.) kullanılabilir.
• Soru: Bu tür araçları kurmak zor mudur?
  
  Cevap: Basit bir ‘diff-review’ aracı kurmak oldukça kolaydır. Genellikle sadece bir betiği Git deposunun .git/hooks/ dizinine kopyalamak ve çalıştırılabilir hale getirmek yeterlidir. Daha gelişmiş araçlar için ek kütüphanelerin veya analiz araçlarının kurulumu gerekebilir.
• Soru: ‘diff-review’ aracı ile hangi tür hataları yakalayabilirim?
  
  Cevap: Genellikle stil hataları (kod formatı), basit sözdizimi hataları, kullanılmayan değişkenler, unutulmuş hata ayıklama çıktıları (print, console.log), basit güvenlik açıkları (gizli anahtarlar vb.) ve kodunuzdaki özel olarak belirlediğiniz diğer kurallara uymayan durumları yakalayabilirsiniz.

#Teknoloji #WebGeliştirme #YazılımMühendisliği #KodKalitesi #Git