Bir Üründe Refactor Kararı Nasıl Verilir?
Bugün bir üründe ya da uygulamanın bir bölümünde nasıl refactor kararı veririz, onu konuşacağız.
Öncelikle bu refactor kısmında tüm takımın hemfikir olması gerekiyor. Çünkü olası canlıda yaşanacak tüm problemler doğrudan takımı etkiliyor. “Çalışıyorsa dokunma” tabularının yıkılması gerekiyor :)
Peki neden refactor ihtiyacı duyarız?
- Son kullanıcıdan gelen crash’leri takip etmekte güçlük çekiyorsak
- Yeni bir feature eklerken kırk takla atıyorsak
- Kod tekrarına düşüp side effect oluşturacak hataları öngöremiyorsak
- Sprint içerisinde 2 puanla çözülecek bir kod 8 puanla çözülüyorsa
- Kod performansı iyice düşüyor ve oradaki koda hakimiyet azalıyorsa
Yüksek trafik alan bir bölgede “smell” kokan kodumuz varsa ve günden güne buraya feature isteği geliyorsa, kod artık spagettiden bile uzaklaşıyorsa, orada bir dur demek gerekiyor.
İzleyeceğimiz 2 yol:
- Takıma bilgi geçip değişiklik gerektiğini ve sebeplerini anlatıp bilgi alışverişi yapmak.
- Product Owner’ımıza ya da Project Manager’ımıza durumu açıklamak.
Böylelikle uygulamada zayıf karnımız dediğimiz bölgeyi elden geçirip daha rahat bir geliştirme ortamı oluşturabilmiş oluyoruz. Her gün mayınlı bölgede yürür gibi geliştirme yapmaktansa mayınlı araziyi temizleyip istediğimiz gibi at koşturabiliriz :)
Refactor’un bazen ne kadar çıkmaza girdiğinin farkındayım. Geri dönülemez noktalar oluyor. Ama iş daha da çığrından çıkmadan, böl-parçala-yönet mantığıyla refactor’u küçük parçacıklara bölebiliriz.