Teknik Borç (Technical Debt) Nedir? Nasıl Ödenir?

Günümüzde işletmeler, varlıklarını sürdürebilmek için hızla gelişen ve değişen teknolojik gelişmelere ayak uydurmak ve sürekli değişen müşteri talep ve beklentilerine hızlıca uyum sağlamak zorundadır. Bu uyum sürecinde yeni uygulamaların müşterilere hızlıca sunulması hedeflenir. Müşteri isteklerini karşıladığı sürece ürünün başarılı olduğu düşünülse de yazılım ürünü kullanılmaya başlandıktan sonra üzerine yeni geliştirmeler eklenmek istendiğinde sürecin eskisi gibi hızlı ilerlemediği ve yeni özelliklerin kolayca ürüne entegre edilemediği gerçeği ile karşı karşıya kalınmaktadır.

Sürece yazılım ekipleri tarafından bakarsak, bir yazılım ürünü geliştirirken hepimiz ortaya çıkaracağımız ürün kodunun hatasız, esnek ve kullanışlı olmasını isteriz fakat acil olarak gelen işler ve son dakika değişen planlar sebebiyle en iyi çözümü uygulamak yerine kısa vadede süreci tamamlamak zorunda kalabiliriz. Kod kalitesine dikkat etmeden, standartlara uymadan, sonradan düzeltirim diyerek karmaşık kodlarla ürünümüzü zamanında tamamladığımızda müşteri mutlu olsa da, oluşabilecek sorunların yakın zamanda bizleri mutsuz edeceği gerçeğini unutmamalıyız.

Geliştirdiğimiz yazılım ürünlerinde yaptığımız kaliteyi bozacak bu ihmaller, bize ileride ödenmesi zor borçlar olarak yazılmaktadır. Teknik borç olarak adlandırılan bu durum, yazılım geliştirme ekiplerinin kısa vadede hızlı proje teslimi sağlamak için uygulaması kolay çözümlere başvurması sonucu oluşmaktadır. Bu kolay çözümler uygulanırken oluşabilecek riskler bilerek veya bilmeyerek yazılımın istenilen kalitede geliştirilememesine yol açar. Sonuç olarak bu tarz kalite eksikliklerinin birikmesi, sonraki yazılım geliştirme süreçlerini yavaşlatır ve en önemlisi de yazılım geliştirme ekibinin hareket kabiliyetini düşürür.

Teknik Borç Önlenebilir mi?

Teknik borçlar dikkate alınmadığında zamanla kalitesi bozulan, problemleri çoğalan ürünler ortaya çıkmaktadır. Teknik borçlanma arttıkça yeni ürün geliştirme süreçlerinin zorlaşmasının yanı sıra mevcut ürünlere yeni özellik eklenmesi ve bakım maliyetleri de artmaktadır. Bu durum geliştirme sürecinde çalışan analist ve yazılımcıları yıpratmakta ve her an hata çıkarabilecek projelerin ortaya çıkmasına sebep olabilmektedir.

Peki teknik borç oluşumunu önlemek için neler yapılabilir?

Ürün gereksinimlerinin etkin bir şekilde önceliklendirilmesi,
Portföy yönetiminin ve kaynak tahsisinin iyi yapılması,
Ekip kapasitesinin bir bölümünün teknik borcu azaltmak için ayrılması,
Ekip üyelerinin ürün teslimatını geciktirecek şekilde yetenek eksikliklerinin olmaması,
Ekip üyeleri arasındaki iletişimin artırılması,
Ekiplerin sadece kısa vadede ürün geliştirmeye değil aynı zamanda kaliteye de odaklanması,
Yazılım içerisinde değiştirilmesi zor yerleşik iş kuralları olmaması,
Yazılım geliştirme sürecinde kod standartlarının belirlenmiş olması,
Geliştirme ve bakım sürecinin iyi yönetilmesi,
Devops kültürünün benimsenmesi,
Düzenli Code Review yapılması: Geliştiricilerin kod yazma kabiliyetini ve projelere olan hakimiyetlerini artırması, bugların minimize edilip performans problemlerine yeni çözüm önerilerinin sunulması ve kodların daha güzel nasıl yazılabileceği konusunda fikir alışverişinde bulunulması amacıyla kodların ekipçe incelenmesi.
Kod kalitesinin Sürekli Denetimi: SonarQube gibi uygulamalar kullanılarak mevcut projelerde ve yeni kod ekleme sürecinde oluşabilecek güvenlik açıklarının, tekrarlı veya gereksiz yazılmış kodların tespit edilip raporlanması ve kodların denetim sonuçlarına göre düzenlenmesinin sağlanması.

Teknik Borçlar Nasıl Ödenir?

Yazılım geliştirme süreçlerimizde teknik borçlar oluştuysa çok birikmeden borcu azaltmak için yeniden düzenleme (refactoring) çalışması yapabiliriz. Refactoring ile kodlarımızı ana işlevi korunacak şekilde tekrardan tasarlayıp yapılandırabiliriz. Böylece projelerimize yeni kod eklemek daha kolay olduğu gibi kodlarımız daha temiz, okunaklı olur ve diğer yazılımcılar tarafından daha kolay anlaşılır hale gelir. Şekil-1’ de refactoring ile teknik borçları azaltmanın zaman içerisindeki zorluğu ve maliyete etkisi gösterilmektedir. Zamanında refactoring yapılmazsa teknik borçlar birikecek, kodların yeniden tasarlanması zorlaşacak, yeni bir kod ekleme süreci yavaşlayacak ve geliştirme maliyetleri artacaktır.

Şekil-1: Teknik Borç Refactoring – Zaman İlişkisi

Peki refactoring kapsamında ne tür çalışmalar yapılabilir?

Ekipler arasında kod sahipliliğinin sağlanması,
Kullanılmayan kod parçalarının (alan, parametre, değişken, metot, sınıf, kod parçacığı) kaldırılması,
Kod karmaşıklığının azaltılması, işlevselliğinin artırılması,
Kodlarının okunurluğunun arttırılması,
Tasarım kalıplarının (Design patterns) doğru uygulanması,
Mümkünse teknik borçların risk yönetim süreçleri ile yönetilmesi,

Yukarıda bahsedilen çalışmaları gerçekleştirmek için kullanılan en etkili yöntemleri aşağıdaki şekilde sıralayabiliriz.

Modüllerin birbirleri arasındaki bağlılığın (coupling) azaltılması ve bu modüllerin içindeki elemanların birbirine bağlılık (cohesion) derecesinin artırılması.
Kod kalitesinin Sürekli Denetimi (Continuous Code Quality)
Düzenli Kod İnceleme (Code Review)

1. Bağlılık (Coupling) ve Uyum (Cohesion) Kavramları

Nesne yönelimli programlamada, nesneler arasındaki bağların sıkı olmaması (loosely coupled), sınıflar içerisindeki procedure ve veri alanlarının ise yüksek uyumlu (high cohesion) olması istenir. Böylece kodun okunabilirliği ve yeniden kullanılabilirliği artırılırken karmaşıklık yönetilebilir durumda tutulur. Modül karmaşıklığı azaltılmış ve modülün yeniden kullanılabilirliği artırılmış olur. Bir modüldeki değişiklikler diğer modüllerde daha az değişiklik gerektirdiğinden artan sistem bakımı sağlanır.

Şekil-2’ de modüller arasındaki yüksek ve düşük uyum farkı gösterilmiştir. Yüksek uyum, yazılımın sağlamlık, güvenilirlik, yeniden kullanılabilirlik ve anlaşılırlık özelliğini artırır. Buna karşılık düşük uyum, sürdürülmesi, test edilmesi, yeniden kullanılması ve hatta anlaşılması zor olan kodların artmasına neden olur.

Şekil-2: Coupling-Cohesion Yapısı

2. Kod kalitesinin Sürekli Denetimi (Continuous Code Quality)

Kodlardaki hataların ve güvenlik açıklarının tespit edilip yeniden düzenlenmesi amacıyla SonarQube gibi uygulamalar kullanılabilir. SonarQube statik kod analiz aracıdır ve clean code gibi unsurları içinde barındıran open source güvenlik aracıdır. Uygulamanın en güzel yanı hataları listelerken aynı zamanda çözüm yollarını da göstermesidir.

Şekil-3’ de SonarQube uygulaması kullanılarak taranmış bir projenin açıkları ve kod hatalarının sayıları raporlanmaktadır. Hatalar tipine göre bug, güvenlik açığı ve code smell olarak gruplanmıştır. Ayrıca hataların önemine göre sayıları engelleyici, kritik, büyük, küçük ve bilgi amaçlı olarak listelenmiştir.

Şekil-3: SonarQube Tarama Sonucu

SonarQube uygulamasını kullanarak tekrarlı kodların atılması, gereğinden fazla kullanılan satır/sınıf/metod varsa silinerek kodun temizlenmesi sağlanabilir. Şekil-4’ de uygulamanın proje içerisinde tespit ettiği hatayı görebilirsiniz. Kod içerisinde kullanılan while döngüsünün tekrar düzenlenmesi şeklinde hata tespiti yapılmış.

Şekil-4: SonarQube Hata Gösterimi

Şekil-5’te ise uygulamanın bulduğu hataya yönelik önerdiği çözümü görebilirsiniz. Tek kayıt dönen bir işlem için while loop kullanmanın gereksiz olduğu belirtilmiş.

Şekil-5: SonarQube Çözüm Önerisi

3. Düzenli Kod İnceleme (Code Review) yapılması

Refactoring çalışmalarında etkili yöntemlerden bir diğeri düzenli Code Review çalışmaları yapmaktır. Kod incelemesinin amacı, bir yazılım ürününün kalitesini artırmak ve tüm proje katılımcılarından (mimarlar, geliştiriciler ve test uzmanları vb.) oluşan ekibin becerilerini geliştirmektir. Ekip kodları incelemek için bir araya gelir ve ekipte yer alan deneyimli kişiler tecrübelerini daha az deneyimli kişilere aktarma imkânı bulurlar. Kodlarda daha önce deneyimledikleri hataların tekrar yaşanmaması için düzeltilmesi gerekli noktaları ekipteki diğer üyelere aktarırlar. Fikir alışverişi yapmak, projelere farklı bakış açıları kazandırabilir.

Kod inceleme, Şekil-5’te ki gibi yazılım geliştirme süreci içerisine kod inceleme süreci yerleştirilmiştir. Süreç içerisinde yeni geliştirilen kodlar düzenli incelendiğinde, geliştirmenin ilk aşamasında fark edilmeyen hataları tespit edip düzeltmek, proje mimarisini iyileştirmek ve sistem bakım uygulamalarını geliştirmek daha kolay olacaktır.

Şekil-6: Yazılım Geliştirme Sürecinde Kod İnceleme

Daha efektif Code Review çalışmaları için aşağıdaki yöntemler uygulanabilir.

Gözden geçirenlerin dikkatini yoğunlaştırmasını teşvik etmek için kod inceleme süresini 60 dakikadan daha kısa bir süre veya tek seferde yaklaşık 400 kod satırı ile sınırlandırın. Tek seferde 60 dakikadan fazla inceleme yapmayın. Makul miktarda ve sınırlı bir süre için daha yavaş bir hızda yapılan kod incelemeleri, en etkili kod incelemesiyle sonuçlanır.
Mümkünse bir uygulama kullanın. SonarQube gibi uygulamaların kullanılması, kod gözden geçirmenin sistematik hale gelmesini, hem de kolay yapılması için yardımcı olacaktır.
Kodu yazan kişi değil, kod gözden geçirilmeli. Kod gözden geçirecek kişi egosunu bir kenara bırakmalı. Ayrıca kodu yazanı değil, kodu gözden geçirmeli.
Hedefleri belirleyin ve ölçümleri yakalayın. Örneğin kod satırı başına bulunan ortalama hata sayısı gibi.
Kodu yazan kişi inceleme gerçekleşmeden önce koda açıklama ekleyebilir; çünkü ek açıklamalar, gözden geçiren kişiye değişiklikler konusunda rehberlik eder.
Kontrol listelerini kullanın. Kritik Review noktaları için (döngüler, değişkenler, karar adımları vb.) bütün ekip üyelerinin kullanacağı bir kontrol listesi faydalı olacaktır.
Bulunan kusurların düzeltilmesi için bir süreç oluşturun. Örneğin ekip kapasitesinin bir bölümünün teknik borcu azaltmak için ayrılması gibi.
Olumlu bir kod inceleme kültürünü teşvik edin. İş birliği içinde kod kalitesini iyileştirmenin fırsat olduğu fikrini ekibe yerleştirin.
Yeterli eğitim sağlayın: Ekip üyelerinin kod inceleme becerilerini geliştirmeye odaklanın.

Sonuç olarak teknik borcun doğrusal olarak büyümediğini, katlanarak arttığını düşünürsek yazılım projelerimizde yeni ürünler geliştirirken teknik borçlanma oluşmaması yönünde çalışmalarımızı yürütmeye özen göstermeliyiz. Mevcutta tespit ettiğimiz teknik borçları ise çok geç olmadan ödemeye başlamanın çözüm yollarını aramalıyız.

Kaynakça: