Refactoring ( Kod Düzenleme) Nedir?
Hem unit test nedir yazımda hem de code smells ( kod kokuları ) yazımda değindiğim refactoring konusundan bu yazıda sizlere detaylıca bahsetmek istiyorum.
Refactoring ( kod yeniden düzenleme ) nedir, ne zaman ve nasıl yapılır sorularını cevaplayacağım bu yazıyı sonuna kadar okuduğunuzda kod kalitenizde gözle görülür farklar ortaya çıkarabilecek bilgilere sahip olacaksınız. O zaman hazırsanız vakit kaybetmeden başlıyoruz 🫵.
Öncelikle refactoring ( kod yeniden düzenleme ) nedir sorusunu cevaplayıp onu aradan çıkartalım ✅.
Refactoring mevcut kodların dış davranışını değiştirmeden daha basit, daha anlaşılır, değiştirmesi ve bakımı daha kolay hale getirmek için iç yapısında gerçekleştirilen değişikliklerdir. Daha da kısacası kodun yaptığı işi değiştirmeyi amaçlamaz. Yapış şeklini iyileştirmeyi ve geliştirmeyi amaçlayan bir disiplindir.
‘Peki madem kodun yaptığı işi değiştirmiyoruz, ya da yeni bir görev eklemiyoruz. Eee o zaman neden refactoring ( yeniden düzenleme ) yapmamız gerekiyor?’ diye sorduğunuzu var sayıyorum. Bu noktada ben hem gereklilik olarak hem de faydalar açısından yeniden düzenleme konusunu ikiye ayırmak istiyorum.
Gereklilik Olarak Refactoring
- Eğer mevcut kod, ilk bakışta kendisini anlatmıyorsa yeniden düzenlenmeye ihtiyacı var demektir. Çünkü aynı kodu farklı bir geliştirici okuyabilir, ya da birkaç ay sonra kendi yazdığımız kodların ne işe yaradığını unutma olasılığımız oldukça yüksektir.
TR: Cinayet dosyalarındaki gizemleri çözmek gereklidir. Ama kod çözümlenmesi gereken bir şey değildir. Kod okunabilir olmalıdır.
ENG:It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it. Steve C McConnell 🔗
- İkinci olarak projeye yeni bir özellik eklemek istediğimizi var sayalım. Ancak kodumuzun yapısı bu değişikliğe pek de uygun görünmüyorsa, öncelikle kodumuzu bu değişikliğe uygun hale getirmeli yani refactor etmeli, sonrasında kolaylıkla değişikliği yapmalıyız.
‘First make the change easy, then make the easy change’ Kent Back.
- Üçüncü olarak da yazılım geliştirme süreçlerinin ayrılmaz bir parçası olan hata ayıklama ( debug ) işlemi de beraberinde refactoring işlemini gerektirir. Çünkü bir hatayı ortadan kaldırmak genellikle kod üzerinde değişiklik yapmayı gerektirir. Bu değişikliğin yeni bir hataya sebep olmaması için üzerinde çalışılan bölümün iyileştirilmesine de zaman ayrılmalıdır.
Faydalı Bir Disiplin Olarak Refactoring:
- Düzenli olarak refactoring yapmak sistemi temiz, okunabilir ve güncel tutar. Biliyoruz ki iyi bir yazılım değiştirmeye ve geliştirmeye açık olmalıdır. Refactoring disiplinini korumak beraberinde bu faydaları getirir.
- Düzgün bir mimari yapı oluşturabilmek için kullanılacak malzemenin sağlam, temiz ve kullanışlı olması gerekir. İnşaat terimleri gibi görünse de aynı bakış açısını yazılım için de uygulayabiliriz. Refactoring güvenli, kararlı ve sağlam bir mimari temel üzerinde çalışan bir yazılım geliştirmeyi kolaylaştırır.
- Daha açık ve anlaşılır bir kod yapısına sahip olmak hata olasılığını azaltır.
- Yeni bir geliştiricinin projeye dahil olma sürecindeki sürtünme de böylelikle azalmış olur.
Kodları yeniden düzenlemeye neden ihtiyaç duyduğumuzu ve bu disiplinin faydalarını ele aldığımıza göre, ne zaman refactoring yaparız sorusunun cevabına geçebiliriz 🤝.
Refactoring Ne Zaman Yapılmalıdır
Öncelikle kod kokularını tespit edebiliyor olmak, refactoring yapmanın ilk adımıdır. ‘Henüz nasıl çözebileceğimi bilmiyor olsam da, burada bir sorun olduğunu hissediyorum’ dediğiniz noktada çözümün bir çeşit refactoring olması muhtemeldir.
Bu ihtiyaca paralel olarak geliştirme süreci içinde dokunduğumuz bölümlerde düzeltmelere gitmek, gerekli testleri eklemek ve TDD prensiplerini uygulamak ( zaten refactoring içerir ) elzemdir. Böylelikle bir noktada proje içindeki test kapsamı da artış gösterecektir.
Ayrıca bütün projenin yeniden yapılandırılması ihtiyacından da bahsedebiliriz. Bu durumda işlemin sürece yayılması gerektiğini, bir planlama gerektirdiğini ve ekip çalışmasına dayandığını baştan kabul etmek gerekir. 🔗
Çünkü ortada uzun bir zaman diliminde geliştirilmiş bir ürün vardır. Bu ürünün kısa bir süreçte yeniden yapılandırılması ve TDD prensiplerine uygun hale getirilmesi pek olası değildir. Gerçekçi olarak öncelikle sürecin planlanması ve ekip üyelerinin sorumlulukları hakkında bilgilendirilmesi gerekir.
Sonrasında geliştirme devam ederken eklenecek her yeni kod parçacığının TDD prensiplerine uygun olarak eklenmesi ikinci adım olmalıdır. Böylelikle mevcut problemin büyümesi önlenir ve proje ( eğer barındırmıyorsa ) test kapsamına alınmaya başlanmış olur 🎯.
Ek olarak bu sürecin takım çalışması olması gerekir. Çünkü bir ya da birkaç geliştirici refactoring ile ilgilenirken diğer ekip üyeleri olağan şekilde çalışmaya devam ederse mutlaka çakışmalar ( conflict ) ortaya çıkacaktır. Bu da refactoring yapan geliştiricinin boşa kürek çekiyormuş hissi yaşamasına sebep olabilir. Ayrıca bir yandan proje yine TDD’ye uygun olmayan şekilde geliştirilmeye devam ettiği için nihai hedefe ulaşmak pek de mümkün olmayacaktır .
Tüm bu sebeplerden ötürü kapsamlı bir refactoring süreci bir ekip çalışmasıdır ve TDD prensiplerine uygun geliştirilmemiş bir projenin dönüşümü gerçekleştirilecekse bu noktalara dikkat edilmesi gerekir.
Buraya kadar okuduğunuz için tebrik ederim 🥇. Bu yazıyı okuduktan sonra herhangi bir kod yapısına bakışınız değişecek ve artık bazı şeylerin yeniden düzenlenme yoluyla daha iyileştirebilir olduğunu kısa sürede anlıyor olacaksınız.
Türkçe ve anlaşılır kaynak eksikliği olduğunu düşündüğüm konularla ilgili yazmaya devam edeceğim. Eğer bu yazıyı faydalı bulduysanız beğenmek, paylaşmak ya da alkış atmak suretiyle destek vermeniz beni mutlu edecektir 🥳.
Sonuç:
- Refactoring’in ne olduğunu öğrendik mi? ✅
- Peki neden refactoringe ihtiyaç duyduğumuzu anladık mı? ✌️
- Ne zaman refactoring uygulamak için kolları sıvamamız gerektiğini de hafızaya attık mı? 👍
- Bu sorulardan bir tanesine ‘Hayır’ cevabını veriyorsanız 4 dakikada yazıyı tekrar okuyarak ya da aşağıda eklediğim referanslara göz atarak tekrar deneyebilirsiniz 🫶
Anlamadığınız, açık olmadığını düşündüğünüz ya da ekstra anlatıma ihtiyaç duyduğunuz yerlerle ilgili benimle çekinmeden bağlantı kurabilir, irtibata geçebilirsiz.
https://www.linkedin.com/in/eyupmert/
Siz de burada öğrendiğiniz bilgileri kolayca yeni ya da mevcut projelerinizde kullanmayı alışkanlık haline getirerek uzun vadede temiz ve anlaşılır kodlar yazan bir geliştirici olabilirsiniz.
Bu yazımı faydalı bulduysanız e-posta bültenime kayıt olup diğer yazılarıma da göz atabilirsiniz.
Referanslar:
