Kod Okumadan Yazılım Kalitesi Nasıl Ölçülür?

Yazılım kalitesi kodun dışında da iz bırakır. Sistemin ne sıklıkla güvenle değiştirilebildiği, yeni bir geliştiricinin faydalı hâle gelmesinin ne kadar sürdüğü, onu kuran kişi yokken ne olduğu, düzeltildikten sonra kaç hatanın geri döndüğü. Bunların hepsi tek bir dosya açılmadan okunabilir ve birlikte, çoğu kişinin beklediğinden fazlasını söyler.

Bu yolla mimari değerlendirmeyeceksiniz. Sistemin bozulmadan değiştirilip değiştirilemediğini öğreneceksiniz ki doğrudan iş sonucu olan tek kalite sorusu budur.

Önemli noktalar

• Kalite, değiştirilebilirliktir: Kimsenin güvenle değiştiremediği sistem, kodu nasıl görünürse görünsün bir yüktür.
• Altı kontrol, hiçbiri teknik değil: Dağıtım sıklığı, uyum süresi, tek kişiye bağımlılık, geri dönen hatalar, ortam benzerliği, bağımlılık yaşı.
• Sistemi kendisiyle kıyaslayın: Eğilim, tek bir rakamdan önemlidir.
• Cevaplar zaten kayıtlı: Bunların çoğu ekibinizin kendi araçlarında duruyor.

Kontrol 1: Değişiklikler üretime ne sıklıkla güvenle çıkıyor

Son üç aydaki dağıtım sayısını ve bunlardan kaçının bir gün içinde geri alınmak ya da acil düzeltme almak zorunda kaldığını sorun.

Sık ve olaysız dağıtım, sağlıklı bir sistemin en güçlü tek göstergesidir. Ekibin nefesini tutmadan değişiklik yapabildiği anlamına gelir; yani testler vardır, sürüm süreci anlaşılmıştır ve parçalar birbirinden ayrılabilir. Her seferinde krizle biten seyrek dağıtım ise, kod standartları hakkında ne söylenirse söylensin bunun tersini gösterir.

Kontrol 2: Yeni bir geliştirici ne kadar sürede faydalı oluyor

Ekibe en son katılan kişinin kendi başına üretime bir şey çıkarmasının ne kadar sürdüğünü sorun.

Birkaç günden iki haftaya kadar olan süre, sistemin anlaşılabilir ve düzgün kurulmuş olduğunu gösterir. İki ay ve üzeri ise ya dokümantasyonun olmadığını, ya kurulumun yazılı olmayan bir folklor hâline geldiğini, ya da sistemin bir parçasında çalışmak için tamamını anlamayı gerektirecek kadar iç içe geçtiğini gösterir. Üçü de pahalıdır ve üçü de kötüleşir.

Yakın zamanda kimse katılmadıysa ne kadar süreceğini tahmin etmelerini isteyin. Tahminin kendisi bilgilendiricidir.

Kontrol 3: Belirli bir kişi yokken ne oluyor

Doğrudan sorun: en kıdemli geliştiriciniz bir ay izne çıksa ne durur?

Her ekipte bilgi yoğunlaşması vardır ve bir miktarı kaçınılmazdır. Ama dürüst cevap sürümlerin duracağı ya da bir alanın dokunulmaz hâle geleceği yönündeyse, tek bir kişinin zihninde duran bir iş riskiniz var demektir. Bu bir kalite bulgusudur ve en kötü anda size zarar verme olasılığı en yüksek olanıdır.

Kontrol 4: Kaç hata geri dönüyor

Son çeyrekte kapatılıp yeniden açılan ya da farklı biçimlerde iki kez düzeltilen kayıt sayısını isteyin.

Tutmayan bir düzeltme genelde sebebin değil yalnızca belirtinin bulunduğunu gösterir. Çok sayıda geri dönen hatası olan sistem, bir değişikliğin etkisini kimsenin öngöremediği sistemdir ki bu, kötü kalitenin pratikteki tanımıdır. Bu sayı genelde ekibin kullandığı hata takip aracında hazır durur ve neredeyse hiç kimse bakmaz.

Kontrol 5: Test ile canlı aynı davranıyor mu

Üretime benzeyen bir ortam olup olmadığını ve testte çalışıp canlıda bozulan şeylerin ne sıklıkla yaşandığını sorun.

Gerçekçi bir test ortamı olmayan ekipler, öyle tanımlasalar da tanımlamasalar da testlerini üretimde yapıyordur. Bu, iyi görünüp ardından acil düzeltme gerektiren sürümler kalıbı olarak ortaya çıkar ve birinci kontroldeki dağıtım krizlerinin en sık sebeplerindendir.

Kontrol 6: Temeller ne kadar eski

Ana çatının, dil sürümünün ve kütüphanelerin en son ne zaman güncellendiğini, herhangi birinin destek ömrünü doldurup doldurmadığını sorun.

Güncel olmayan temeller otomatik olarak sorun değildir; pek çok istikrarlı sistem bilinçli olarak eski sürümlerde çalışır. Sorun, cevabı kimsenin bilmemesi ya da güncellememe sebebinin kimsenin cesaret edememesi olduğunda başlar. Desteği biten bileşenler güvenlik düzeltmesi de almaz; bu da teknik bir kararı iş riskine çevirir.

Sonuçları birlikte okumak

Tek bir kontrol bir sistemi mahkûm etmez. Endişe edilmesi gereken kalıp şudur: seyrek dağıtım yapan, kimseyi aylarca uyum sürecinde tutan, tek kişiye bağımlı ve hataları sürekli geri dönen bir sistem. Bu birleşim, güvenle değiştirilemeyen bir kod tabanını tarif eder ve ne öderseniz ödeyin bundan sonraki her işi yavaşlatır.

Tersi kalıp, yani sık dağıtım ve hızlı uyum, kodun pürüzleri olsa bile genelde ayakta kalır. Kimsenin yayına alamadığı derli toplu kod, çıkan dağınık koddan daha az değerlidir.

Cevaplar kötüyse ve ne kadar kötü olduğunu bilmeniz gerekiyorsa denetim tam olarak bunun içindir. Kapsamını teknik denetim yazısında anlattık.