Büyük bir değişiklikte yüzlerce dosya satırını incelemekten daha zor olan şey, birbirine karışmış amaçları ayırmaktır. İsim düzeltmeleri, veri modeli değişikliği ve yeni arayüz aynı diff içinde bulunuyorsa hatanın kaynağı zor görünür. Codex ile çalışırken işi küçük parçalara bölmek, yalnızca daha kısa pull request üretmek değildir. Her parçanın neden var olduğunu ve kendi başına neyi değiştirdiğini anlaşılır kılmaktır.
Parçayı dosya sayısına göre tanımlamayın
Tek dosyada yapılan geniş bir davranış değişikliği, beş dosyaya yayılan küçük bir metin düzeltmesinden daha karmaşık olabilir. Bu nedenle bölümleme ölçütü satır sayısı değil, aynı gerekçeyle birlikte incelenmesi gereken davranıştır. Örneğimizde bildirim ayarları ekranına yeni bir tercih ekleniyor. Veri alanı, servis davranışı ve arayüz farklı sorular doğurur.
İlk iş bu alanların bağımlılığını çıkarmaktır. Arayüzün çalışması için servis yanıtında yeni alan gerekiyorsa sırayı buna göre kurun. Sonraki parça gelene kadar uygulamanın çalışabilir kalması önemlidir. Sadece diff'i küçültmek için yarım bir davranışı yayınlanmış gibi göstermek, incelemeyi kolaylaştırmak yerine sorumluluğu gizler.
Hazırlık ile ürün değişikliğini ayırın
Yeni tercih eklenmeden önce ortak form bileşeninin küçük bir düzenlemeye ihtiyacı olabilir. Bu hazırlık mevcut davranışı değiştirmeden yapılabiliyorsa ayrı incelemek yararlıdır. Böylece sonraki arayüz değişikliğinde hem bileşen taşınması hem yeni iş kuralı aynı anda değerlendirilmez. Ancak sırf parça sayısını artırmak için gereksiz soyutlama üretmeyin.
Codex'e şu örnek görev verilebilir:
Bildirim tercihi özelliğini küçük inceleme parçalarına ayır. Her parça için amaç, önceki parçaya bağımlılık, değişen davranış ve doğrulama yöntemi yaz. Biçimlendirme veya isim temizliğini iş kuralıyla karıştırma. Her aşamanın çalışabilir kalmasını sağla. Ortak dosyada gerekli değişiklikleri gerekçesiyle göster; gereksiz yeniden düzenleme ekleme.
Bu talimat bir uygulama sırası önerir. Veritabanı ve yayın gereksinimi varsa parçalardan önce bunların uyumluluk koşullarını ayrıca değerlendirin.
Her parçaya kendi inceleme sorusunu verin
Veri alanı değişikliğinde geçmiş kayıtların durumu sorulur. Servis değişikliğinde yetki ve varsayılan değer değerlendirilir. Arayüz değişikliğinde ise kaydetme, hata ve yeniden açılma davranışı kontrol edilir. Hepsine aynı genel test listesini uygulamak yerine ilgili riski doğrulayın. Son birleşim kontrolü bu ayrı incelemelerin yerine geçmez; onları tamamlar.
Pull request açıklaması da parçanın sınırını anlatmalıdır. “Bildirim sistemi yenilendi” yerine “mevcut ayar yanıtına tercih alanı eklendi” ifadesi, okuyucunun neyi değerlendirdiğini gösterir. Sonraki arayüz parçasına bağımlılık varsa bağlantısı ve uygulama sırası belirtilsin. İnceleyen kişi sohbet geçmişini bilmeden bu ilişkiyi anlayabilsin.
Sonuçları bir araya getirirken tekrar okuyun
Parçalar tek tek doğru görünse de birleşen akışta boşluk kalabilir. Yeni tercih kaydediliyor ama yeniden açıldığında yanlış görünüyorsa sorun parça sınırında saklanmış olabilir. Son kontrolde kullanıcı akışını bütün olarak deneyin. İlk varsayımlarla son kod arasında değişen bir karar varsa açıklamaları da güncelleyin.
Küçük parçalara bölmenin kazancı, hataların hangi aşamada oluştuğunu ve hangi kararın geri alınabileceğini göstermesidir. Sonuç raporunda kaç satır değiştiğinden önce hangi davranışların tamamlandığını yazın. Böylece Codex'in ürettiği çalışma, yalnızca hızlı uygulanmış bir yama değil, başka bir geliştiricinin anlayıp sürdürebileceği bir değişiklik dizisi haline gelir.
Resmî kaynak: OpenAI — Code review.
