Daha önce yazılımda teknik borç üzerine yazmış ve bu kavramın yazılım projelerinde nasıl hayat bulduğundan ve nihayetinde de yazılım yöneticilerinin tavırlarından bahsetmiştik. Bu yazıda biraz daha özele girerek kod seviyesindeki kalitenin değişimini, düşmesini etkileyen etmenlerden bahsedelim.

Kod bozulur mu? Ya da İngilizce olarak sorarsak “does code decay?” Evet kod bozulur, yazılım mühendisliğinde en fazla ve sık bozulan şey muhtemelen koddur. Kodun bozulmasından kasıt, ne diğer mühendisliklerde olduğu gibi fiziksel aşınma ve bozulmadır ne de evlerdeki yemeklerimizin bozulması gibi kimyasal değişimlerdir. Kodun bozulmasından kasıt, kodun değişmeler yoluyla kalitesinin düşmesidir.

Beni yazılım projelerinde en fazla şaşırtan şeylerden birisi de, yazılımı yönetenlerin, yazılımın boyutunun bir problem olduğunu kesinlikle göz önüne almayan yaklaşımları olmuştur. Yani yazılımın büyüdükçe karmaşıklaştığı ve bunun da ciddi problemlere ve kalitede düşmeye sebep olduğunu genelde gözden kaçırıyoruz.  Benzer şekilde proje koduna önüne gelenin el atması ve değişiklikler yapması nihayetinde kod kalitesini düşürmektedir.

Bir yazılım geliştirme projesinde yazılımın ilk aylarında yani daha üç-beş bin satır iken, sahip olduğu özellikleri ve kaliteyi, aradan bir-iki sene geçtikten sonra yani yazılımın boyutu bir kaç yüzbin hatta bir kaç milyon satıra çıktığında da, tabi olarak taşımaya devam edeceğini düşünmek çok yaygın bir durum. Çünkü yazılımı yönetenlerin, yazılım büyürken, büyümenin getirdiği karmaşıklığı yönetmekle ilgili hiç bir şey yapmadıklarını çok sıklıkla gözlemliyorum. Aslen bu durumun öyle ya da böyle düşünmekle bir ilgisi yok, bu konuda bir farkındalığa sahip olmamakla bir ilgisi var. Hatta yazılım yöneticilerinin ciddi bir kısmının sahip olduğu bu aymazlığın, taa okullarındaki Fortran, C ya da Pascal gibi programlama dilleriyle yazdıkları programlara ve ödevlere dayandığını düşünüyorum. Çünkü “yaptığınız iki for bir if” ve buna benzeri, yazılım projesini basite alan, sözleri ben bir kaç defa duydum.

Aslen bu durum sadece yazılımı yönetenlere de has bir şey değil. Teknik pozisyonlarda olan pek çok kişinin de benzer şekilde yazılımın küçüğüyle büyük halinin arasında kalite açısından bir fark olmayacağını düşündüklerini biliyorum. Teknik pozisyonlarda ciddi zaman geçirdiği halde yazılım geliştirme faaliyetini hala program yazma seviyesinde ele alan kişilerin, yazılımın mimari özelliklerinin olduğunu ve büyüdükçe bu özelliklerinin bozulma riskine sahip olduğunu düşünememeleri normaldir.

Peki kod neden bozulur? Bu konuda tartışmayı, IEEE’nin Transaction os Software Engineering isimli yayınının Ocak 2001 sayısında “Does code decay? Assessing the evidence from change management data” başlıklı makale üzerinden yapmak istiyorum. Makale, Stephen G. Eick ve dört arkadaşı tarafından yazılmış olup içinde hem teorik tartışmalara hem de deneysel çalışmalara yer verilmiştir. Bu makaleyi, erişiminiz varsa hem IEEE hem de ACM üzerinden elde edebilirsiniz. İsterseniz makaleye buradan da ulaşabilirsiniz.

Makale, “kodun değiştirilmesinin olması gerektiğinden daha zor olması”nın (“harder to change than it should be”), kodun bozulmasına en temel işaret olduğu ifade ediliyor. Bu cümledeki zorluktan kasıt makaleye göre şu üç şeyde olabilir: Maliyette yani değişikliği yapanların maliyetinde, değişikliği yapmanın süresi ve değişiklik yapılan yazılım sisteminin kalitesini tutturmada.

Bunlar yanında makaleye göre şunlara dikkat etmek gerekli:

• Kodun bozulması, zamansaldır, zamanla ortaya çıkar.
• Kodun değiştirilmesindeki zorluk sadece kodun kalitesinin düşük olmasından kaynaklanmaz. Yazılımın, kalitesi aynı seviyede kalsa bile büyümesi, değiştirilmesini zorlaştıracağı açıktır.
• Kodun kalitesinin düşmesi, kodun yanlış olduğu ve müşteri ihtiyaçlarını yerine getirmediği anlamına gelmez. Yani kod hala müşteri ihtiyaçlarını giderme açısından son derece iyi bir noktada olmasına karşın, değişmesi son gittikçe zorlaşıyor olabilir.
• Kalitesi gittikçe düşen koda rağmen, bu koda sahip yazılımın değeri gittikçe yükseliyor olabilir.
• Kodun kalitesinin düşmesi sonuçta zaman içerisinde yapılan ilk değişiklikten sonuncusuna kadarki süreç içerisinde olmaktadır. Dolayısıyla bu süreçte kod kalitesini düşürmeyecek önlemler alınabileceği gibi, zaten düşmüş olan kalitenin tekrardan yükseltilmesi de mümkündür. Bu anlamda “değişiklik yoksa kodun kalitesi düşmez” şeklinde bir iddia ancak yüksek seviyede desteklenebilir.  Çünkü, yazılımın bir parçasında yapılan bir değişikliğin tamamen başka bir parçanın kalitesini düşürmesi mümkündür.
• Makale “değiştirilmesinin olması gerektiğinden daha zor olmasının (“harder to change than it should be”)”  tanımının zaten ölçülmesi zor olan bir şey olduğunu da ekliyor. Çünkü bazı kodlar hakikatten değiştirilmesi zor olan kodlardır ve nihayetinde kodu değiştirenler programcılardır.

Peki kod neden bozulur? Makaleye göre kodun bozulmasının sebepleri şunlardır:

• En başta kurgulanan mimarinin zaten değişimi kolaylaştıracak kurgu ve soyutlamalara sahip olmaması.
• İlk başta konan ve uygulanan prensiplerin zamanla bırakılması ve uygulanmamamsı.
• Belirsizlik taşıyan, muğlak ihtiyaçların koda çok fazla değişiklik gerektirmesi.
• Zaman baskısı.
• Uygun olmayan programlama araçları.
• Organizasyonal çevre. Ortamdaki moral ve enerji gibi şeylerdeki düşmeler, kodun bozulmasına sebep olabilir.
• Programcılardaki yetkinlik farklılıkları.
• Uygun olmayan değişiklik süreci.
• Kötü proje yönetimi.

Kodun bozulmasının işaretleri neler olabilir? Makale şunları listeliyor:

• Olması gerekenden daha karmaşık hale gelmiş olmak, kodun bozulmasının en temel işaretidir. Bunu anlamanın yolu ise, o kod parçasının tekrardan yazılması durumunda daha basit olacağı öngörülüyorsa o kod parçası bozulmuş demektir.
• Yapılan değişikliklerin sıklığı da kodun kalitesinin düştüğünü gösterebililir. Çünkü çok sık değişiklik, önceki değişikliklerin sıkıntılı olduğunu gösterebilir. Zira hızlıca yapılan değişiklikler zaten risklidir.
• Hata giderme (bug fix) çalışmalarının yeteri kalitede olmaması.
• Değişikliklerin geniş alanlara yayılması, bir bölgeye munhasır kalmaması, kodun mpdulerleştirilmesinde zaten bir problem olduğunu göstermektedir.
• Özellikle hata gidermede programcıların çok sıklıkla hızlı, günü kurtaran çözümler ya da İngilizcedeki karşılığıyla “workaround”lar bulmaları.
• Kodun arayüzlerinin sayısı zamanla artması da kodun bozulmasının işaretlerindendir.

Peki makaleye göre kodun kalitesinde düşmeye sebep olacak en temel risk faktörleri nelerdir?

• Büyüklük tabi ki en baş etken. Büyüklük derken en temelde NCSL (non-commenting source lines) yani yorumsuz kaynak koddaki satır sayısıdır.
• Kodun yaşı.
• Kodun yapısındaki tabi zorluklar. Örneğin bazı algoritmik yapılar kodun tabi haliyle zor kılabilir.
• Organizasyonel değişiklikler. Örneğin sisteme giren-çıkan kişilerin sayısı.
• Başka dillerden çevrilen kodlar.
• Aşırı çok ve detaylı ihtiyaçlar da kodları fonksiyonel bir yüke maruz kılacak ve kalitesinde düşmeye sebep olacaktır.
• Tecrübesiz programcılar.

Makale nihayetinde yaptığı çalışmadan sonra kod kalitesinin düşmesinin şu dört noktada kendini gösterdiğini ifade ediyor:

• Zaman geçtikçe değişiklikler yayılma eğiliminde olur. Yani yapılacak değişiklikler artık daha çok kod parçasını etkiler.
• Modüler yapı gittikçe bozulur.
• Her yeni değişiklik yeni hatalara (bug) sebep olur.
• Ve yeni değişikliklerin maliyetini tahmin etmek gittikçe zorlaşır.

Ülkemiz açısından değerlendirildiğinde, yukarıda bahsettiğim “zorluk” kavramının ortaya çıktığı maliyet, zaman ve kalite faktörlerinden kalitenin zaten bilinçli ya da bilinçsiz olarak söz konusu olmaktan çıkarıldığı ve geriye maliyet ve zamanın kaldığını söyleyebiliriz. Bu da nihayetinde fasit bir daireye sebep olmaktadır: Sadece maliyet ve süreye odaklı olan yazılım projelerimizde değişiklik yapmanın maliyeti ve süresi gittikçe düşecektir. Çünkü çoğu zaman ya baştan yazılım kalitesi anlayışına sahip olarak projelerimize girişmiyoruz ya da girişsek bile kalite, en ufak bir tansiyon yükselmesinde ilk başta terkettiğimiz şey oluyor. Düzgün bir ihtiyaç analizi, bunlar üzerine yapılması gereken analitik çalışmalar, tasarımlar, ar-ge deneme yanılmaları, etkin kod yazma, best-practicelere uyma, iç ve dış dokümantasyon ve birim testleri ile her türlü proje, risk vb. yönetim çalışmaları, maliyet ve zaman baskısı altında en hızlı bir  şekilde terk ettiğimiz disiplinlerdendir.

Bu konuyla ilgili olarak sanırım aklımızda tutmamız gereken, iyice öğrenmemiz gereken bir kaç konu var. Genel anlamda yazılım kalitesi ile mimari ve kod kalitesi üzerinde öğreneceğimiz şeylerin başındadır. Yazılımın büyümesi, kodların değişmesinin aslen ekleyerek değil de çıkararak yapılması gerektiği ve bunun da “refactoring” çalışmasının içinde ele alınması gerektiği de açıktır. Bu konudaki bu yazıma da bakabilirsiniz.

Yüksek kaliteli yazılımlar geliştirme umuduyla.

Toplam görüntülenme sayısı: 970