in Eski Blog Yazılarım

C# Refaktoring Ipuçları

Yazılım sektöründe ve hatta BT gezgeninde genel olarak söylenen bir söz vardır “Çalışıyorsa Elleme”.
Bazı sistemlerde doğru olsada yazılım geliştirme prensipleri çerçevesinde bu çok iyi bir şey değildir. Çünkü çalıştırdığınız sistemi her zaman için daha iyi, daha hızlı ve stabil hale getirme şansınız vardır.
Diğer taraftan bir işi çözmek için ilk geliştirdiğiniz algoritma genelde ileride probleme yol açabilecek (Code Smell) potansiyele sahiptir ki görüp geriye dönüp gereğince düzeltmek gerekir. İşte bu düzeltme, toparlama yaparken geçirdiğiniz zamana ve kodlarda yaptığınız iyileştirmelere, değişikliklere de yazılım aleminde “Code Refactoring” deniyor.

Kavramlar ve işin teorik tarafı ile Yazılım Mühendisleri ve Bilgisayar Bilimcileri uğraşa dursun biz direkt koda’a dalalım;

Not: Daha fazla örnek, teori ve derine inmek isterseniz “anti pattern, code smell, code stink” gibi şeyleri aratabilirsiniz.

 

Örnekleri verirken yukarıdaki mantıkta ilerleyeceğim. Önce şişman, yavaş koda bakacağız, daha sonrada seksi kod’a bakacağız böylece aradaki fark yukarıda olduğu gibi daha çarpıcı görünecek. Tabi seksi kod’a bakıp, yukarıda ki bayana baktığınızdaki etkiyi alıyorsanız da bilgisayarın başından kalkma vaktinizin geldiğini hatırlatmak isterim.

İnceden başlayalım;

Aynı değişken tipleri, aynı değeri alacaksa kullanabileceğimiz bu yazım seçeneği bir kaç değişkende pek kullanışlı olmasada bazı durumlarda onlarca değişken tanımlamanız gerekdiğinde uzun kod yığınlarında sizi kurtaran bir etki yapar. Aklınızda olsun.

Yukarıda ki örnek aslında çok sık karşılaştığımız bir olay. String’in veya objenin belirlie bir değerde olup olmadığını en rahat if ile buluruz ve koşulları işletiriz fakat programcı dostu if her zaman işinizi kolaylaştırmaz bazende uzatır. Özellikle bool tipi dönüşlerinde kodları kısaltmamızı sağlayan bir düşünce tarzı diyebiliriz.

Başka bir örnekde try..catch kullanımı ile ilgili. Herkesin bildiği gibi bu bloğu kullanmak CLR için oldukça maliyetli o nedenle try…catch blog’unu bir koşul olarak kullanan programcıyı dövseniz kimse ses çıkarmaz. .Net zaten try-catch kullanmayalım diye bize bir sürü method sunuyor. Örneğimizde dosyanın var olup, olmadığını kontrol etmek için kolaylıkla File.Exists() methodunu kullanabiliriz. Böylece try..catch kullanmamıza gerek kalmaz ve kodumuz daha hızlı çalışır.

Diğer taraftan FileStream disposable bir class olduğundan using içinde kullanmak daha doğru olacaktır, ki işimiz bittiğinde otomatik olarak GC’nin ellerine emanet edilsin.

 

Ve tabiki string işlemleri. En çok can çekiştiğimiz ve takla attığımız konulardan biride string işlemleri. Neyse ki .Net bize string üzerinde işlemler yapabilmek için bir ton araç sunuyor. Sol tarafta gördüğünüz string birleştirme işlemi (concatanate derler) her ne kadar dil kurallarına uygun olsada çalışması yavaş, yazılması ve okunmasıda zordur. Daha hızlı, okunması ve yazması kolay hali ise sağ tarata string.format kullanılarak gerçekleştirilmiştir. Tabi string birleştirmeden söz ediyorsan StringBuilder’dan da söz etmemiz gerekir ki aşağıda bir örnek mevcuttur.

Başka bir kötü if örneği. Her ne kadar süslü parantezlerle kodu uzun gösterip “oha, arbiden kısalmış” dedirtmeye çalışamda burda şairin demek istediği şey “refaktoring faydalı bir şey” mesajı dır. Yine burda doğru yerde, doğru koşulun kullanımın yapmış olduğu etkiyi görebilirsiniz. Teşekkürler :?

Yine doğru zamanda ve doğru yerde kullanılan bir koşul operatorü “??”. Bir class’ın null olup olmadığını kontrol eder ve null ise koşulu işletir. If burda yine yapacağını yapmış ve işleri zorlaştırmış fakat aynı imdadımıza ?? koşarak işleri yoluna sokmuş.

Bu sefer işler biraz değişik gerçek hayata daha yakın bir method ile karşı karşıyayız fakat kod harabe! En baştaki array’ın elemanı olup olmadığı daha sağlıklı bir yolla kontrol edilebilirdi, ek olarak yine string birleştirme işleminde .Net’in nimetleri kullanılmamış.

Refaktoring sonrası String’imizi StringBuilder yaptık ki string birleştirme işlemlerinde maksimum performansı alalım, sonra Array’ın bir elemana sahip olup, olmadığınız Linq’in Any() Extension methodu ile kolay bir şekilde öğrendik, arkasındanda AppendFormat() methodu ile de okunaklı bir şekilde stringimizi oluşturduk.

Bu sefer şişman olan sağ taraf oldu. Neden? çünkü kod’u her inceleyen tarafından ne yaptığının anlaşılması gerekiyor bu nedenle biraz daha pseudo’ya kaçırdık. ExecuteTask() methodundan errorCode’a bir değer atanıyor ve o değere görede methodlar çalışıyor fakat sağdaki kodda bir sıfır değerinin ne olduğunu bilmiyoruz. Halbuki bilmek gerekiyor ki bir şey değiştireceksek ilgili methodda değiştirelim. Bizde gittik class’ın başına bu değişkenleri const tipinden ekledik ve condition’a tekrar verdik. Şimdi neyin ne olduğu dahada anlaşılır oldu.

Yorum Bırak

Comment

  1. Doğru sözler. Bir tek ekleme yapmak istediğim yer BASARILI diye değişken oluşturulan yerde de “enum” kullanılsa sanki daha doğru olacakmış.

  2. Emeklerine saglik. Bu arada After_2() methodunda return !string.isNullOrEmpty() seklinde olmali.

Webmentions

  • C# Refaktoring Ipuçları « Orhan Öcal'ın Bloğu 04/06/2020

    […] atılması gerektiğini düşündüğüm C# Refaktoring ipuçları makalesi. Kısa ve öz… http://blog.oguzhan.info/?p=23 Like this:BeğenBe the first to like […]