Bir pull request açıldığında çok sayıda satırı hızlıca okumak, değişikliğin doğru olduğunu göstermeye yetmez. Önemli olan hangi davranışın değiştiğini, bu davranışın nereden çağrıldığını ve hangi koşulda bozulabileceğini anlamaktır. Codex ile yapılan incelemede de iyi başlangıç, genel bir kalite puanı istemek yerine sınırları belirlenmiş bir araştırma görevi vermektir. Aşağıdaki yaklaşım, örnek bir sipariş servisi üzerinden uygulanabilir bir inceleme düzeni önerir.
İnceleme hedefini sabitleyin
Önce karşılaştırılan değişikliği belirtin. Çalışma alanındaki bütün düzenlemeleri incelemek ile yalnızca bir dalın temel dala göre farkını değerlendirmek farklı işlerdir. Yanlış kapsam seçildiğinde başka bir geliştiricinin henüz tamamlamadığı kod, bu pull request'in parçası sanılabilir. Değerlendirmeye başlamadan başlangıç ve bitiş revizyonlarını, etkilenen modülü ve beklenen kullanıcı davranışını kaydedin.
Örneğin hedef, ödeme başarısız olduğunda siparişin tekrar denenebilmesi olsun. İnceleme soruları da buna göre şekillenir: Aynı istek iki kez geldiğinde ne olur? Başarısız ödeme kaydı silinir mi? Kullanıcı başka bir siparişin durumunu görebilir mi? Bunlar, yalnızca değişken isimlerini tartışmaktan daha değerli sorulardır.
Codex'e uygulanabilir bir görev verin
Şu örnek başlangıç kullanılabilir:
Bu pull request'in sipariş yeniden deneme değişikliğini incele. Değişiklik yapmadan önce çağrı akışını takip et. Önceliğin veri kaybı, yetki kontrolü ve aynı isteğin tekrarlanması olsun. Her bulgu için ilgili dosyayı, hatayı tetikleyen koşulu, kullanıcı üzerindeki etkisini ve doğrulama önerisini yaz. Yalnızca varsayıma dayanan konuları kesin hata olarak sunma.
Bu metindeki sipariş akışı bir örnektir; kendi projenizin gerçek davranışına göre değiştirin. İnceleme, uygulama görevine dönüşmesin istiyorsanız “değişiklik yapmadan” sınırını açık tutun. Bulgular geldikten sonra gerekli düzeltmeleri ayrı bir talimatla yaptırabilirsiniz.
Bulguyu kanıta dönüştürün
“Kayıt iki kez oluşabilir” ifadesi, hangi iki isteğin hangi sırayla çalıştığı açıklanmıyorsa eksik kalır. Codex'ten küçük bir zaman çizelgesi isteyin: Birinci istek kontrolü geçtiğinde ikinci istek de aynı kontrolü geçebiliyor mu? Veritabanı kısıtı bunu engelliyor mu? Hata yalnızca varsayımsal mı, yoksa mevcut akışta gösterilebiliyor mu?
Mümkünse ilgili test veya güvenli yerel yeniden üretim çalıştırılsın. Çalıştırılmayan kontrol raporda açıkça belirtilsin. Testin geçmesi de bütün iş akışının kapsandığı anlamına gelmez; örneğin birim testi yetki katmanını hiç çağırmıyor olabilir. Her kanıtı kendi kapsamıyla değerlendirin.
İncelemeyi kapatılabilir hale getirin
Düzeltme sonrasında aynı tetikleyiciyle tekrar kontrol yapın. Pull request açıklamasına sorunu, son davranışı ve gerçekten yapılan doğrulamayı ekleyin. Küçük bir yazım hatasıyla müşteri verisini etkileyen bir sorunu aynı önemde sunmayın; okuyucu hangi bulgunun yayın kararını etkilediğini kolayca anlayabilsin.
Son geçişte yalnızca yeni diff'e bakmak yerine çağıran kodun beklentisini de kontrol edin. Düzeltme bir hata yolunu kapatırken başarılı sipariş akışını değiştirmiş olabilir. İncelemenin çıktısı uzun bir eleştiri listesi değil, bir geliştiricinin yeniden deneyebileceği somut bulgular ve kapatıldığı gösterilebilen sorunlar olmalıdır.
İnceleme sırasında güvenli görünen bir değişikliğin eski istemciler üzerindeki etkisini de sorun. Örneğin yanıt alanının adını değiştirmek sunucu testlerini bozmayabilir; eski mobil uygulama ise bu alanı bekliyor olabilir. Bu yüzden bulgunun yalnızca yeni kodda değil, desteklenen istemcilerle ilişkisini de açıklamak gerekir. İncelemenin kapsamı küçük olsa bile dış sözleşmeler gözden kaçmasın.
Resmî kaynak: OpenAI — Code review.
