Refactoring, çalışan kodun iç yapısını iyileştirirken dışarıdan gözlenen davranışı korumayı amaçlar. Bu ayrım önemlidir: aynı görevde hem yapıyı temizlemek hem iş kurallarını değiştirmek, bir farkın nereden geldiğini anlamayı zorlaştırır. Codex’e refactoring görevi verirken önce değişmeyecek davranışı tarif etmek gerekir.
Korunacak sözleşmeyi örneklerle belirleyin
Bir blogda yazı kartları için tarih, okuma süresi ve kategori bilgisi üç farklı yerde hazırlanıyor olsun. Amaç bu tekrarları ortak bir sunum yardımcısına taşımaktır. Kullanıcı açısından başlıkların, tarihlerin ve kategori bağlantılarının aynı kalması gerekir. Veri seçimi veya sıralama bu işin konusu değildir.
Sözleşmeyi yalnızca “her şey aynı kalsın” cümlesiyle bırakmayın. Tarihi olmayan yazı, birden fazla kategorili içerik ve uzun okuma süresi gibi örnekler seçin. Bu örnekler, ortaklaştırma sırasında kaybolabilecek küçük ayrıntıları görünür kılar. Mevcut davranışın bir kısmı hatalıysa önce bunun korunup korunmayacağına karar verilmelidir.
Şaşırtıcı bir mevcut davranış bulduğunuzda refactoring bahanesiyle sessizce düzeltmeyin. Örneğin boş kategoriye verilen varsayılan etiket ürün kararı olabilir. Davranışı değiştirmek gerekiyorsa bunu ayrı bir değişiklik olarak ele almak, incelemeyi ve geri dönüşü kolaylaştırır.
İlk adımı küçük tutun
Önce tek bir kullanım noktasını ortak yardımcıya taşıyın. Çıktı eşleşiyorsa diğer kullanımları aynı yaklaşımda güncelleyin. Böylece soyutlamanın gerçek ihtiyaçlara uyup uymadığını erken görürsünüz. Bütün dosyaları dönüştürdükten sonra yanlış bir arayüz seçildiğini fark etmek daha pahalıdır.
Yazı kartı meta bilgisinin üç yerde tekrarlanan hazırlığını ortak bir yardımcıda topla. Başlık, tarih biçimi, kategori adresleri ve boş veri davranışı aynı kalmalı. Yeni özellik veya bağımlılık ekleme. Önce mevcut örnekleri belirle; ardından küçük bir dönüşüm yap ve seçilen örneklerde önceki çıktıyla eşleştiğini doğrula.
Bu görevde “daha temiz kod” somut bir hedefe bağlanır: tekrarın tek yerde yönetilmesi. Her kısa kod parçasını soyutlamak gerekmez. İki benzer bölümün ileride farklı değişmesi bekleniyorsa, zorla birleştirmek okunabilirliği azaltabilir. Ortaklaştırmanın gerekçesi gerçek sorumluluk olmalıdır.
Değişikliği incelerken mekanik taşıma ile mantık değişimini ayırt etmek yararlıdır. Bir fonksiyonu başka dosyaya almak çoğunlukla izlenebilir bir adımdır; aynı anda koşulları sadeleştirmek ise ayrı değerlendirme gerektirir. Önce taşıma, sonra açıkça gerekçelendirilmiş sadeleştirme yapmak, farkın okunmasını kolaylaştırabilir. Bu sıra her projede zorunlu değildir, ancak büyük dosyalarda inceleyenin aynı davranışı takip etmesine yardımcı olur.
Eşdeğerliği uygun düzeyde kontrol edin
Saf bir biçimlendirme fonksiyonunda girdi ve çıktı karşılaştırması yeterli olabilir. Veritabanına yazan bir akışta ise yan etkiler de kontrol edilmelidir. Bildirim sayısı, işlem sırası veya hata durumunda geri alma davranışı görünür sonuca dahildir. Yalnızca son ekran görüntüsünü karşılaştırmak bu farkları yakalamaz.
Testlerin uygulamanın iç ayrıntılarına aşırı bağlı olması refactoring sırasında gereksiz kırılma yaratabilir. Bir test belirli yardımcı fonksiyonun kaç kez çağrıldığını doğruluyor ama ürün açısından bunun önemi yoksa, davranış odaklı bir kontrol daha uygun olabilir. Ancak testleri yalnızca yeşil hale getirmek için beklentileri gevşetmek de doğru değildir.
Son incelemede yeni soyutlamanın adını ve sorumluluğunu okuyun. Kullanım yerleri basitleşmiş mi, koşullar tek yerde anlaşılır hale gelmiş mi, gereksiz esneklik eklenmiş mi? İyi bir refactoring, sonraki değişikliği daha açık bir noktadan yapmanızı sağlar. Bu kazancı göstermek için büyük bir yeniden yazıma ihtiyaç yoktur; küçük ve kanıtlanmış bir iyileştirme çoğu zaman daha değerlidir.
