Avustralya

Miras Kod (Legacy Code) İle Çalışmak 3

Serinin bu 3.makalesinde daha anca yüzeyini kazıdığımız, kötü kokan kodun içinde daha derin temizliğe girişiyoruz. Artık okunabilirliğin biraz olsun arttığı bu kodda biraz daha köklü değişiklikler yapacağız.

Extract Method

Extract Method, belki de en çok kullandığım refactoring yöntemi bu. Bunun için ReSharper gibi araçlar olsa da ben kendim yapmayı tercih ediyorum. Ama buradaki esas sıkıntı kodun neresini extract edeceğine karar vermek. Ben Visual Studio içinde Code Clone analizi yapan bir araç kullandım. (Maalesef bu araç Visual Studio’nun free versiyonunda yokmuş.) Ama kodla biraz haşır neşir olduğunuzda bazı kod tekrarları gözünüze çarpmaya başlar ve siz de refactoring yapmaya başlarsınız.

Örneğin, kodun her yerinde Müşteri hareketlerini loglayan bir kod bloğu var. Bu kod bloğu 6 satır ve hep aynı işi yapıyor. Her seferinde bu kod önce ilgili repository’i tanımlayıp sonra clientId, createdDate, userName ve log’u database’e yazıyor. Bu kod parçasını önce ayrı bir method haline getirip öyle kullanmaya başladım. Bütün kodu değiştirdiğimde bu kod parçasını toplam 90 ayrı yerde, evet yanlış okumadınız yazı ile DOKSAN, kullanıldığını gördüm.

Sadece bu değişikliği yapmak bile kodu kısalttı, okunurluğu ve yönetilebilirliği ciddi derecede arttırdı. Üstelik yarın öbür gün bir bu kodda bir değişiklik yapmak istediğimizde tek bir yerde değişiklik yapmamız yeterli olacak.

ViewModel

Bir MVC (Model-View-Controller) projesinin olmazsa olmazı ViewModel class’larıdır. Bu classların getirdiği esnekliği, kod okuma kolaylığını ve güvenliği belki ileride inceleriz ama basitçe söylemek gerekirse view’da kullanılacak tüm verileri temsil eden class’lara ViewModel diyoruz(en azından ben böyle tanımlıyorum. Diğer tanımlara açığım). Veriyi kullanıcıdan bu şekilde alıp controller’da istediğimiz gibi takla atabiliyoruz.

Bu projede hiç ViewModel kullanılmamıştı. Bunu diğer takım arkadaşlarıma sorduğumda projeye ilk başlayan arkadaşın o şekilde başladığını ve onların da bu şekilde devam ettiğini öğrendim. Yani herkes kodu sorgulamadan doğruluğunu kabul etmişti veya kimse uğraşmak istemedi veya çok acil işleri vardı. Eğer bir işin hemen bitmesi gerekiyorsa ve bu size göz göre göre kötü kod yazdırıyorsa en azından unutmayacağınız bir yere not alın ve ilk fırsatta o kodu düzeltin. Ancak Amca Bob Martin’in dediğini de unutmayalım.


“The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times.”

Uncle Bob Martin

Ben yeni eklediğim bütün sayfalarda ViewModel class’ları kullanmaya başladım. Mevcutları değiştirmek istesem de bunları değiştirmem şirket tarafından istenmedi, boşa bir çaba olarak görüldü. Öylece bırakmak zorunda kaldım. İçime sinmedi ama yapacak birşey yok sonuçta emir kuluyuz.

Magical Strings

Bu isim çok şeker dursa da hem okunurluğu inanılmaz azaltan hem de kodun esnekliğini azaltan bir problem, magical strings. Düşünün, bir başkasının kodunu okuyorsunuz ve customerStatus == “3” diye bir satır var. Ne sihirdir ne keramet, nereden geldi bu 3 (kafiye olmadı idare edin). Bir açıklama satırı da yoksa anlamanız imkansız. Temiz kod hiçbir zaman müşteriye özel kod barındırmaz, clientStatus == 2 gibi kodlar kabul edilemez.

Bu arada açıklama satırı da ayrı bir tartışma konusu. Çeşitli kaynaklar iyi yazılmış bir kodun açıklama(commit) barındırmaması gerektiğini söylüyor. Ben de bu fikre katılmakla beraber bazen karışık bir algoritmanın 1-2 cümle ile nasıl çalıştığının anlatılması okuyanın işini çok kolaylaştıracağını düşünüyorum.

Magical stringlerden kurtulmak için bir kaç farklı yöntem var. Bunlardan ilki Enum kullanmaktır ki bence çok şık bir çözüm. Mesela yukarıdaki örnekte bahsettiğim ClientStatus bir Enum olarak tanımlanıp kullanılmalıdır. Bir diğeri ve benim favorim parametre tablosu kullanmaktır. Hatta bütün sistemi olabildiğince parametrik yapmak, ileride yapılması gereken değişikliklerde koda dokunulmasını da engeller.

Bizim miras kodu incelerken farkettim ki zaten halihazırda müşteriler için bir tag(parametre) sistemi mevcutmuş. Yani bir çok durumda magical stringden kurtulmak için yapılması gereken bir tag tanımlayıp ilgili müşterilerde de bu tag’i aktif hale getirmek. Bu muhteşem bir özellik çünkü ileride bu tag ile hiç koda müdahale etmeden istenilen müşteriler için istenilen özellikler aktif edilebilir.

Mevcut kodda magical stringler çıktıkça karşıma bunları ufak ufak çözmeye başladım. Artık bir sürü parametremiz var. Ancak hiç ne idiği belirsiz stringler ortada fink atmıyor.

Haftaya SOLID prensipleri üzerinden kodu kötü kokulardan arındırmaya devam edeceğiz.

Görüşmek üzere,

Leave a Reply

Your email address will not be published. Required fields are marked *