Data Vinci 27 : Kod Kalitesi

Tahmini Okuma Süresi: 8 dakika

Lacoste, Barbour, Nike, Tommy, Helly Hansen, Sony, Ferrari. Markalar markalar… Kazandığınız paracıkları birkaç saniye içerisinde tırtıklamaya her an hazır milyar dolarlık devler. Fakir ruhlarımıza atılan ince çizikler, cüzdanlara ise balyoz . Markaların sunduğu ayrıcalıklardan en başta geleni prestij iken, diğer tarafta da “kalite” vaatleri var.

Yazılım dünyasında da kalite kavramı hasıl olmuştur. “Code Quality” denen başlık altında çeşitli hesaplama yöntemleri ile kodun kalitesinden bahsedebiliyoruz. Kodun kalitesi için neler yapıyoruz ?, kullanılan metrikler nelerdir?, dikkat edilmesi gereken noktalar gibi sorulara cevap arayacağım bu yazı, bam tellerimize dokunan bir konudur. Soyut olan bu kavramı gündelik hayat örnekleriyle karşılaştırarak fikirlerimizi pekiştirelim. Öncelikle kaliteli olan şeylerin genel karakteristiklerini öne çıkartarak “genelleme”ler yapalım.

Ucuz kalitesizdir.

Evet. Genellemenin ve ön yargının dibi. Her zaman ucuz şeyler kalitesizdir diyemeyebiliriz. Fakat konu hakkında ünlü sözler bile üretilmiş. “Ucuz alacak kadar zengin değilim”. Bir ürünü ucuz olarak sunmayı sağlayan özellikler, dayanıksızlık, kalitesiz malzeme, tasarım eksiklikleri ise sıkıntılıdır. Haliyle ucuz fakat kalitesiz, yarı yolda bırakacak , cinnete getirecek durumlar doğurubilir.

Kullan-At ürünler kalitesizdir.

Bir diğer genelleme. Ucuz kalitesizdir inanışına nispeten daha tutarlı bir tespit olabilir. Adı üstünde kullan ve at. Özenmeye gerek yok, uzun vadeli amaç yok. Dolayısıyla kalite beklentisinin de düşük olduğu ürünlerin kaliteli olmasına çok da gerek yok.

Bir programın içerdiği kod açısından değerlendirecek olursak, yazılımın maliyetinin düşük olması için yapılan fedakârlıklar, eksik analiz, eksik dokümantasyon, kodlama standartlarının uygulanmaması, ünite testlerinin yapılmaması gibi işlemler ise doğal olarak kod kalitesini düşürecektir. Kısa sürede ortaya çıkan, uzun süreli planlara sahip olmayan projelerde kalitenin düşük olma ihtimali de yükselecektir. Kısa sürede ortaya çıkması durumunu da maliyetin azaltılmasına , dolayısıyla da “ucuz” olmasına ilişkilendirilebilir.

Kaliteli kod için çeşitli kural setleri oluşturulmuştur. Bu setler kişi ve kurumlara göre değişiklikler gösteren subjektif ve genel-geçer kurallardır. Bu kurallardan bazılarına değinelim.

  • Style Guide denilen programlama dilini ait en iyi pratikleri içeren dokümanlara uygun davranmak.
  • Değişken isimlendirmeleri, anlaşılır gerektiği kadar uzun, fazla uzun değişken isimleri okumayı ve anlamayı zorlaştırır. Mantıklı, yapılan işi tanımlayan isimlendirmeler önemli.
  • Her ne kadar tanımlamalar az çok yapılan iş hakkında bilgi verse de, gerekli yerlerde yorum satırı kullanmak ve nihayi bir dokümantasyon oluşturmak çok faydalıdır.
  • Bir takım kod geliştirme pratikleri var bunları uygulamak elzemdir. Örneğin, Don’t Repeat Yourself, KISS gibi.
  • Versiyon kontrol sistemleri kullanmak programa bir hafıza kazandıracaktır. Kullanılmalıdır.
  • Ünite testlerinin yapılması, TDD altında incelenebilecek bir madde. Kısaca kodun çalışıp çalışmadığı kontrol edilmeli, bu kontrollerde otomatik testler ile yapılabilir.
  • Veri yapıları ve algoritmaları kullanmak, tasarım desenlerini nerede kullanabileceğini bilmek önemlidir.
  • Tekerleği, Amerika’yı yeniden keşfetmeye çalışmamak. Bazı durumlarda üçünçü parti kütüphaneleri veya çerçeveleri kullanmak gerekir.

İyi bir kod deposu için  Temiz, basit, hatasız, dokümante edilmiş, genişletilebilir, test edilmiş  olmak gibi bir takım özellikler gerekmektedir.

İyi hoş güzel yazıyorsun da, kime göre, neye göre ? sorularına cevap vermiyorsun diyenler olabilir. Bu işin bir standartı yok mudur?

– Kod yazacağım

+nasıl kod yazacaksın?

– Temiz ve kaliteli

Gayet klişe ve objektiflikten uzak bir bakış açısı. Avam ve yer yer fakir.

Kodun temizliği ve kaliteliliği yazılım ekiplerinin bilgi seviyelerine, tecrübelerine, uygulanan yazılım geliştirme metoduna göre değişiklik gösterilebilir.

Tüm bu hengameyi standartlaştıran bir üst akıl, bir bakış açısı yok mu sorusu sorulduğunda cevabımız CMMI olacaktır.

Capability Maturity Model Integration diye geçen bu fularlı konu, CMMI enstitüsü tarafından yönetilmektedir. Kısaca yazılım geliştirme süreçlerinin olgunluğunun değerlendirildiği bir modeldir. Bu modeli araştırırsanız olayın artık koda yorum koymamışın hacı’dan çıkıp, sürecin ve planlamanın önemine vurgu yapılmaya başlandığını görürsünüz. Tam fular.  Birkaç aşama içeren bu olgunluk modelinde fakir ruhlu “kodlamacı”ları cezbeden şeyler pek yoktur.

Bir başka okuması bile karizma kavram olan Cyclomatic complexity ise biraz daha teknik bir bakış açısı ile kod karmaşıklığının değerlendirmesini yapar. Daha önceki yazılarımda değinmiş olduğum bu kavramda kaliteli kod tanımlamasına matematiksel bir çıktı üretmektedir.

Data Vinci 13 : High Cohesion

Unutmayalım ki ölçmediğimiz, ölçemediğimiz bir şeyin performansı hakkında ahkâm kesemeyiz. Hâl böyleyken ölçüm yapmak için bir takım araçlar kullanmak gerekebilir. SonarQube ilk aklıma geleni. Güvenlik açıklarını (security vulnerability) , hafıza sızıntılarını  (memory leak), ve kötü kokuları (code smells) tespit edebilen, birçok popüler programlama diline destek veren bir araç. Line of code,  complexity, duplication, dependency gibi kaygılardan istediğinize kurallar yazabilir ve kontrol edebilirsiniz. Kod blokları için, metotların uzunlukları, sınıfların uzunlukları, yine bu objelerin karmaşıklıkları, parametre sayıları, stil, isimlendirme standartları gibi birçok veriden ölçümleme yapılabilir. Klişe bir şekilde ölçmediğim şeyi yönetemem diyebilirsiniz, diyelim ki ölçtünüz bunlardan aksiyon çıkartılmıyorsa yine GG.

Martin Woodward bu konuda metriklerin faydalı olması için kabaca bu metriklere göre bir şeylerin değiştirilmesi ve ödül veya ceza ile kullanılması gerektiğini söylemektedir.

TL;DR

Bu yazıda kod kalitesi ile ilgili bir takım bilgiler aktarmaya çalıştım. Metriklerden, CMMI kavramından bahsettim. Kod kalitesini arttırmak için genel-geçer kabul görmüş bazı kuralları listeledim. Unutmayalım ki kod kalitesi ile organizasyonunun kalite tanımı arasında sıkı bir ilişki var. Seçilen metrikler ve kaygılara göre bu listeler değişecektir. Kod yazım kuralları ise aşağı yukarı benzer olmakla birlikte, programlama dilleri arasında farklılık gösterecektir. Faydalı olması dileklerimle.

Kaynaklar

 

 

Leave a Reply

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