Eski kodu modernleştirme isteği çoğu zaman birkaç farklı hedefi bir araya getirir: Okunabilirlik, yeni dil özellikleri, daha kolay test ve kullanılmayan parçaların kaldırılması. Hepsini aynı anda değiştirmek, bir hata ortaya çıktığında sebebi bulmayı zorlaştırır. Codex'e verilecek işin ilk sınırı bu yüzden hangi davranışın korunacağı ve hangi teknik sorunun çözüleceği olmalıdır.
Mevcut davranışı görünür hale getirin
Örneğimizde tek dosyada çalışan eski bir fatura hesaplama modülü var. Vergi, indirim ve yuvarlama aynı fonksiyonda yapılıyor. İlk adım fonksiyonları yeniden adlandırmak değil, mevcut girdi ve çıktıları anlamaktır. Özellikle sıfır tutar, küsurat, iade ve farklı vergi oranları gibi sınır durumlarını listeleyin. Kodun garip görünmesi, o bölümün gereksiz olduğunu kanıtlamaz.
Codex'ten bu örneklerin mevcut davranışını açıklamasını isteyin. Bir kuralın nedeni bilinmiyorsa “hata” diye kaldırmak yerine belirsizlik olarak kaydedin. İşletmenin yıllardır kullandığı bir yuvarlama davranışı, matematiksel olarak farklı bir yaklaşımdan daha önemli bir uyumluluk gereksinimi olabilir. Ürün kararıyla teknik temizlik birbirine karıştırılmasın.
Tek dönüşüm türüyle başlayın
İlk değişiklik, hesaplamayı kullanıcı arayüzünden ayırmak olabilir. Aynı aşamada vergi hesabını, isimlendirmeyi, veri tipini ve paket yapısını baştan tasarlamayın. Küçük bir yapısal değişiklikten sonra aynı örneklerle çıktıyı karşılaştırmak, hangi dönüşümün fark yarattığını gösterir. Sonraki iyileştirme bunun üzerine kurulabilir.
Örnek görev metni:
Fatura hesaplama modülünde yalnızca hesaplama mantığını ayrı bir bileşene taşı. Dışarıdan çağrılan fonksiyonun imzasını ve mevcut yuvarlama davranışını koru. Önce çağrı yerlerini ve sınır durumlarını belirle. Yeni paket ekleme. Değişikliği küçük tut; önceki ve sonraki çıktıları aynı örnekler üzerinden karşılaştır ve açıklanamayan farkları ayrı bildir.
Bu örnek, modernleştirmeyi ölçülebilir bir dönüşüme indirger. Gerçek projede dosya ve test sınırlarını kendi mimarinize göre ekleyebilirsiniz.
Uyumluluğu çağıran kodda arayın
Bir modülün kendi testi geçse de çağıran kod farklı beklenti taşıyabilir. Örneğin önceden boş metin dönen bir hata yolunun artık istisna üretmesi, dış sözleşmeyi değiştirir. Codex'in yalnızca düzenlediği fonksiyona değil, onu kullanan servis, komut ve ekranlara da bakmasını isteyin. Dönüş tipi kadar hata davranışı da sözleşmenin parçasıdır.
Kaldırılacak kod için arama yapmak iyi başlangıçtır; ancak dinamik çağrılar veya yapılandırma üzerinden yüklenen bileşenler doğrudan referans vermeyebilir. Kullanılmıyor kararı verilmeden bu yolları değerlendirin. Kanıt yetersizse kaldırmayı ayrı bir işe bırakmak, belirsizliği büyük refaktörün içinde saklamaktan daha anlaşılırdır.
Dönüşümün değerini sonuçla anlatın
Son açıklamada “kod modernleştirildi” yerine neyin ayrıldığını ve bakımın nasıl kolaylaştığını yazın. Hesaplama artık arayüz açılmadan doğrulanabiliyorsa bu somut bir kazanımdır. Satır sayısının azalması tek başına kalite ölçütü değildir; bazı açık kuralların ayrı yazılması kodu uzatırken incelemeyi kolaylaştırabilir.
İlk parçayı yayınlanabilir durumda tamamladıktan sonra bir sonraki hedefi seçin. Örneğin veri tiplerini sıkılaştırma sonraki değişiklik olabilir. Böyle ilerlemek, eski davranışı koruyan yenilemeyle yeni ürün davranışı eklemeyi ayrı ayrı değerlendirme fırsatı verir ve geri dönüşü daha anlaşılır tutar.
Örnek çıktıları karşılaştırırken tarih, rastgele kimlik veya çalışma anına bağlı alanları ayırın. Bu değerlerin farklı olması dönüşümün iş kuralını bozduğunu göstermeyebilir. Hangi alanların birebir aynı kalacağı önceden belirlenirse karşılaştırma daha anlamlı olur. Aynı zamanda gerçek davranış farkının gürültü içinde kaybolması da önlenir.
Resmî kaynak: OpenAI — Prompting, refaktör iş akışları.
