“yeterince zaman olmadığı” refactoringle ilgili en fazla duyduğum ortak söylemlerden birisi. Kod ve mimari için günlerce ya da haftalarca sürecek önemli bir refactoring yapılabileceği ve mevcut zaman planlamalarında buna yer olmadığı da sıkılıkla duyduklarımdan.

Takımlar sıklıkla refactoringi kendilerinin değil de sadece zamanı olan diğer takımların yapabileceği bir şey gibi düşünüp gündemlerine almıyorlar.  Yazılım teslim eden  bütün takımların sıkışık bir zaman planlaması olduğu aşikar. Refaktoringe zaman ayırabilmenin anahtarı daha esnek deadline lar değil.( Deadlineların realistik olması gerekiyor ama bu zaten başka bir konu:)

Aristottle’dan şöyle demiş: Bizler sürekli tekrarladığımız şeyden ibaretiz. İşte bu yüzden, mükemmellik bir alışkanlıktır bir hareket değil.

Mükemmel kodlama için de bu geçerli .Dolayısıyla refaktörleme. Refaktorü etkin bir şekilde geliştirme sürecimizin bir parçası haline getirmek için günler ya da haftalar gerektiren bir efor olmaktan çıkartıp daha çok  kod yazarken devamlı uyguladığımız bir alışkanlık olmasını sağlamamız gerekir. Refaktoringi bir alışkanlık haline getirmek istiyorsak bunu nasıl yapabileceğimiz önemli bir soru olarak karşımıza çıkıyor.

Ne zaman Refactoring Yapmalıyız?

Her zaman! Kodu geliştirken bir kaç dakika ayırarak küçük parçalar halinde refaktör ettiğimizde bu kodu yüksek kalitede tutmamızı sağlayacaktır. Şimdi TDD döngüsüne bir bakalım ve refaktoringle nasıl entegre olduğunu görelim.

Test driven development döngüsünde  başarılı yazılan her kod sonrası değerlendirmek ve refaktoring  için zaman var. Pratikte çoğu zaman yazdığınız koda bakarsınız , eğer sizin için ok ise o şekilde bırakabilir ya da ihtiyaç varsa bir kaç dakikanızı ayırarak küçük bir refactoring yaparsınız. 20 yada 30 dakikanızı alacak belirgin bir refactoring ihtiyacı nadiren çıkar. Refactoring yapılan her kod sonrası testlerinizi tekrar koşar ve herhangi bir şeyi bozmadığınızdan emin olursunuz.

Sıklıkla unutulan işin diğer bir sırrı da disposalınzdaki  otomatikleştirilmiş araçları kullanmak. Günümüzde çoğu IDE’nin kendi içinde kurulmuş refaktorü kolaylaştıran araçları var. Bu araçları doğru kullanmayı öğrenerek zamandan iyi şekilde tasarruf eder ve hata risklerini azaltırsınız. Hangi değişikliği yapacağını bilmek ise hala elzemdir.

Legacy Code u Refactoring hakkında?

Hepimiz   daha önce başkası tarafından yazılmış kaliteli kod standartlarında olmayan ancak refactoringi sonsuz zaman alabilecek kod yığınlarıyla uğraşma durumunda kalmışızdır. Bunun nedeni kodun çok kritik bir misyonu olmasından ya da sorgulayamayacağımız birisi tarafından yazılmış olmasından olabilir. Peki bu kodla ne yaparız öyleyse?

Önce bir şeyi kabul etmeliyiz, insanlar herzaman yapabildiklerinin en iyisine çabalarlar, fakat şartlar bazen doğru şekilde yapmamızın önüne geçer. Kötü kodlar da muhtemelen yetkinliği daha iyisini yapabilecek kişiler tarafından yazılmış olabilir, ancak zaman baskısı onlara refactoring için imkan tanımamış olabilir. O zaman bu bizi 1. adıma götürüyor:

Adım 1: Kötü Alışkanlığı kır

Koda daha önce yapılmış olanı değiştiremeyebilirsiniz ancak daha kötü hale gelmesini durdurabilirsiniz. Takım olarak bundan sonrasında refactoringe  zaman ayırmadan kod değişikliği yapmayacağınız konusunda anlaşma yapabilirsiniz. Dosyayı açtığınız herzaman onu bulduğunuzdan daha temiz bırakarak başlayabilirsiniz.

Adım 2: Beklentileri belirle

Bütün problemleriyle miras aldığınız odun  size bırakılması sihirli bir şekilde daha iyi geleceği anlamına gelmiyor.  Takımınızın ve  iş biriminin kodda hangi iyileştirmelere ve ne zaman bu iyileştirmelere ihtiyaçları olduğu konusunda ortak bilgi sahibi olduklarından emin olun. Bazı şeyler doğal akış zamanı gelinceye kadar beklenebilir, bazıları müşteri için sorun yaratıyor ve bazılarıyla hemen uğraşılması gerekebilir. Hemen müdahale edilmesi gerekenler uygun önceliklendirmeyi alabilmek üzere backloga eklenmeli ve hangi iş değerini kattıklarının da anlaşılmış olması gereklidir.

Adım 3: Eforunuzu İzole Edin

Çok miktarda hatalı kodu tek seferde çözümleyemezsiniz. Değişiklik yapma ihtiyacı duyduğunuzda test ettiğiniz belirgin bir davranışı izole edin. Testlerle kavrayın ve değiştirdiğiniz şeyi refaktörleyin. Bu bazendeğişimin olduğu ve eforu odaklamanız gereken  bir ya da iki class tanımlamak kadar basit olabilir. Bazen de kodu izole etmek için biraz çalışmanız gerekebilir.

Legacy kodla nasıl çalışacağımız çok karmaşık olabilir ve sadece bir yazıyla problemi çözümeye çalışmak çok mümkün olmayabilir. Şanslıyız ki bu konuda yazılmış  ve her kod yazanın kitaplığında bulunması gereken iyi bir kitap var:Working Effectively with Legacy Code by Michael C. Feathers (Prentice Hall, 2004)Working Effectively with Legacy Code

Özet

Kısaca , kod refactoring için tek gümüş kurşun yok, fakat iyi pratikler sizi gün ve gün hedefinize yaklaştıracaktır. Kaynak kodu her kapatmaya yakın olduğunuzda refactoring için emek harcayın ve legacay kodu küçük parçalara ayırmak için zaman ayırın. Her zaman modül veya daha üst seviyede sizi yaptığınız değişikleri karşısında koruyacak  otomatikleştirilmiş test uygulayın ve disposalınızdki otomatikleştirilmiş araçları kullanmayı öğrenin.

Bu yazı agile42 koçlarından arkadaşım Daniel Lynn’in İngilizce web sitemizde yayınladığı yazıdan alıntıdır.İçeriğini beğendiğim için  Türkçe blog sitemizde Türkçe olarak paylaşmak istedim. Yazının orjinal haline buradan ulaşabilirsiniz.