Yahu, bu hafta tamam dedik, sadece temizlik yapacağız. Sprint planlamasında masumca "şu servisi biraz refactor edelim, technical debt'i azaltalım" dedik. Herkes kafa salladı, Story Point'ler verildi. İşte o an, felaketin başlangıcıydı.
İlk Domino Taşı: "Şuraya da Bakayım"
Dedim ya, sadece bir DTO katmanını düzenleyecektim. Ama bir metoda tıkladım, o metod başka bir utility sınıfını çağırıyor. O utility'ye baktım, içinde 500 satırlık, kimsenin dokunmaya korktuğu bir "sihirli" fonksiyon var. Son 5 yılda 150 farklı yerde kullanılmış. İşte o an, sprint hedefi buharlaştı.
Keşif Çılgınlığı ve Test Kabusu
Temiz kod yazayım derken, önce o kodu anlamam lazım. Test yok. Log'lar yetersiz. 1 saatlik iş, 1 günlük arkeolojik kazıya dönüştü. Sonra "madem buraya dokundum, test de yazayım" dedim. Mock'lamak için tüm evreni kurmam gerekti. Bir de unit test yazarken, aslında kodun ne yapması gerektiğini değil, ne yaptığını test ettiğimi fark ettim. Kısır döngü.
Beklenmeyen Sonuç: "Bu Kimin Branch'i Bozdu?"
Nihayet temiz, güzel, SOLID prensiplerine uygun yeni bir yapı kurdum. Merge request açtım, övünçle. İlk yorum: "QA'da regression bulduk, senin branch'ten sonra checkout işlemi çöktü." Meğerse o "sihirli" fonksiyon, görünmeyen bir yan etkiyle başka bir modülün cache'ini dolduruyormuş. Ben onu "temizlerken", o gizli bağı koparmışım. Bug'ı fixlemek, asıl refactor'dan daha uzun sürdü.
Sonuç? Sprint hedeflerimiz suya düştü. Product Owner'ın kaşları çatıldı. "Sadece temizlik" diye başladığımız iş, yeni bug'lar, yeni test senaryoları ve bitmeyen bir code review sürecine dönüştü.
Refactor, planlanabilir bir iş değil, bir keşif yolculuğu gibi. Derinlere indikçe karşına çıkan canavarlar belli olmuyor. Siz de böyle "basit bir temizlikle" başlayıp, projenin temellerini sarsan bir maceraya daldınız mı? Bu kaçınılmaz bir kader mi, yoksa kontrol edebileceğimiz bir süreç var mı? Fikirlerinizi bekliyorum, belki birlikte bir çözüm buluruz!
İlk Domino Taşı: "Şuraya da Bakayım"Dedim ya, sadece bir DTO katmanını düzenleyecektim. Ama bir metoda tıkladım, o metod başka bir utility sınıfını çağırıyor. O utility'ye baktım, içinde 500 satırlık, kimsenin dokunmaya korktuğu bir "sihirli" fonksiyon var. Son 5 yılda 150 farklı yerde kullanılmış. İşte o an, sprint hedefi buharlaştı.
Java:
// "Sadece bir kerelik" diye yazılmış, artık her yerde olan fonksiyon.
public static Object buyukSihirliFonksiyon(Object... hersey) {
// 500 satır... Dokunma, patlar.
}Temiz kod yazayım derken, önce o kodu anlamam lazım. Test yok. Log'lar yetersiz. 1 saatlik iş, 1 günlük arkeolojik kazıya dönüştü. Sonra "madem buraya dokundum, test de yazayım" dedim. Mock'lamak için tüm evreni kurmam gerekti. Bir de unit test yazarken, aslında kodun ne yapması gerektiğini değil, ne yaptığını test ettiğimi fark ettim. Kısır döngü.
Beklenmeyen Sonuç: "Bu Kimin Branch'i Bozdu?"Nihayet temiz, güzel, SOLID prensiplerine uygun yeni bir yapı kurdum. Merge request açtım, övünçle. İlk yorum: "QA'da regression bulduk, senin branch'ten sonra checkout işlemi çöktü." Meğerse o "sihirli" fonksiyon, görünmeyen bir yan etkiyle başka bir modülün cache'ini dolduruyormuş. Ben onu "temizlerken", o gizli bağı koparmışım. Bug'ı fixlemek, asıl refactor'dan daha uzun sürdü.
Sonuç? Sprint hedeflerimiz suya düştü. Product Owner'ın kaşları çatıldı. "Sadece temizlik" diye başladığımız iş, yeni bug'lar, yeni test senaryoları ve bitmeyen bir code review sürecine dönüştü.
Refactor, planlanabilir bir iş değil, bir keşif yolculuğu gibi. Derinlere indikçe karşına çıkan canavarlar belli olmuyor. Siz de böyle "basit bir temizlikle" başlayıp, projenin temellerini sarsan bir maceraya daldınız mı? Bu kaçınılmaz bir kader mi, yoksa kontrol edebileceğimiz bir süreç var mı? Fikirlerinizi bekliyorum, belki birlikte bir çözüm buluruz!