Refactoring Nedir?

Blogumda genelde lisans dönemindeki arkadaşlarıma, kardeşlerime hitap ettiğim için bu yazımda da sizlere çok işinize yarayacak bir kavramdan bahsedeceğim. Refactoring. Bir çoğunuz duydunuz, duymayanlarınızda aslında bir şekilde bunu yapıyorlar fakat bu yazının amacı konuyu tam anlamıyla öğrenmek ve kafanızda (büyük ihtimalle) dağınık halde bulunan bilgileri toplayıp bütünleştirmek olacak. Ayrıca belki hiç bilmediğiniz ve denemediğiniz bazı teknikler de öğrenmiş olacaksınız. Tekniklerin hepsine bu yazıda değinemeyebilirim fakat en azından bir giriş olur diye düşünüyorum.

Bir tanım yapmak gerekirse;

Refactoring; yazılımı daha basit, daha anlaşılır, değiştirmesi daha kolay bir hale getirmek amacıyla iç yapısında yapılan ve yazılımın dış davranışını etkilemeyen değişikliklerdir.

Bu tanım üzerinde biraz durabiliriz. Öncelikle amaç belirtilmiş; yazılımı daha basit ve anlaşılır bir hale getirmek, değişmesi kolay yani flexible yapmak. Daha sonra bu amaca ulaşmak için ne yapmamız gerektiği söylenmiş; yazılımın iç yapısını değiştirmek. En sonda da önemli bir şart belirtilmiş; yazılımın dış davranışını etkilememek.

Refactoring’in ne olduğunu pek anlatamadan amacına geçiyorum ama tanımda önce o söylenmiş, sonra tekrar döneriz. Evet amaç temiz kod yazmak. Peki temiz kod yazmak neden bu kadar önemli. Sonuçta programlama dediğiniz şey bilgisayara ne yapması gerektiğini söylemektir. Yazdığınız kodu bilgisayar kullanır ve sizin istediğiniz şeyi yapar. Zamanla daha iyi bir yazılımcı olursunuz ve bilgisayara anlattığınız şey ile gerçekten istediğiniz şey gittikçe birbirine daha çok yaklaşır. Yani esas olay bu değil midir?

Temiz kod yazmak neden önemli?

Evet aslında kod yazan birçok kişi olaya böyle bakar ve bir açıdan bu doğrudur. Fakat unutulan çok önemli bir nokta var. Yazdığınız kodun tek kullanıcısı bilgisayar değil. Aradan belli bir süre geçtikten sonra o kodu değiştirme ihtiyacı ortaya çıktığında sizin gibi (hatta belkide siz kendiniz) bir yazılımcı daha bu kodu okumak zorunda kalacak. Ve aslında kodun asıl önemli olan kullanıcısı bu kişi. Bilgisayar zaten yazdığınız kodu anlayacaktır, nasıl anladığınız pek bir önemi yok. 2-3 kere daha fazla loop yaptı da yazılımınızın çalışması 0.000000001 ms daha uzun sürdü diye üzülmeyin. Esas sorun aylar sonra kodunuzu okuyup anlayıpta değiştirmek isteyen yazılımcının bu iş için harcayacağı 1-2 haftadır. Eğer temiz bir kod yazmış olsaydınız belki 1-2 saatte kodu anlayıp değiştirebilecekti.

Neredeyse hepimiz çalışan bir kod yazmakla uğraşırken gelecekteki bu kullanıcıyı unutuyoruz. Refactoring’in en temel amacı, kodu yazarken o kişiyi düşünmenizi sağlamaktır. Kodunuzu bir  bilgisayarın değil bir insanın okuyacağını düşünerek yazın. Zaten çalıştığınız şirkette büyük ihtimalle kodunuzu okuyacak kişi de siz olacaksınız ve gelecekteki size düzgün bir kod hazırlamanız gerçekten güzel olur (: Hemen Bilişim Hakkında Özlü Sözler isimli yazımdan örnek vermek istiyorum;

• “Its OK to figure out murder mysteries, but you shouldnt need to figure out code. You should be able to read it.”
  Steve McConnell
• “Any code of your own that you have not looked at for six or more months might as well have been written by someone else.”
  Eagleson

Refactoring’in başka faydası yok mu?

Temiz kod üzerinde çok durdum ama gerçekten işin temelinde bu var gibi geliyor bana. Tabiki bunun dışında da faydaları var. Refactoring sayesinde iyi bir yazılım tasarımı (software design) yapmanız kolaylaşır. Neredeyse hepimizin ezbere bildiği ama pratikte kullanmakta çok zorlandığı tasarım desenlerini (design patterns) kolaylıkla kullanabilmenizi sağlar. Çünkü kod temiz ve düzenlidir ve artık görmekte zorlandığınız incelikleri kolaylıkla görmeye başlarsınız. Yeni hiyerarşiler kurarsınız, aralara interface‘ler koyarak dependency‘leri kaldırırsınız, polymorphism‘ler havada uçuşur, neler neler (: Bu sayede kodunuz kolaylıkla geliştirilebilir, değiştirilebilir, tanınabilir, ve başka projelerde kullanılabilir hale gelir ki bunlar harika şeyler 🙂 Hem bence bunlardan dahada önemli olan şeyler kazanırsınız, mesela yaptığınız işten zevk almaya başlarsınız, kendinizi kod yazan herhangi biri gibi değil, bir yazılımcı gibi hissetmeye başlarsınız. Bir inşaat mühendisi nasıl binayı tasarlıyorsa, sizinde yazılımınızı tasarlamanız, iyi design etmeniz gerekiyor, kod yazmak inşaatın duvarını örmek gibi birşey bence. Bunu altınızda çalışan ustalardan biride gayet yapabilir, sıva ustası değiş mühendis gibi hissetmek için sadece kod yazmayın, refactor yapın 🙂

Bu yazı çok uzadı ve içinde hiç örnek veremediğim için sıkılmanıza yol açabilir diye düşünüyorum, o yüzden birkaç noktaya daha değinip burada bırakacağım.

Ne zaman refactor yapılır?

Aslında sürekli refactor yapmak lazım gibi görünsede bu konuda bazı belli başlı kurallar var. Bu işin üstadlarından Kent Beck‘in “2 şapka teorisi” bize yol gösterebilir. Bunlar ışığında kendi tecrübelerimden örnek vermek istiyorum.

1. Yazılıma yeni bir fonksiyonalite eklediğinde: yeni bir özellik eklediğinizde epey kod yazarsınız ve bu kodun refactor edilmesi gerekir. Kent Beck’in şapka teorisine dönelim. Kendisi 2 şapkanız olsun der, biri koder şapkası, diğer refactorer şapkası. Yeni bir özellik eklerken koder şapkasını takın ve sadece o özelliği eklemeye odaklanın, sadece kod yazın. Refactor yapmayı düşünmeyin. Özelliğin eklendiğine ve çalıştığına inandığınız anda koder şapkasını çıkarıp refactorer şapkasını takın ve yazdığınız kodu design etmeye başlayın. Mükemmel design’a ulaşmaya çalışmak kötü birşeydir ve genelde şeytan vesvesesidir, “iyi” bizim için yeterli. İyi olduğunu düşündüğünüzde davranışın değişmediğini test edin.
    
   
2. Yazılımdaki bir hata giderildiğinde: bir hatayı çözmeye çalışırken de kodu okumanız gerekir. Eğer okuyamıyorsanız okunabilir hale getirmekten çekinmeyin.
    
   
3. Yazılımı gözden geçirirken: birçok şirket bunu yapmasa da, büyük ve kurumsal şirketlerde “code review” denen bir olay vardır. Biz de kurumda sık sık yapıyoruz ve code review sırasında aslında bana göre gayet okunabilir ve anlaşılır duran birşeyi arkadaşımın anlamadığını görebiliyorum. Çünkü anlaşılabilirlik subjektif bir kavram ve birden çok yazılımcının birlikte yaptığı bir code review sırasında refactor yapmak, bu subjektif kavramı mümkün olduğunca objektif hale getirir.

Bu yazıda bu kadar edebiyat yeter diye düşünüyorum. İnşallah bir sonraki yazıda örneklerle çıkacağım karşınıza ve daha okunabilir bir yazı olacak. Yazılımdaki kötü kokulardan ve bunları temizleme yöntemlerinden bahsetmeyi planlıyorum.