Legacy Kodla İlk KarşılaşmaYeni bir işe başladım ya da eski bir projeye dahil oldum, ilk baktığım şey tabii ki kod. Karşıma çıkan şey, içinde global state'lerin uçuştuğu, 500 satırlık tek bir metodun olduğu, magic number'larla dolu bir dosya. "Bu ne yapıyor arkadaş?" diye sordum kendi kendime. Dokümantasyon? Tabii ki yok. Orijinal yazan kişi? Çoktan şirketten ayrılmış. Kafayı yiyecektim.
Test Yazma Fikri ve İlk AdımStackOverflow'da bile direkt bir çözüm bulamadım. Sonra aklıma bir fikir geldi. "Kodu anlamak için onu test edeyim!" dedim. Amacım baştan sağlam bir test suite oluşturmak değildi, sadece ne yaptığını görmekti. Hemen basit bir test dosyası açtım ve bu gizemli fonksiyonu çağıran bir test yazmaya başladım.
JavaScript:
// Bu koca fonksiyon ne döndürüyor acaba?
const result = legacyMagicConverter(inputValue, true, 42);
console.log('Sonuç:', result);İlk testim çöktü tabii, çünkü inputValue diye bir şey yokmuş. Meğerse fonksiyon, global bir config objesinden okuyormuş. Bak, kodun nasıl çalıştığını anlamaya başladım bile!
Testler, Canlı Bir Dokümantasyona DönüşüyorHer yazdığım küçük test, bana o karanlık kod parçası hakkında bir ışık yaktı. "Şu parametre null gelirse ne oluyor?", "Burada 42 yazmış, acaba neden?" gibi soruların cevaplarını, testi çalıştırıp hatayı okuyarak buldum. Yazdığım testler, o an için o kodun canlı, çalışan bir dokümantasyonu haline geldi. Meğerse sorun şuradaymış: fonksiyon, belirli bir edge case'de NaN döndürüyor ve bu da sistemin başka bir yerinde sessizce patlıyormuş.
Sonuç ve İtirafŞaka gibi ama, o berbat legacy kodu refactor etmeye başlamadan önce yazdığım o ilkel, amatör testler, bana en büyük güvenliği sağladı. "Şimdi değiştirdim, bir şeyi bozdum mu?" sorusunun cevabı hep oradaydı. Kodun ne yaptığını yaparak öğrendim.
Siz de böyle korkunç bir legacy kodla karşılaştığınızda, ilk iş olarak onun için küçük testler yazmayı denediniz mi? Yoksa direkt koda dalıp, her şeyi alt üst mü ediyorsunuz? Daha temiz bir yönteminiz var mı?