Statik Kod Analizi ve Kod Gözden Geçirme Pratiği

Bu yazıda, yazılım kalite ve test süreçleri esnasında hala gereken önemin ve sürenin verildiğine inanmadığım “Statik Kod Analizi” başlığını inceleyeceğim. Şu bilinen bir gerçektir ki, her yazılım geliştiricisinin aşağıdaki standart yakınmaları vardır.

• Bu projeyi sağlıklı tamamlayabilmek için en az iki katı süreye ihtiyacım var.
• Hem kısıtlı süre veriyorlar, hem de birçok standarda uymam için ciddi iş gücü harcamam gerekiyor.
• Önce sistemi çalışır hale getireyim, sonra sürem kaldıkça ufak hataları temizlerim.

Bu noktada, geliştirici her zaman kalite ve test süreçlerini bir “overhead” olarak görür ancak kendi de bilir ki, aslında yazılım kalitesini arttıran ve kabul edilebilir hale gelmesini sağlayan bu süreçlerdir. Burada önemli olan konu, yazılım testini yapan kişinin, yazılım hakkında sahip olduğu bilgi seviyesinin belirli bir seviyede olması gerekliliğidir, ki bu seviyeyi her zaman gereksinim ve analiz dokümanları tam olarak sağlayamaz. Bu eksikliğin en önemli nedeni; bazı programatik (ve dolayısıyla sistemsel) problemlerin, geliştiricinin kodu yazma stilinden kaynaklanmasıdır. Bu noktada “Statik Kod Analizi’nin özellikle test uzmanı ve geliştiricinin ortak çalışması ile yapılması önem taşımaktadır.

Elimizde çok ayrıntılı bir gereksinim dokümanının olduğunu varsayalım. Kullanılacak her parametre ayrıntılı bir şekilde anlatılmış, yazılımın tüm kullanım durumları ve modları açıklanmış, operasyonel senaryolar tanımlanmış, her şey çok sistematik, olması gerektiği gibi. İş sadece yazılım geliştiricinin gereksinimdeki metinleri tasarlaması ve koda çevirmesine kalmış. Böyle anlatınca her şey çok kolay görünüyor… Ancak bu aşamada uymamız gereken bir çok kural ve uygulamamız gereken faaliyetler var. Bu yüzden projelerde, yazılımın güvenilirliği sağlamak için hazırlanmış bir kodlama standardı olmalı.

Kodlama standardının oluşması ile ilgili örnek verecek olursak,

“Savunma sanayini temel alalım, donanım entegrasyonu konusunda daha önce onlarca projede çalışmış bir geliştiricinin, kendisinin de bildiği ve her projede önemli oranda çıkan, klasik hatalar vardır. Bu hatalar için geliştirici önlemlerini almaya çalışır ancak bu hataların önemi bir kısmı “kodlama mantığı”ndan kaynaklanmaktadır. Bir donanımın entegrasyon kütüphanesindeki bir metodun bütün dönüş değerlerini değerlendirmek birinci önemli adım ise, sorun belirten bir dönüş adımından sonraki “recovery” sürecini yönetmek de diğer bir önemli adımdır. Bu “recovery” adımlarının doğru mantıkta, her noktada benzer şekilde kodlanabilmesi için, bu sorunun “Statik Kod Analizi” esnasında bulunmuş, dokümante edilmiş ve kurumsal hafızaya eklenmiş olması gereklidir. “

Peki elimizde gereksinim ve tasarım dokümanları var kod var ve bir de kodlama standardımız var ne yapacağız bunlarla? Kodun yayınlanmadan önce gözden geçirilmesi lazım. Burada da aslında “kodu neye göre gözden geçireceğiz?” sorusu ile karşılaşıyoruz. Bu soruların ve daha fazlasının cevabı statik kod analizinde saklı.

Statik kod analizini iki kısımda inceleyebiliriz, otomatize prosedürler ile kontrol edilen genel geçer yapısal kod hataları ve amaca özgün kod eksiklikleri. İlk kısım çok önemli olmasına karşın, yazılım geliştirme ortamları aracılığıyla yapılmalıdır, ki son dönemde entegre geliştirme ortamlarının (IDE) bu yöndeki eklentileri çoğalmaktadır. Bu araçları Wikipedia’dan inceleyebilirsiniz.

Ama ikinci kısım yani amaca özgün kod eksiklikleri. Burada aslında birçok yazılımcının da aklında olan bir soruya cevap veriliyor. “Evet kodu yazdım, kod analiz aracının kontrollerine ve ürettiği rapora göre düzeltmeleri yaptım. Ama bu kod analiz aracının konfigürasyonunu da bir insanın yaptığını düşünecek olursak acaba konfigürasyon sırasında bir eksiklik var mı veya bu kod farklı bir algoritma ile yazılsa daha güvenilir veya daha hızlı çalışır mıydı?”

Bu güne kadar donanımlar ve yazılımlar üzerinde bu kadar AR-GE yapılmasının temel  sebeplerinden biri de insanların yapabileceği hataları en aza indirmektir. Ama kritiklik seviyesi yüksek projeleri (Yazılımda çıkacak hataların insan hayatını doğrudan veya dolaylı yollardan tehdit ettiği projeler) ele alacak olursak. Kodlar belirli bir yere kadar araçlarla kontrol edilse de son olarak farklı ve tecrübeli bir bakışın gözden geçirmesi gerekmektedir. Çünkü bir kod analiz aracı kodu yapısal kurallar çerçevesinde inceleyebilir, örneğin “.c dosyasında hard coded veri olmamalı.” “her if ‘in bir else’i olmalı” veya “Ölü Kod Bölümlerinin bulunması” gibi. Ama hiçbiri kullanılan algoritmayı değiştirecek veya iyileştirecek önerilerde bulunamaz.

Bu yüzden kodun yayınlanmadan önce mutlaka farklı bir göz tarafından gözden geçirilmesinde fayda var. Gözden geçirme faaliyeti şu şekilde yapılmalı;

• Öncelikle kodların, yayınlanmış ve müşteri tarafından onaylanmış gereksinim ve tasarım dokümanları ile uyumlu olması gerekmektedir. Her gereksinim/tasarım maddesinin kodda karşılığı bulunması gerekmektedir.
• İlgili proje için oluşturulmuş bir kodlama standardı bulunmalıdır.
• Kodun daha önce statik kod analiz aracında çıkan hatalarının raporu (Bu raporu araçlar sağlamaktadır) bulunmalıdır. Gözden geçirme sırasında bu raporlar doğrultusunda koda hızlıca bir göz atmak genellikle faydalı olur.

Bu gözden geçirme faaliyetinin temel amacı kodu iyileştirmek ve belirli bir seviyede kaliteyi sağlamak olsa da, gözden geçirme sırasında kod analiz aracının bulması gereken yapısal hatalarla da karşılaşılabilir çünkü bu araçların konfigürasyonları yapılırken de hatalar yapılmış olabilir.

Özetle statik kod analizi ve kod gözden geçirmenin avantajlarını şu şekilde sıralayabiliriz;

• Kodlar belirli kurallar çerçevesinde geliştirildiği için bütün ekibin çıktılarında iç tutarlılık sağlanır.
• Daha kaliteli kodlar üretilir.
• Olası hatalar erken tespit edilir. Dolayısı ile testlerde daha az hata çıkar.
• Test süreleri kısalır.
• Ekibe yeni gelen personelin adaptasyon süresi kısalır.
• Gözden geçirme süresi ve maliyeti azalır.
• Yazılım geliştiriciler arasındaki bilgi alışverişi artar.

Kaliteli, hataların kolayca bulunduğu ve düzeltildiği yazılım süreçleri dilerim….

REFERANSLAR

• http://www.emo.org.tr/ekler/f966d9ba0bf9787_ek.pdf
• http://www.guneriu.com/2012/04/kod-gozden-gecirme-nedir.html
• https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Pelin Turan (pturan) @ PROVEN