Opportunistic Refactoring - Fırsatçı Yeniden Düzenleme

Fırsatçı Yeniden Düzenleme

https://martinfowler.com/bliki/OpportunisticRefactoring.html

Ne Zaman?

• Yeniden düzenleme (refactoring) yazılım geliştirme süreçlerine nasıl dahil edilir?

• Geliştirme sürecinde yeniden düzenleme fazları mı olmalıdır?

• Bir iterasyonun ne kadarı yeniden düzenlemeye ayrılmalıdır?

• Yeniden düzenleme işleri için kimin görevlendirileceği nasıl belirlenir?

Bazı özel durumlarda (örneğin teknik borç aşırı yığılmışsa) yeniden düzenleme çalışmalarının planlı bir şekilde ele alınması gerekse de, önerilen pratik yeniden düzenlemeyi fırsatçı bir etkinlik olarak görmektir. Yani yeniden düzenleme fırsatı bulunduğunda nerede kodun temizlenmesi gerekiyorsa herhangi biri tarafından yeniden düzenleme yapılmalıdır.

Kim Yeniden Düzenleyecek?

Takımdaki herhangi biri, olması gerektiği kadar açık olmayan bir kod ile karşılaştığında onu düzeltme şansını kullanmalıdır. Bu yöntem Uncle Bob'ın izci kuralına atfedilir: "Her zaman, kodu bulduğundan daha iyi bir durumda bırak." Takımdaki herkes bunu uygularsa, her gün kod deposu sağlığına ufak katkılarda bulunmuş olur.

Fırsat

Fırsat şu aşamalarda gelir:

• Yeni özellik eklenirken

• Var olan bir özellik değiştirilirken

• Bir hata giderilirken

Bu durumlardan biri hazırlık amaçlı yeniden düzenlemedir (preparatory refactoring). Yeni bir şey geliştirmeden önce, mevcut API farklı bir şekilde yapılandırılmış olsaydı geliştirmenin daha kolay olacağını görürsün. Önce olması gerektiği hale getirecek şekilde yeniden düzenlersin, sonra yeni özelliği eklersin.

Yeni özellik eklerken, yeni eklediğin kodun mevcut kodla birlikte kod tekrarına neden olduğunu görürsün, bu nedenle var olan kodu yeniden düzenlemen gerekir. Bu, koda sürekli bu şekilde özenli bir şekilde dikkat etmek önemlidir, ancak şu hatırlanmalıdır: sadece testler yeşilse yeniden düzenlemelisin.

Bazen bir işin ortasındayken bir fırsat görürsün. O anki düşünce akışını kesmemek için not alarak, bir todo ifadesi ekleyerek bu düzenlemeyi sonraya bırakabilirsin. İşini bitirdiğinde düzenlemeye geçmek daha iyidir. Bunu çok geciktirmemek gerekir, örneğin en geç o gün düzenleme tamamlansa iyi olur.

Karşı Görüşlüler

Bazı kişiler yeniden düzenlemenin yeni özellik eklemek için kullanılabilecek zamandan kaybettirdiğini düşünür. Ancak yeniden düzenlemenin asıl amacı da zaten budur: kodu daha kolay değiştirilebilir hale getirmek ve yeni özelliklerin daha hızlı ve kolay eklenebilmesini sağlamak. Yeniden düzenleme fırsatlarına zaman ayırmazsanız kodun kalitesi zamanla düşer, kod çürür ve daha yavaş ve uzun süren bir geliştirme süreciyle başbaşa kalırsınız. Bunun sonucunda da proje sponsoruyla yeniden düzenleme iterasyonu gerekliliği hakkında zorlu pazarlıklara girmeniz gerekir.

Nerede Duracağını Bilmek

Tavşan deliğinden derinlere doğru gitmek gibi hakiki bir tehlike de vardır. Bir şey düzeltirken başka bir şey fark edersiniz, sonra da onu düzeltirken başka bir şey. Maharetli bir şekilde fırsatçı yeniden düzenleme yapabilmek iyi bir değerlendirme ve yargıda bulunma özelliği gerektirir. Kodu bulduğundan daha iyi durumda bırakmak isteyebilirsin ancak olması gerektiğini düşündüğün hale gelmesi o kod bölümüne yapacağın bir sonraki ziyareti de bekleyebilir. Her seferinde biraz iyileştirirsen sık ziyaret edilen bölümler zamanla zaten daha iyi hale gelecektir, ki bu bölümlerin temiz olması daha değerlidir. Programlamanın çoğu gibi bu karar da düşüncelilik gerektirir.

Nereyi Yeniden Düzenlenmeli?

Fırsatçı yeniden düzenlemenin özelliklerinden biri, çalıştığın projede herhangi bir yere uygulanabilmesidir. İşinin çoğunu belli bir sınıfta yapıyorken, tamamen farklı bir bölgede sorunlar tespit edebilirsin. Orada çalışmıyor olman değişikliği şimdi yapmanı engellememeli. Kodun diğer bölümlerindeki değişiklikleri başka bir güne bırakmak genelde cazip görünür, ancak o diğer gün çoğu zaman gelmez. (bkz. Later Equals Never).

Testler

Yeniden düzenleme iyi bir regresyon suitine sahip olmaya bağlıdır ve testlerin olması gerektiğinden zayıf olduğunu düşündüğünüz uygulama bölümlerine dokunurken temkinli olmak akıllıcadır.

• Tavşan deliğinden çok derinlere inmeden bir-iki fazladan test eklemek oldukça mantıklıdır.

• Kasıtlı hatalar üreterek (kodu hatalı hale getirerek) testin bu durumu yakalayıp yakalayamadığını görmek de güvenlik ağının ne kadar iyi olduğu hakkında bir fikir verir.

Yeniden düzenlemeyi engelleyen etkenler

Fırsatçı yeniden düzenlemeyi engelleyecek geliştirme pratiklerinden kaçınmalıdır.

• Güçlü Kod Sahipliği -> Ortak Kod Sahipliği

• Özellik dalları (Feature Branch) -> Trunk based development

Özellik dalı yeniden düzenleme isteğini engeller, çünkü kodu birleştirmeyi zorlaştırır. (Gelişmiş araçlar kod birleştirmeyi daha akıllı ve kolay hale getirmiş olabilir, ancak Anlamsal Çakışma (Semantic Conflict) olasılığını engelleyemezler.) Birkaç günden uzun süre yaşayan dallarda durum iyice zorlaşır.

Sonuç

Çoğu takım yeterince yeniden düzenleme yapmıyor, bu nedenle insanları bunu yapmaktan alıkoyan nedenlere dikkat etmek önemli. Küçük bir yeniden düzenleme yapmaktan alıkoyan durumları tespit etmek için dikkatli olmak gerekir. Böyle bir engel, hakkında konuşmayı gerektirecek bir kötü kokudur. Konuyu takımın gündemine getirerek çözümlemek gerekir.

Yeniden düzenlemeyi, koşullu ifadeler yazma gibi sürekli yapılan ve programlamanın düzenli, bölünmez bir parçası gibi görmek önemlidir. Yeniden düzenlemenin planlanması gereken bir etkinlik olduğunda dair yanlış bir algı vardır. Şüphesiz böyle bir planlamayı gerektirecek durumlar olabilir. Örneğin birkaç ayda bir herkesin önüne çıkan bir sorunu çözmek için 1-2 gün ayrılabilir. Ancak yeniden düzenlemeyi iyi uygulayan takım böyle bir planlamaya ihtiyaç duymaz. Yeniden düzenlemeyi, kodun sağlığını koruyan sürekli, küçük ayarlamalardan oluşan bir akış olarak düşünmeliyiz. (Teknik borç da ancak bu şekilde engellenir.)