Kaynak Kodu QA: Artık Sadece Geliştiriciler İçin Değil

Yirmi yıl önce, otomotiv endüstrisinde çalışırken, bir fabrikanın müdürü sık sık “Bir araba yapmak için bir günümüz var, ancak müşterimizin onu incelemek için bir ömrü var” derdi. Kalite son derece önemliydi. Gerçekten de, otomotiv ve inşaat endüstrileri gibi daha olgun sektörlerde, kalite güvencesi, ürün geliştirme sürecine sistematik olarak entegre edilen önemli bir husustur. Bu kesinlikle sigorta şirketlerinin baskısından kaynaklansa da, aynı zamanda - fabrika müdürünün belirttiği gibi - ortaya çıkan ürünün ömrü tarafından da belirlenir.

Bununla birlikte, yazılım söz konusu olduğunda, daha kısa yaşam döngüleri ve sürekli yükseltmeler, yeni özellikler, gelişmiş işlevsellik ve pazara giriş hızı lehine kaynak kodu bütünlüğünün genellikle göz ardı edildiği anlamına gelir. Ürün yöneticileri, bir ürünün kaderini belirlemede daha kritik faktörlerden biri olmasına rağmen, genellikle kaynak kodu kalite güvencesini ön plana çıkarır veya halletmesi için geliştiricilere bırakır. Ürün geliştirme için sağlam bir temel oluşturmak ve riskleri ortadan kaldırmakla ilgilenen ürün yöneticileri için, kaynak kodu kalitesinin sistematik bir değerlendirmesini tanımlamak ve uygulamak çok önemlidir.

“Kalite”yi Tanımlamak

Bir kaynak kodu QA sürecini uygun şekilde değerlendirmenin ve yürürlüğe koymanın yollarını keşfetmeden önce, yazılım geliştirme bağlamında “kalite”nin ne anlama geldiğini belirlemek önemlidir. Bu karmaşık ve çok yönlü bir konudur, ancak basitlik adına, kalitenin, tüketici memnuniyetinden ödün vermeden veya geliştirme şirketinin iş modelini tehlikeye atmadan bir ürünün değer teklifini destekleyen kaynak koduna atıfta bulunduğunu söyleyebiliriz.

Başka bir deyişle, kaliteli kaynak kodu, ürünün işlevsel özelliklerini doğru bir şekilde uygular, işlevsel olmayan gereksinimleri karşılar, tüketicilerin memnuniyetini sağlar, güvenlik ve yasal riskleri en aza indirir ve uygun maliyetli bir şekilde sürdürülüp genişletilebilir.

Yazılımın ne kadar yaygın ve hızlı bir şekilde dağıtıldığı göz önüne alındığında, yazılım kusurlarının etkisi önemli olabilir. Hatalar ve kod karmaşıklığı gibi sorunlar, ürünün benimsenmesini engelleyerek ve yazılım varlık yönetimi (SAM) maliyetlerini artırarak bir şirketin kârlılığına zarar verebilirken, güvenlik ihlalleri ve lisans uyumluluğu ihlalleri şirketin itibarını etkileyebilir ve yasal endişeleri artırabilir. Yazılım kusurlarının yıkıcı sonuçları olmasa bile, yadsınamaz bir maliyeti vardır. Bir 2018 raporunda, yazılım şirketi Tricentis, 314 şirketten gelen 606 yazılım hatasının bir önceki yıl 1,7 trilyon dolarlık gelir kaybına neden olduğunu tespit etti. Yeni yayınlanan bir 2020 raporunda, CISQ, ABD'de düşük kaliteli yazılım maliyetini 2,08 trilyon ABD Doları olarak belirledi ve teknik borçtan kaynaklanan gelecekteki maliyetlerde 1,31 trilyon ABD Doları olarak tahmin edildi. Bu sayılar daha önceki müdahalelerle azaltılabilir; ürün tasarımı sırasında bir sorunu çözmenin ortalama maliyeti, aynı sorunu test sırasında çözmekten önemli ölçüde daha düşüktür ve bu da sorunu dağıtımdan sonra çözmekten katlanarak daha düşüktür.

Sıcak Patatesi Kullanmak

Risklere rağmen, yazılım geliştirmede kalite güvencesi parça parça ele alınır ve diğer endüstrilerde benimsenen proaktif yaklaşımdan ziyade reaktif bir yaklaşımla karakterize edilir. Kaynak kodu kalitesinin mülkiyeti, farklı işlevlerin ortak sorumluluğu olarak görülmesi gerektiğinde tartışmalıdır. Ürün yöneticileri kaliteyi genel giderden ziyade etkili bir özellik olarak görmeli, yöneticiler kalite durumuna dikkat etmeli ve buna yatırım yapmalı ve mühendislik işlevleri kod temizlemeyi bir "sıcak patates" olarak görmeye direnmelidir.

Bu yetkilendirme zorluklarını birleştirmek, mevcut metodolojilerin ve araçların kod kalitesi sorununu bir bütün olarak ele alamamasıdır. Sürekli entegrasyon/sürekli teslim metodolojilerinin kullanılması düşük kaliteli kodun etkisini azaltır, ancak CI/CD kapsamlı ve bütünsel bir kalite analizine dayanmadıkça çoğu tehlikeyi etkili bir şekilde tahmin edemez ve ele alamaz. QA testi, uygulama güvenliği ve lisans uyumluluğundan sorumlu ekipler, sorunun yalnızca bir bölümünü çözmek için tasarlanmış araçları kullanarak silolarda çalışır ve işlevsel olmayan veya işlevsel gereksinimlerin yalnızca bir kısmını değerlendirir.

Ürün Yöneticisinin Rolünü Düşünmek

Kaynak kodu kalitesi, ürün tasarımı sırasında ve yazılım geliştirme yaşam döngüsü boyunca bir ürün yöneticisinin karşılaştığı sayısız ikilemde rol oynar. ΤTeknik borç yükü ağırdır. Düşük kaliteli bir kod tabanında özellikler eklemek ve değiştirmek daha zor ve daha pahalıdır ve mevcut kod karmaşıklığını desteklemek, aksi takdirde yeni ürün geliştirmeye harcanabilecek önemli miktarda zaman ve kaynak yatırımı gerektirir. Ürün yöneticileri, riski pazara giriş hızıyla sürekli olarak dengelediğinden, aşağıdaki gibi soruları dikkate almaları gerekir:

• Bir OSS (açık kaynak yazılım) kitaplığı kullanmalı mıyım yoksa sıfırdan işlevsellik oluşturmalı mıyım? Seçilen kitaplıklarla ilişkili lisanslar ve olası yükümlülükler nelerdir?
• Hangi teknoloji yığını en güvenlidir? Hangisi hızlı ve düşük maliyetli bir geliştirme döngüsü sağlar?
• Uygulama yapılandırılabilirliğine mi (yüksek maliyet/zaman gecikmesi) öncelik vermeliyim yoksa özelleştirilmiş sürümleri mi uygulamalıyım (yüksek bakım maliyeti/ölçeklenebilirlik eksikliği)?
• Yüksek kod kalitesini korurken, riskleri en aza indirirken ve mühendislik maliyetlerini düşük tutarken yeni edinilen dijital ürünleri entegre etmek ne kadar mümkün olacak?

Bu soruların yanıtları, iş sonuçlarını ve ürün yöneticisinin kendi itibarını ciddi şekilde etkileyebilir, ancak kararlar genellikle titiz araştırmalar ve sağlam ölçümler yerine sezgilere veya geçmiş deneyimlere dayalı olarak alınır. Kapsamlı bir yazılım kalite değerlendirme süreci, yalnızca karar verme için gereken verileri sağlamakla kalmaz, aynı zamanda paydaşları hizalar, güven oluşturur ve önceliklerin açık ve üzerinde anlaşmaya varıldığı bir şeffaflık kültürüne katkıda bulunur.

7 Adımlı Bir Sürecin Uygulanması

Eksiksiz bir kaynak kodu kalite değerlendirme süreci, daha büyük bir sorunun birkaç izole semptomu yerine kalite belirlemelerinin tamamını dikkate alan bir tanılama ile sonuçlanır. Aşağıda sunulan yedi adımlı yöntem, CISQ'nun süreç iyileştirme önerileriyle uyumludur ve aşağıdaki hedefleri kolaylaştırmayı amaçlar:

• Sorunu kök nedenine yakın bir yerde bulun, ölçün ve düzeltin.
• Genel kalite ölçümlerine dayalı yazılım kalite iyileştirmesine akıllıca yatırım yapın.
• Eksiksiz ölçüm setini analiz ederek ve en iyi, en uygun maliyetli iyileştirmeleri belirleyerek soruna saldırın.
• Sahip olma, bakım ve lisans/güvenlik düzenlemesi uyumu dahil olmak üzere bir yazılım ürününün tam maliyetini göz önünde bulundurun.
• Hoş olmayan sürprizleri önlemek için SDLC boyunca kod kalitesini izleyin.

1. Üründen koda eşleme: Ürün özelliklerini kod tabanlarına kadar takip etmek açık bir ilk adım gibi görünebilir, ancak geliştirme karmaşıklığının artma hızı göz önüne alındığında, bu her zaman basit değildir. Bazı durumlarda, bir ürünün kodu birkaç havuz arasında bölünürken, diğerlerinde birden fazla ürün aynı havuzu paylaşır. Bir ürün kodunun belirli bölümlerini barındıran çeşitli konumların belirlenmesi, daha fazla değerlendirme yapılmadan önce gereklidir.

2. Teknik yığın analizi: Bu adım, kullanılan çeşitli programlama dillerini ve geliştirme araçlarını, dosya başına yorum yüzdesini, otomatik oluşturulan kodun yüzdesini, ortalama geliştirme maliyetini ve daha fazlasını dikkate alır.

Önerilen araçlar: saat

Alternatifler: Tokei, scc, sloccount

3. Sürüm analizi: Bir kod tabanının tüm sürümlerinin tanımlanmasını ve benzerliklerin hesaplanmasını içeren denetimin bu bölümünün sonuçlarına dayanarak, sürümler birleştirilebilir ve tekrarlar ortadan kaldırılabilir. Bu adım, kodun en sık revize edilen ve daha yüksek bakım maliyetleri üretme eğiliminde olan zor kısımlarını tanımlayan bir hata noktaları (sıcak noktalar) analizi ile birleştirilebilir.

Önerilen araçlar: cloc, scc, sloccount

4. Otomatik kod incelemesi: Bu inceleme, kodu kusurlar, programlama uygulama ihlalleri ve sabit kodlanmış belirteçler, uzun yöntemler ve yinelemeler gibi riskli öğeler açısından inceler. Bu süreç için seçilen araç(lar), yukarıdaki teknoloji yığını ve sürüm analizlerinin sonuçlarına bağlı olacaktır.

Önerilen araçlar: SonarQube, Codacy

Alternatifler: RIPS, Veracode, Micro Focus, Parasoft ve diğerleri. Başka bir seçenek de evrensel bir kod arama çözümü olan Sourcegraph'tır.

5. Statik güvenlik analizi: Statik uygulama güvenlik testi (SAST) olarak da bilinen bu adım, olası uygulama güvenlik açıklarını araştırır ve tanımlar. Kullanılabilir araçların çoğu, kodu OWASP ve SANS gibi kuruluşlar tarafından tanımlanan ve sıklıkla meydana gelen güvenlik sorunlarına karşı tarar.

Önerilen araçlar: WhiteSource, Snyk, Coverity

Alternatifler: SonarQube, Reshift, Kiuwan, Veracode

6. Yazılım bileşenleri analizi (SCA)/Lisans uyum analizi: Bu inceleme, kodla doğrudan veya dolaylı olarak bağlantılı açık kaynak kitaplıklarının, bu kitaplıkların her birini koruyan lisansların ve bu lisansların her biriyle ilişkili izinlerin belirlenmesini içerir.

Önerilen araçlar: Snyk, WhiteSource, Black Duck

Alternatifler: FOSSA, Sonatype ve diğerleri

7. İş riski analizi: Bu son önlem, kaynak kodu kalite durumunun iş üzerindeki tam etkisini anlamak için önceki adımlardan toplanan bilgilerin konsolide edilmesini içerir. Analiz, ürün yöneticileri, proje yöneticileri, mühendislik ekipleri ve üst düzey yöneticiler dahil olmak üzere paydaşlara riskleri tartmak ve bilinçli ürün kararları vermek için ihtiyaç duydukları ayrıntıları sağlayan kapsamlı bir raporla sonuçlanmalıdır.

Bu değerlendirme sürecindeki önceki adımlar, çok çeşitli açık kaynak ve ticari ürünler aracılığıyla otomatikleştirilip kolaylaştırılabilse de, yedi adımlı sürecin tamamını veya sonuçlarının birleştirilmesini destekleyen mevcut hiçbir araç yoktur. Bu verilerin derlenmesi sıkıcı ve zaman alıcı bir iş olduğundan, ya gelişigüzel bir şekilde gerçekleştirilir ya da tamamen atlanır, bu da geliştirme sürecini potansiyel olarak tehlikeye atabilir. Bu, kapsamlı bir yazılım inceleme sürecinin sıklıkla bozulduğu ve bu son adımı değerlendirme sürecindeki tartışmasız en kritik adım haline getirdiği noktadır.

Doğru Araçları Seçmek

Yazılım kalitesi ürünü ve dolayısıyla iş sonuçlarını etkilese de, araç seçimi genellikle geliştirme departmanlarına devredilir ve sonuçları geliştirici olmayanların yorumlaması zor olabilir. Ürün yöneticileri, şeffaf ve erişilebilir bir KG süreci sağlayan araçların seçiminde aktif olarak yer almalıdır. Yukarıda değerlendirmedeki çeşitli adımlar için belirli araçlar önerilmiş olsa da, herhangi bir araç seçim sürecinde dikkate alınması gereken bir dizi genel husus vardır:

• Desteklenen teknoloji yığını: Mevcut tekliflerin çoğunun yalnızca küçük bir geliştirme araçları setini desteklediğini ve kısmi veya yanıltıcı raporlamaya neden olabileceğini unutmayın.
• Kurulum kolaylığı: Kurulum süreçleri karmaşık komut dosyası oluşturmaya dayalı araçlar, önemli bir mühendislik yatırımı gerektirebilir.
• Raporlama: Önemli sorunları belirleyen ve düzeltmeler için öneriler sunan ayrıntılı, iyi yapılandırılmış raporları dışa aktaran araçlar tercih edilmelidir.
• Entegrasyon: Kullanılan diğer geliştirme ve yönetim araçlarıyla kolay entegrasyon için araçlar taranmalıdır.
• Fiyatlandırma: Araçlar nadiren kapsamlı bir fiyat listesiyle gelir, bu nedenle ilgili yatırımı dikkatlice düşünmek önemlidir. Çeşitli fiyatlandırma modelleri genellikle ekip çalışan sayısı, kod boyutu ve ilgili geliştirme araçları gibi şeyleri hesaba katar.
• Dağıtım: Şirket içi ve bulut dağıtımını tartarken güvenlik gibi faktörleri göz önünde bulundurun. Örneğin, değerlendirilen ürün gizli veya hassas verileri işliyorsa, şirket içi araçlar ve kör denetim yaklaşımını (FOSSID) kullanan araçlar tercih edilebilir.

Devam Ettirmek

Riskler belirlendikten ve metodik olarak analiz edildikten sonra, ürün yöneticileri önceliklendirme ve triyaj kusurları hakkında daha doğru kararlar verebilirler. Ekipler yeniden yapılandırılabilir ve en acil veya yaygın sorunları ele almak için kaynaklar tahsis edilebilir. Yüksek riskli lisans ihlalleri gibi "göstericiler", düşük önemdeki kusurlara göre öncelikli olacak ve kod tabanı boyutunun ve karmaşıklığının azaltılmasına katkıda bulunan faaliyetlere daha fazla önem verilecektir.

Ancak bu tek seferlik bir süreç değildir. Yazılım kalitesinin ölçülmesi ve izlenmesi, SDLC boyunca sürekli olarak gerçekleşmelidir. Tam yedi aşamalı değerlendirme, her bir analizin hemen ardından başlayan kalite iyileştirme çabaları ile periyodik olarak yapılmalıdır. Yeni bir risk noktası ne kadar hızlı belirlenirse, çözüm o kadar ucuza gelir ve etkileri o kadar sınırlı olur. Kaynak kodu kalite değerlendirmesini ürün geliştirme sürecinin merkezine yerleştirmek ekipleri odaklar, paydaşları hizalar, riskleri azaltır ve bir ürüne başarı için en iyi şansı verir - ve bu her ürün yöneticisinin işidir.