Editörün Yeniden Düzenleme Araçları: Elle Değiştirmeyi Bırakmak

Kodda yeniden düzenleme (refactoring), davranışı değiştirmeden yapıyı iyileştirme işidir. Çoğu geliştirici bunu elle yapar: bul-değiştir çalıştırır, dosyaları tek tek gezer, gözle kontrol eder. Editörlerin yıllardır sunduğu yeniden düzenleme araçları ise aynı işi kodun yapısını anlayarak yapar — ve aradaki fark, yalnızca hız değil güvenliktir.

Bul-değiştir neden tehlikeli?

getUser metodunu fetchUser yapmak istiyorsunuz. Bul-değiştir çalıştırdığınızda şunlar olur: farklı bir sınıftaki aynı isimli metot da değişir, bir yorum satırındaki metin de değişir, bir dize içindeki değer de değişir. Üçüncüsü en sinsisidir — kod derlenir, testler geçer, hata aylar sonra üretimde ortaya çıkar.

IDE'nin yeniden adlandırma işlemi ise metni değil sembolü değiştirir: yalnızca gerçekten o metoda ait referansları günceller, dizeleri ve yorumları isterseniz dışarıda bırakır. Bu, dinamik dillerde bile statik analiz sayesinde belirgin biçimde daha güvenlidir.

En çok kullanılan işlemler

Yeniden adlandırma

En sık kullanılan ve en çok değer üreten işlemdir. Kritik faydası psikolojiktir: adlandırma ucuzlarsa, kötü isimler kalıcı olmaz. "İsim yanlış ama değiştirmek riskli" düşüncesi, kod tabanındaki en yaygın küçük teknik borçlardandır — teknik borç yazımızda ele aldığımız birikimin bir parçasıdır.

Metot çıkarma

Uzun bir fonksiyonun içindeki bir bloğu seçip ayrı bir metoda taşır; parametreleri ve dönüş değerini araç kendisi belirler. Bu, uzun metotları bölmenin en hızlı ve en az hatalı yoludur. Ayrıca kendi kendini belgeleyen kod üretir: çıkarılan bloğa iyi bir isim vermek, üç satırlık bir yorumun yerini tutar.

Değişken çıkarma ve satır içine alma

Karmaşık bir koşulun parçasını isimlendirilmiş bir değişkene almak okunabilirliği belirgin artırır: if ($u->s === 2 && $u->d > 30) yerine if ($aboneligiSuresiDolmus). Tersi işlem (satır içine alma) ise gereksiz sarmalayıcıları temizler.

İmza değiştirme

Bir metoda parametre eklemek veya sırasını değiştirmek elle yapıldığında en riskli işlemlerdendir; çağrı noktalarından biri unutulduğunda hata çalışma zamanına kalır. İmza değiştirme işlemi tüm çağrıları birlikte günceller ve yeni parametre için varsayılan değer sunar.

Ön koşul: test ve sürüm kontrolü

Yeniden düzenlemenin tanımı "davranışı değiştirmeden" olduğuna göre, davranışın değişmediğini kanıtlayacak bir mekanizma gerekir. Testler bu güvenceyi verir; test yoksa her yeniden düzenleme bir bahistir.

İkinci güvence sürüm kontrolüdür: yeniden düzenleme, davranış değişikliğiyle aynı commit'te olmamalıdır. Karışık bir commit'te neyin yapısal neyin işlevsel değişiklik olduğunu ayırt etmek imkânsızlaşır ve inceleme değersizleşir. Bu ayrımın gerekçesi için commit mesajı yazımıza, inceleme tarafı için kod incelemesi yazımıza bakabilirsiniz.

Statik analiz: aracın gücünü belirleyen şey

Yeniden düzenleme araçlarının güvenilirliği, editörün kodu ne kadar iyi anladığına bağlıdır. Bu yüzden tip bilgisi eklemek yalnızca hata yakalamaya değil, araç desteğine de yatırımdır: tip belirtilmiş bir kod tabanında yeniden adlandırma ve imza değiştirme belirgin biçimde daha isabetli çalışır. Bu, statik tip tartışmasının az konuşulan ama pratik bir boyutudur.

Dinamik çağrılar (değişkenle metot çağırma, sihirli metotlar, dize üzerinden sınıf oluşturma) araçların göremediği alanlardır. Bu kalıpların yoğun olduğu kod tabanlarında yeniden düzenleme sonrası mutlaka arama yapıp elle kontrol gerekir.

Küçük adımlarla ilerlemek

En yaygın hata, büyük bir yeniden düzenlemeyi tek hamlede yapmaya çalışmaktır: yüzlerce dosya değişir, testler kırılır, geri dönmek zorlaşır ve iş yarım kalır. İşleyen yöntem küçük ve tamamlanmış adımlardır — her adımdan sonra testleri çalıştırmak ve commit almak. Böylece bir noktada durmak zorunda kalırsanız kod tabanı yine tutarlı kalır.

Editör verimliliğini artıran diğer ayarlar için VS Code verimlilik rehberimize, eklenti dengesi için eklenti şişkinliği yazımıza bakabilirsiniz. Editörün yeniden düzenleme yetenekleri için Visual Studio Code dokümantasyonu güncel bir kaynaktır.

Sonuç

Yeniden düzenleme araçları, kodu metin olarak değil yapı olarak gördükleri için elle yapılan düzenlemelerin ürettiği sessiz hataları ortadan kaldırır. Yeniden adlandırma, metot çıkarma, değişken çıkarma ve imza değiştirme — bu dört işlem günlük çalışmanın büyük kısmını kapsar ve bir kez alışıldığında geri dönülmez. Ön koşul iki tanedir: davranışı koruyan testler ve yapısal değişikliği işlevsel değişiklikten ayıran commit disiplini. Bu hafta küçük bir deney yapın: bir sonraki isim değişikliğinizi bul-değiştir ile değil editörünüzün yeniden adlandırma komutuyla yapın ve kaç farklı dosyaya dokunduğuna bakın.