GitHub Copilot ile yazılan kodu gözden geçirirken temel kural şudur: GitHub Copilot önerisi, tamamlanmış kod sayılmadan önce gereksinim, çalışma davranışı, hata durumları, güvenlik ve test açısından sistematik biçimde incelenmelidir. Yapay zekâ önerisi bir başlangıçtır; çalışan test, anlaşılır gerekçe ve insan incelemesi olmadan tamamlanmış kod sayılmaz.
İncelemeye pull request diff'ini okuyarak başla. Değişikliğin amacını gereksinimle karşılaştır, ardından kodun normal ve hatalı girdilerde nasıl davrandığını kontrol et. Otomatik öneriler yalnızca başlangıç noktasıdır; son karar, değişikliği anlayan ve sonuçlarını değerlendiren insan onayına aittir.
Öneriyi kabul etmeden önce inceleme sırasını kur
Öneriyi tek seferde kabul edip sonra sorun aramak yerine, incelemeyi sabit bir sıraya bağla. Pull request diff'i iyi bir başlangıçtır; fakat değişen satırların çağrıldığı yeri, ilgili gereksinimi ve mevcut kodlama kurallarını da aynı bağlamda gör. Böylece yapay zekâ önerisi, kararın kendisi değil, incelenecek malzeme olur.
- Gereksinimi doğrula: Değişiklik hangi davranışı veya problemi hedefliyor?
- Kodu açıkla: Her satır girdiyi nasıl dönüştürüyor ve hangi çıktıyı üretiyor?
- Küçük testler çalıştır: Beklenen davranış somut örneklerde gözleniyor mu?
- Sınır ve güvenlik durumlarını incele: Boş, hatalı, beklenmedik veya kötüye kullanılabilecek girdilerde ne oluyor?
- Geçmişi ve kararı kontrol et: Commit geçmişi, inceleme yorumları ve insan onayı birlikte değerlendiriliyor mu?
Ürün arayüzü, özellik adları ve öneri biçimleri zamanla değişebileceği için bu sıra belirli bir düğmeye bağlı değildir. GitHub'ın kod önerileri dokümantasyonu, önerilerin yazım sırasında sunulabildiğini açıklar; önerinin sunulmuş olması, gereksinimin karşılandığını göstermez.
1. Kodu satır satır açıklayarak gereksinimi doğrula
Pull request diff'ini önce değişikliğin amacı ve gereksinimiyle karşılaştır. Sonra eklenen veya değiştirilen her satırı, “Bu satır hangi girdiyi alıyor, hangi koşulda ne döndürüyor, başarısızlıkta akış nereye gidiyor?” sorularıyla açıkla. Girdinin formdan mı, başka bir fonksiyondan mı geldiğini ve çıktının çağıran kod tarafından nasıl kullanıldığını da izle. Sadece çalışıyor görünmesi, açıklanamayan bir satırı kabul etmek için yeterli değildir.
Gereksinimin, kullanıcı adı alanının çevresindeki boşlukları temizlemesini, boş bırakılmamasını ve en az üç karakter içermesini istediğini varsayalım:
def validate_username(username):
username = username.strip()
if not username:
return "Kullanıcı adı boş bırakılamaz."
if len(username) < 3:
return "Kullanıcı adı en az 3 karakter olmalı."
return None
for value in [" Ada ", "Al", ""]:
error = validate_username(value)
print(repr(value), "->", error or "Geçerli")
Çalıştırıldığında beklenen çıktı şöyledir:
' Ada ' -> Geçerli
'Al' -> Kullanıcı adı en az 3 karakter olmalı.
'' -> Kullanıcı adı boş bırakılamaz.Satır satır incelemede strip(), baş ve sondaki boşlukları temizleyerek kontrol edilen değeri düzenler. Bunun gereksinimle uyumlu olup olmadığını sor. if not username boş girdiyi, len(username) < 3 ise en az karakter koşulunu denetler. Gereksinim izin verilen karakterleri de tanımlıyorsa bu kod o kontrolü yapmaz. return None, çağıran kodun bunu hata yok anlamında yorumlamasına dayanır.
for döngüsü farklı girdileri aynı kuralla işler, error sonucu taşır ve print gözlemlenebilir çıktıyı üretir. Girdinin gerçekten formdan geldiğini, fonksiyonun çağrıldığı yerde hata mesajının nasıl kullanıldığını ve projenin mevcut doğrulama kurallarını diff dışındaki bağlamda kontrol et. Girdi metin değilse strip() satırı hata verebilir; bu garanti gereksinimde yoksa kod henüz tamamlanmış sayılmaz.
GitHub'ın pull request inceleme rehberi, commit kayıtları, dosya değişiklikleri ve diff'in birlikte değerlendirilmesini kapsar. Bu yüzden tek bir satırın yerel olarak doğru görünmesi, değişikliğin bütün olarak gereksinimi karşıladığı anlamına gelmez.
2. Küçük testlerle beklenen davranışı ölç
Test yazmadan önce gereksinimi ölçülebilir kurallara çevir: değer boş veya yalnızca boşluksa boş, alfasayısal değilse hatalı biçim, uzunluğu 3-12 karakter arasında değilse sınır dışında, diğer durumlarda geçerli. Önce beklenen sonucu belirlemek, Copilot tarafından yazılan koşulların gereksinimi gerçekten karşılayıp karşılamadığını görmeyi kolaylaştırır.
def validate_username(value):
if not isinstance(value, str):
return "beklenmeyen veri türü"
if value.strip() == "":
return "boş"
if not value.isalnum():
return "hatalı biçim"
if not 3 <= len(value) <= 12:
return "sınır dışında"
return "geçerli"
cases = [
("Ada12", "geçerli"),
("", "boş"),
("Ada!", "hatalı biçim"),
("ab", "sınır dışında"),
("abcdefghijkl", "geçerli"),
("abcdefghijklm", "sınır dışında"),
]
for value, expected in cases:
actual = validate_username(value)
print(f"{value!r} -> {actual} | beklenen: {expected} | {actual == expected}")'Ada12' -> geçerli | beklenen: geçerli | True
'' -> boş | beklenen: boş | True
'Ada!' -> hatalı biçim | beklenen: hatalı biçim | True
'ab' -> sınır dışında | beklenen: sınır dışında | True
'abcdefghijkl' -> geçerli | beklenen: geçerli | True
'abcdefghijklm' -> sınır dışında | beklenen: sınır dışında | TrueBu tür küçük ve anlamlı testler, kodun davranışını görünür kılar. Ancak bütün sonuçların True olması kodun tek başına onaylandığı anlamına gelmez. Gereksinimle karşılaştırma, okunabilirlik ve başarısız durumların ele alınışı ayrıca incelenmelidir. Buradaki alfasayısal karakter kuralı yalnızca örneğe aittir; gerçek formun hangi karakterlere izin verdiği gereksinimde açıkça belirtilmelidir.
3. Sınır durumlarını deneyerek hata yollarını açığa çıkar
Normal girdiler kodun temel akışını gösterir, sınır testleri ise koşulların nerede değiştiğini ortaya çıkarır. Her sınır girdisi için beklenen davranışı kodu çalıştırmadan önce belirle:
- Minimumun altı:
absınır dışında olmalıdır. - Minimum değer:
abcgeçerli olmalıdır. - Maksimum değer:
abcdefghijklgeçerli olmalıdır. - Maksimumun üstü:
abcdefghijklmsınır dışında olmalıdır. - Boşluk: Boş dize ve yalnızca boşluk içeren değer boş kabul edilmelidir. Başta veya sonda bulunan boşlukların silinip silinmeyeceği ayrıca tanımlanmalıdır.
- Eksik alan: Formda
usernamealanı hiç gönderilmemişse bunun boş değerle aynı mı, yoksa ayrı bir eksik alan hatasıyla mı gösterileceği belirlenmelidir. - Beklenmeyen veri türü:
None, sayı veya liste geldiğinde kod bunu metne çevirmeden kontrollü biçimde durmalıdır. - Özel karakter:
Ada!hatalı biçim olarak işaretlenmelidir. Gerçek form farklı karakterlere izin veriyorsa test beklentisi de değişmelidir. - Tekrar gönderim: Aynı veri tekrar gönderildiğinde doğrulama sonucu tutarlı olmalı, geçersiz veri doğrulamadan sonraki işleme aktarılmamalıdır.
ab, abcdefghijkl ve abcdefghijklm sonuçları yalnızca uzunluk kuralını değil, gereksinimin alt ve üst sınırlarının açık yazılıp yazılmadığını da gösterir. Hata mesajı kullanıcıya hangi kuralı ihlal ettiğini ve nasıl düzelteceğini anlatmalı; kod da başarısız durumda kontrollü biçimde durmalıdır. Birkaç başarılı test, tüm olası davranışları temsil etmez. Bu nedenle sınır testlerini gereksinim, okunabilirlik ve bakım kolaylığıyla birlikte değerlendirmek gerekir.
4. Bağımlılıkları, izinleri ve güvenliği kontrol et
Form doğrulama kodunda güvenlik incelemesi, yalnızca koşulların doğru yazılıp yazılmadığına bakmaz. Diff içinde eklenen importları, bağımlılık bildirimlerini ve kilit dosyasını ayrı ayrı aç. Yeni paket gerçekten gerekli mi, mevcut kod aynı işi yapabilir mi, bu paket ağ, dosya sistemi veya çalışma zamanı izinlerini genişletiyor mu sor. Kilit dosyasındaki değişiklikleri atlama; ana bildirim dosyası aynı kalsa bile çözümlenen bağımlılık ağacı değişmiş olabilir.
Sonra form verisinin akışını izle. Girdi nerede temizleniyor, türü, uzunluğu ve kabul edilen biçimi nerede doğrulanıyor? Değer bir veritabanı sorgusuna, dosya yoluna, URL’ye ya da dış servise aktarılıyorsa aradaki sınırlar korunuyor mu? Kimlik doğrulama yalnızca kullanıcının kim olduğunu gösterir; yetkilendirme, o kullanıcının istenen kaynağa erişme hakkını ayrıca denetler. Ortam değişkenlerinde tutulan anahtarların, belirteçlerin ve bağlantı bilgilerinin koda, günlük kayıtlarına veya kullanıcıya dönen hata mesajlarına sızmadığını kontrol et.
Hata mesajı da incelemenin parçasıdır. Kullanıcıya genel ve işe yarar bir açıklama verilirken dosya yolu, SQL ayrıntısı, yığın izi, ham form verisi veya gizli bilgi gösterilmemelidir. Otomatik öneri güvenli görünüyor diye bu adımı geçme; bağlamı yanlış yorumlayabilir, eksik bir doğrulamayı atlayabilir veya güvenlik sorunu taşıyan bir düzeltme önerebilir. GitHub’ın resmî Copilot açıklaması, üretilen kodun dikkatle gözden geçirilip test edilmesi gerektiğini vurgular. Copilot önerileri çevredeki kod ve sağlanan depo bağlamından yararlanabilir; gerçek çalışma ortamındaki veri akışını ve izin sınırlarını sen ayrıca doğrulamalısın.
Bu aşamanın sonunda elinde en az şu kanıtlar olmalı: yeni bağımlılığın gerekçesi, en dar izin kapsamı, geçersiz girdiler için testler ve hassas ayrıntı içermeyen hata çıktıları.
5. Commit geçmişiyle karşılaştır, inceleme yorumu yaz ve insan onayı ver
Güncel diff’i tek başına okumak yerine değişikliği ilgili commitlerle karşılaştır. Örneğin:
git diff HEAD^ HEAD
git log --oneline --decorate -5İlk komut son commit ile ebeveynini, ikinci komut ise yakın commitleri kısa biçimde gösterir. Beklenen çıktı, ilkinde eklenen ve silinen satırları, ikincisinde kısa commit kimliklerini, başlıkları ve varsa dal etiketlerini içerir. Çıktıyı pull request açıklaması ve gereksinimle birlikte değerlendir: değişiklik amacına hizmet ediyor mu, mevcut adlandırma ve hata yönetimiyle uyumlu mu, ilgisiz satır, dosya veya biçim değişiklikleri içeriyor mu? Commit mesajı bağlam sağlar, fakat tek başına doğruluk kanıtı değildir; asıl kararı kod, test ve gereksinim birlikte belirler.
İnceleme yorumunu “Copilot bunu yazmış” diye değil, gözlediğin davranış üzerinden kur. GitHub’da yorum bırakma, satır üzerinde öneri sunma ve incelemeyi Comment, Approve veya Request changes kararıyla gönderme seçenekleri bulunur. Yorum bırakmak için okuma erişimi yeterli olabilir; ancak bir onayın birleşme koşuluna sayılması, korumalı dal kurallarına ve gereken yetkiye bağlıdır. Approve hazır olma sinyalidir, otomatik birleşme değildir; Request changes kararının birleştirmeyi durdurması da depo ayarlarına bağlı olabilir. Arayüz etiketleri ve iş akışları zamanla değişebileceğinden, düğme adlarını değil kararın anlamını ve depo kurallarını esas al.
Örneğin şu yorum davranışa, riske ve istenen kanıta odaklanır:
Gereksinim: Form yalnızca beklenen biçimdeki girdiyi kabul etmeli. Gözlem: Form verisi işlenmeden önce sunucu tarafında uzunluk ve biçim doğrulaması görünmüyor. Risk: Beklenmeyen girdiler hatalı kayıt veya ayrıntılı hata çıktısı oluşturabilir. İstek: Geçerli, boş, aşırı uzun ve beklenmeyen biçimdeki girdiler için test ekleyip, kullanıcıya dönen hata mesajının hassas ayrıntı içermediğini gösterir misin?
Form örneğinden genellenen beş aşamalı kontrol listesi şöyledir:
- Kodu satır satır açıklayarak gereksinimi doğrula.
- Küçük testlerle beklenen davranışı ölç.
- Sınır durumlarını deneyerek hata yollarını açığa çıkar.
- Bağımlılıkları, izinleri ve güvenlik sınırlarını kontrol et.
- Değişikliği commit geçmişiyle karşılaştır.
Testlerin geçmesi önemli bir kanıttır, ancak tek başına kabul gerekçesi değildir. Gereksinimi karşılayan, okunabilir, bakımı sürdürülebilir ve güvenlik sınırları anlaşılır bir değişiklik için insan incelemesi, kabul, düzeltme talebi veya ek inceleme kararını vermelidir. Yeni commit geldiyse diff’i yeniden oku ve önceki onayın hâlâ aynı değişiklik kümesini kapsadığını kontrol et.
Bu yaklaşım, Copilot’u üretken bir yardımcı olarak kullanırken son kararı kodun davranışına, kanıtlara ve insan değerlendirmesine dayandırır.
