Kotu yazmis/ilmis kodu nasil anlariz..

kpmakaleler
  • Turgay Can
  • Tarih

    06 Jul, 2015
  • Yorum

    0
  • Görüntüleme

    1551
  • İndirme

    0

Kotu yazmis/ilmis kodu nasil anlariz..

Merhabalar,

Uzun süredir ara verdiğim bloğumu çok özlemekle beraber yazmayıda ve son 2 senedir öğrendiğim o kadar çok şeyi paylaşmak istiyorum ki, lakin zamanımı bu sevdiğim bloğumun tasarımını ve alt yapısını değiştirmekle uğraşıyorum ve tabiki n11'deki agile süreçlerin yoğun temposu!

Gelelim serzenişten sonra blog konumuza!

Kötü kod yazdığımızı anlamamızın ve nasıl önlem alabilirize dair tecrübe ettiğim bir kaç genel kanıyı sizlerle paylaşacağım.

  • Test yazmak zorlaşıyorsa hatta güç hale geliyorsa yada imkansızlaşıyorsa.. Kötüdende öte bir kod yazmışız yada yazılmıştır..

Eğer TDD metodolojisi ile kod geliştirmiyorsanız öncelikle buna kendinizi mutlak alıştırın, zorlayın. Test ile beraber hem kod kaliteniz hemde bug sayınızda yüksek miktarda düşüş olacaktır.

Genelde View yada Controller sınıflarına test yazmak pek alışılagelen bir durum değildir fakat bu ön katmanı karşılayan sınıflarda bazen öyle kod blokları yada metod bloklarıyla karşılaşıyorum ki, test yazmayı bırakın, kodun ne söylediğini anlamak bile ayrı bir efor gerektiriyor.

Bunun için basit çözüm yolları var ;

a - Mümkün mertede çokca test test test yazalım (%80+ coverage iyidir, candır..) :) Buna kendimide dahil ediyorum.
b - Yazdığımız unit testlerinde metod isimleri anlamlı olmalı.. Bir önceki yazılımcı durumuna düşmeyelim ;)
c - Pair programming!! ve Code Review!!

Test yazmak zorlaşıyorsa ;

  • İlgili metoda/sınıfa gereğinden fazla iş yükü yüklemişsinizdir.
    Bir metod düşünelim 4-5 filtreden geçiyor, 3-5 servis çağırıyor, sonra bu servislere göre işler yapıyor derken bir bakmışız ortada bir logic var ve bu 30-40 satırı geçmiş..
    Bu noktada bizim kocaman 30-40 satırlık metodumuzu ya daha anlamlı metodlara, bana kalırsa yapılabiliyorsa ve daha anlamlı gelebiliyorsa daha anlamlı servislere dağıtmalı ki, iş mantığını servislere üzerine yıkıp, hem test yazılmasını kolaylaştırıp, hemde iş parçalarını genel kullanıma açmış olursunuz. Aynı işi farklı bir modül yada servis ihtiyaç duyduğunda aynı kod bloğunu çağırmamış olacak, hem duplike kod oluşmayacaktır.. Ve yine yeniden test açısındanda rahatlık :)

  • Bir metoda anlamlı ve kısa bir isim veremiyorsanız ; Bu aslında size şunu söyler, eyy yazılım geliştirici kardeş, ben bu kaba sığmıyorum beni daha anlamlı daha küçük metodlara bölersen sende mutlu olursun bende daha anlamlı olurum. bkz : bir önceki yazılımcı durumu!

  • Yazdığımız kodlar bizlerle beraber mezara gitmeyecek o sebeple, iş yeri içinde paylaşıma açmalı code review yapmalı, bunu tüm seviyeden yazılımcıların fikirlerini belirtmesi ve kodu iyileştirmek için bana göre şarttır ve code review edecek grup içinde kodu yazan kişiye göre daha tecrübeli kişilerin olması avantajdır yada olmazssa olmazdır(opsiyonel).

  • Öyle bir iş yapıyorusz ki, psikolojiye göbekten bağlı! Bazen öyle bir psikoloji ile bile çok iyi bildiğiniz bir dizayn pattern ( yada best practice) bile oldukça kötü implement edebilirsiniz. Bu noktalarda sizin kurtarıcınız, pair'iniz yada kodu test, prod ortamlarına atmadan code review ile kompanse edebilirsiniz.

  • Bir kod bloğu içinde tekrar eden 3-5 ve daha fazlası if bloğu varsa yada switch case'ler orada zaten gözü irite eden bir şey vardır. Yazdığımız kodu inceleyip, yapılan işi daha iyi nasıl yazılabileceğine bakılmalı.. Eğer if blokları içinde kontrol edilen mantık her koşulda aynıysa fakat parametrelerin değerlerine göre şekilleniyorsa, bir Builder sınıf ve chain rule yada decorator pattern ile bu kötü kodu ortadan kaldırabilirsiniz.. Bu noktada yaptığınız işe bağlı olarak değişeceğinden ucu açık size bırakıyorum.

  • Kod, metod tekrarı.. (elzem olmadıkça) kötü kod habercisidir.

  • Bir metod'a 3 adet parametreden fazla parametre geçiyorsanız.. Bu aslıda kötü bir kullanım bunun yerine builder pattern'i kullanmak her daim iyidir ;)

Ek olarak, yazdığınz kodu bolca tekrar tekrar okuyunuz, daha anlaşılır nasıl yazarıma kafa yorunuz, iş yoğunluğunda zor fakat en azından bir kaç defa okuyup, kodunuzu refactor etmeyi unutmayınız.

Keyifli kodlamacalar ;)

0 Yorum..

Yorum yapmak için "Giriş yapın" yada "Misafir üye" olarak yorum yapabilirsiniz.

Yorum Yap