Yazılım geliştirme verimliliği ve ölçümleme

Yazılım geliştirme ekiplerinin verimliliğini bakmak ve iyileştirmek her teknik takım yöneticisi için problemdir. Burada kayda değer iki nokta var:

Farkındalık: Takım ne durumda? İyileştirme: Takım daha iyi duruma nasıl kazanç? Ölçmek ve Gözlemlemek: Ölçmeden geliştiremezsiniz Bir şeyi değiştirmeye çalışmadan önce, en manâlı adım nereden başlanacağı. Verimlilik, yalnızca çok fazla iş bitirmek veya daha fazla kod yazmak yok, production ortamında yüksek performanslı, kusursuz ürünler üretmek; yalın ve bakımı basit kod yazmak ve sürdürülebilir development ortamı sağlamaktır. Verimlilik üzerine odaklandığımızda 4 asıl başlık altında metrikleri peşine düşüp takip edebiliriz:

Development kalitesi ve verimliliği Deneme kalitesi ve verimliliği Deployment süreçleri Production kalitesi Aşağıdaki tabloda asıl başlıklar aşağı örnek alınabilecek metrikleri bulabilirsiniz.

Bu metrikler ile nasıl geliştirme yapıldığı, hangi pratiklerin kullanıldığı, testlerin kapsamı ve ne dek verimli olduğu, deployment süreçlerinin ne dek dinç olduğu ve ürünün production ortamında ne değin sorunsuz olduğu ölçülebilir ışık halkası getirilebilir. Bu metrikleri kullanmakta olduğunu vasıta ve metodolojilere tarafından artırabilirsiniz.

Metrikler ve Örnekler Development Metrikleri Development süreci ne değin iyi olursa, test ve işlem ekiplerine düşen ağırlık; uygulamanın test ve production hataları böylece eksik olur. Bunun yanında yazılım pratiklerini iyi kullanan ekipler sürdürülebilir koda; bakımı kolay ve idare edilir uygulamalara sahip olurlar.

Line of Code: Bir developer'ın açıklanmış zamanda yazdığı kodu açıklama eder. Bu metrik kimsesiz bir şey ifade etmez oysa öbür metriklerle bir araya getirildiğinde yardımsever bir değerleme aracına dönüşür. Line of code, complexity ile birlikte düşünülürse manalı bir netice alırsınız.

Örnek değer: 2 haftalık geliştirme süreci 800 satır kod.

Kullanılabilecek araçlar: Gitlab, Bitbucket, Gitwiser kullanarak satır sayısı bilgilerini alabilirsiniz.

Complexity: Line of Code'dan bağımsız yazılan kodun algoritma karşılığı da denilebilir. Bir kod içerisinde her bir if, else, for, while veya farklı method çağırımları complexity değerini bir artırır. Bu durumda 500 satır kod yazmış developerın complexity değeri 100 iken diğer bir developerınki 200 olabilir. Bu durumda ikinci developer algoritmasını daha yoğun yazmış olabilir.

Örnek değerinde : 1000 satırlık 200 complexity değeri bulunabilir.

Kullanılabilecek araçlar : Sonarqube, Gitwiser gibi araçlarla kodun complexity'sini ölçebiliriz.

Technical Debt: Kod içerisinde yer alan hataları düzeltmek için harcanacak zamanı ifade eder. Yanlış yerler başlıca Sonarqube gibi sabit çözümleme araçları ile bulunur ve eforlar bu araçlar kadar otomatik verilir.

Örneğin loglama yerine System.out.println kullanılan bir yeri düzeltmek minör bir hata olarak tanımlanıp düzeltmek için Sonarqube göre 2 dakikalık bir vakit verilebilir. İşte bu hataları düzeltmek için bahşedilen sürelerin toplam değeri teknik borçlanmayı ifade eder.

Misal bedel: 18 saat 22 dakika teknik borçlanma değeri

Kullanılabilecek araçlar : Sonarqube, Fortify, Cast

Unit Deneme Coverage: Bu metrik, yazılan kodun ne kadarına karşılık unit test yazıldığını yüzdesel olarak açıklama eder. Burada “Line Coverage” ve “Branch Coverage” almak üzere iki tanımlama kullanılır. Line Coverage, yazılan testlerin satır sayısının ne kadarına karşılık işletildiğini gösterir. Yani 500 satır kodunuzun 400 satırı için unit deneme yazılmışsa; unit deneme coverage'ınız %80 dir. Branch coverage ise satırları yok içeride if, else, for gibi daha aşağı kırılımların ne kadarını kapsadığına bakar.

Misal değer : %60 unit test coverage

Kullanılabilecek araçlar : Cobertura, JaCoCo, Sonarqube

Cyclometic Complexity : Complexity soylu davranış değerini verirken Cyclometic Complexity karmaşıklık değerini verir. Karmaşıklık değeri ne dek yüksekse bir kodu okuması veya bakımını yapması öyle zordur. bununla beraber sektörde kabul edilmiş bir gerçek vardır: Cyclometic Complexity değeri yüksek kodlarda hata çıkma olasılığı da yüksektir. Her bir if, case, for gibi kod bloğu Cyclometic Complexity değerini bir artırır. Cyclometic Complexity değerlerinin fonksiyon bazında verilmesi beklenmektedir ve sektörde Cyclometic Complexity değerinin 10 üzerinde olması kabul edilir değildir.

Misal değerinde : 0 – 10 kabul edilir Cyclometic Complexity değerdir.

Kullanılabilecek araçlar: Sonarqube, Cast, Fortify

Duplication : Yazılan kodların benzerlik oranıdır. Copy-paste kodlar olarak da değerlendirilebilir. Bu değerin yüksek olması ayrıca re-usability keza de bakım anlamında bir dezavantaj doğurur. Duplication değeri yüksek uygulamaların değişimi zordur. aynı zamanda duplication değeri yüksek uygulamalar satır sayısını olumsuz etkiler. Yani 1.000 satır kodun duplication oranı %40 ise kod yazılmaktan çok copy-paste yapıldığı anlaşılabilir.

Misal bedel : %26.5 Duplication

Kullanılabilecek araçlar : Sonarqube, Cast, Fortify

Code Review : Yazılan kodları static analysis'dan geçirebiliriz ancak keza kuralların kısıtlı olması ayrıca de gözden kaçma olasılığını minimize etmek için başka bir developer veya ekip kadar gözden geçirilmesi ve yorum yapılması talep edilir. Code review süreci için genelde bir review check-list hazırlanır.

Kullanılabilecek Araçlar: GitLab, Bitbucket, Crucible

Refactoring Practice : Yazılan kodun fonksiyonalitesini etkilemeden bitmiş düzenleyerek okunabilir ve bakımı kolay ışık halkası getirilmesidir. Hızlı imlâ hemen gözden kaçan veya okunması zorlama adımları görebilmemizi sağlar. Refactoring check-list çıkarılması beklenen birincil adımdır.

Kullanılabilecek Araçlar: IntelliJ, Visual Studio

Security Bugs : DevOps ya da SDLC süreci içerisinde kullanılan emniyet araçlarının verdiği emniyet zaafiyeti sayılarını ifade eder. Doğru, okunabilir ve beklenilen fonksiyonaliteyi tedarik eden kod yazmanın yanına güvenli kod yazmak da önemlidir. Bu işlem emniyet hatlarının kimler kadar yapıldığını görmemizi sağlar.

Kullanılabilecek Araçlar: Sonarqube, Fortify, Cast, Veracode

Deneme Metrikleri Deneme ortamının yeterli olgunlukta olması ürünlerin production geçişi öncesi tatmin edici kalite olması demektir. Keza aralıksız ve tatmin edici sayıda koşulan testler ile ne kadar sık geri bildirim verilirse takım muhtemel hatalardan öyle erken farkında olan olur ve önlemini alır.

Test Coverage : Fonksiyonel testlerin, ürünün bütün fonksiyonlarının ne kadarını kapsadığının oranıdır. Bu oran yalnızca otomasyondan meydana gelmek zorunda değildir; manuel testler de bu değer içerisine dahil edilebilir. Sayısal bir değerinde yerine tehlike yüzdesi verilmelidir.

Mesela 1.000 mantıksal bağ içerisinden koşulan 300 devamlılık size %70 coverage sağlayabilir. Risk hesaplaması “hata olasılığı x ağırlık derecesi” ya da direk “hata maliyeti” olarak verilebilir. Bu durumda bir süreklilik 4 risk değerini taşırken başka bir akıcılık 20 değerini taşıyabilir.

Kullanılabilecek Araçlar: XRay, Zephyr, Deneme Rail

Automation Coverage : Koşulan testlerin ne kadarının deneme otomasyon ile yapıldığını gösterir. Burada beklenen testlerin olabildiğince otomasyona alınıp sık koşulması ve sürekli geri bildirim vermesidir. Kullanılabilecek Araçlar: Testinium, Deneme Complete, Ranorex

CI/CD Integration: Deneme sürecinin CI/CD entegrasyonunu belirtir. Bu sürecin manuel olması ve kesintisiz işletilmesi zor bir konu. Bu disiplinden ziyade sürecin CI/CD entegrasyonunun yapılması beklenmektedir.

Kullanılabilecek Araçlar: Jenkins, Bamboo, Azure DevOps, GitLab

Peformance Test : Uygulamalar yalnızca fonksiyonalite açsından değil performans olarak da deneme edilmeli ve KPI'lar istenilen seviyeye ulaştıktan sonra daha sonra devreye alım yapılmalıdır. kodlanmış ve fonksiyonalite açısından herhangi bir hataya sahip olmayan ürünler belirtilen bir önem aşağı cevap veremez ayla gelebilir. Bu durum sizi hedeflediğiniz gelire ve garanti ettiğiniz alıcı deneyine ulaşmakta engeller.

Kullanılabilecek Araçlar : JMeter, Gatling, Loadium, Blazemeter

Integration Tests : System entegration testi de denen bu adımda ürünle entegrasyonda olan tüm ürünlerinde senaryoları deneme edilmelidir.

Test Koşum Sayısı: Testlerin amacı mümkün fonksiyonalite ve/veya işlevsel olmayan hatalar konusunda müşterileriniz fark etmeden takıma geri bildirim vermektir. Geri bildirim ne dek erken verilirse böylece çabuk aksiyon alınır, hatanın büyümesi engellenir. İki haftada bir koşulan testler geri bildirim vermek için yavaş kalır. Bu yüzden beklentinizden daha hata çıkarsa çözmek için tatmin edici zamanınız kalmayabilir. Hedef önce jurnal sonra ise commit sayısı kadar deneme koşmak olmalıdır.

Test Veri Management : Testleri sabit veri ile koşmak hataları tutmak için yeterli değildir. Öbür veri setleri ile karşılaşılabilecek farklı durumlar deneme edilmeli ve tek kullanımlık verileri yönetmek için de test verisinin dinamikleştirilmesi sağlanmalıdır.

Kullanılabilecek Araçlar: Informatica, Delphix, CA Test Data Manager, Microfocus TDM

Deployment Metrikleri DevOps metrikleri, DevOps sürecinin her bir adımının olgunluğunu artırmak için kullanılmaktadır. Devops olgunluğu arttıkça daha güvenilir ve sorunsuz ürünler ortaya çıkar. Bu süreçleri kişilerin insiyatifine vazgeçmek süreçteki herhangi bir adımın atlanmasına ya da insiyatif sahibi takımdan ayrıldığında neden olabilir.

Automated Deployment: Süreçlerin atlanmadan her bir adımının kesinkes işletilmesini açıklama eder. Bu süreci işleten ekiplerin olgunluğunun yüksek olması beklenir.

Kullanılabilecek Araçlar: Jenkins, Bamboo, Azure DevOps, GitLab

Deployment Sayısı: Bu sayının yüksek olduğu ekipler DevOps sürecindeki adımları kesintisiz işletiyor ve aralıksız mahsul çıkabiliyordur. Bu keza iş birimlerine kesintisiz geri bildirim ayrıca de olası hatalarda erken aksiyon alma seçeceği verir.

Deployment Süresi: Deployment sürelerinin uzun olması geri bildirimleri düşük olmasına niçin olur. bununla beraber takım öbür işler yapmak yerine süreci takip etmek zorunda kalır. Bu sürelerin minimum tutabilecek aksiyonların alınması beklenmektedir.

Production Metrikleri Development ortamının iyileştirilmesinden test olgunluğunun artırılmasına dek yapılan yatırımların en kayda değer çıktısı, müşteriye bahşedilen hizmetin iyileştirilmesidir. Bizim buradaki önerimiz: New Relic, Dynatrace, Appdynamics gibi APM (Application Performance Monitoring) araçlarını verimli kullanmaktır. Bu sayede production ortamınızı ölçümleyebilir, değişiklikleri trend halinde takip edebilir ve iyileştirebilirsiniz.

Avarage Response Time: Uygulamanın yanıt verme süresini açıklama eder. APM göre ölçülebilir. Bilhassa sunucu tarafında geçen sürenin çözümleme edilmesinde kullanılması beklenir. Cevap verme süresi, performansı iyi olan uygulamalar için 1.2 saniyenin aşağı olması beklenir. Cevap verme süresinin 4 saniye altında olması ortalamada kabul edilebilir olduğunu gösterir.