YAZILIM MİMARİSİ
Teknik Borç (Technical Debt) Nedir?
Bu yazıda Teknik Borcun ne olduğu, neden ortaya çıktığı, borcun nasıl kapatılabileceği üzerine konuşacağız.
Teknik Borç, Yazılım Geliştirme sırasında bilerek veya bilmeyerek yazılımın istenilen kalitede geliştirilmemesi ve kalite eksikliklerinin gerçek hayattaki finansal borçlar gibi birikerek ekibin hareket kabiliyetini, hızını düşürmesidir.
1. Yazılımın istenilen kalitede geliştirilmemesi NE DEMEK ?
Yazılımın kalitesini incelerken Internal(İç) ve External(Dış) kaliteler olarak 2ye ayırabiliriz.
Internal Quality (İç Kalite)
İç kalite dediğimiz kısım kodun kaliteli yazılıp yazılmadığı kısmıdır.
- Kodunuz kaliteli bir şekilde yazılmış ve yapılandırılmış mı ?
- Kod anlaşılabilir ve bakımı kolay yapılabilir mi ?
- Kod ne seviyede test yazılmış, ve % kaç oranında kod covarage bulunuyor.
External Quality (Dış Kalite)
- Yazılım Müşterinin ihtiyaçlarını karşılıyor mu ?
- Yazılım çöküyor mu ? Yazılım etkileşimi ve tepkime süreleri nasıl
- İyi bir UI tasarımı ve kullanabilirlik sunabiliyor mu ?
Not: Bu kısım birçok konuyu ilgilendiriyor. Buraya tüm yazıların linklerini tek tek koymaktansa Yazılım Süreçleri, Mimari Örüntüler, Tasarım Örüntüleri ve AntiPatterns yazıların hepsine dokunduğu noktalar bulunuyor.
2. Yazılımın kaliteli geliştirilmemesinin NEDENLERİ ?
Bunun bir çok nedeni olabilir,
- zamanın azlığı,
- takımın deneyim eksikliği,
- yönetimsel hatalar,
- yanlış 3rd party ürün ve kütüphane seçimleri,
- müşteriyi iyi analiz edememe,
- yanlış bir geliştirme modelini kullanma,
- yanlış önceliklerde kod geliştirme,
- design system kullanmamak,
- vb.. bir çok konu buna neden olmuş olabilir. Bu konuda Kod kalitesi için Kod Kalitesini Neler Kötü Etkiler ve Yazılım Mimarisi açısından Yazılım Mimarının 5 Yanlışı yazılarımı okumanızı öneririm.
3. Yazılım Entropisi?
Bilim insanları düzensizliği entropi adı verilen nicelik ile ölçerler. Sistemlerdeki düzensizlik arttıkça, entropi de artar. Bu durum da faydalı (iş yapabilir) enerji miktarı azalır, faydasız enerji artar [Vikipedia]
As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it” by Meir Manny Lehman
Gelişmekte olan yazılım içinde benzeri bir durum söz konusudur. Geliştikçe , kompleks seviyesi artacak, bu artış bozulan yapıya yansıyacak ve bir çok iş gücü önceki bu kodları bakım yapmaya veya bu tarz sorunları azaltmaya gidecektir.
Burada kastedilen kod geliştirme ilerledikçe kodun geliştirmenin daha zorlaştığı, yeni yeteneklerin sisteme rahat bir şekilde eklenemediği ve ekibin , yazılım geliştirmenin giderek yavaşladığını farketmekle başlayacaktır. Bu aşamada en iyi çözümlerden biriside kod için Teknik Borçlardan Refactoring yöntemi ile kurtulmaktır. Refactoring düzgün ve sorunsuz olması Test ve Test Code Coverage istenilen düzeylerde olmasıyla münkündür.
Yazılımınız değişmese bile ortam ve teknoloji geliştiği için yazılımınız çevresiyle olan etkileşimi değişecek veya kullanıcıların yazılımdan beklentileri farklılaşacak yazılımınız yine bozulmuş olacaktır. Aşağıdaki 2 yazı bu bahsettiğim konuyla ilgilidir.
4. Teknik Borç Ödenmez ise Ne Olur ?
Teknik borç zamanında ödenmez ise ekibin üretim hızı giderek azalarak işin içerisinden çıkılamayan bir yazılıma sahip olursunuz. Martin Fowler örneklerinde bu konuyu çok güzel özetlemiş
Yazılım = (Group of Function)
Herhangi bir yazılım sistemi esas işini gerçekleştirmek için bir miktar kompleski yapısında içerir, fakat çoğu sistem ekstradan bir tortu içerir, bu sistemin daha zor anlaşılması ve değiştirilmesine neden olur.
Örneğin aşağıdaki resimde yeşil kısım bizim yazılımdan beklediğimiz kısım, fakat kahverengi , yazılımda istemediğimiz kısımlar, bunun yanında ise bu yazılımı kırılım halinde gösterilmiş üçgenlerin çevresinde bu tortudan farklı kalınlıklarda olduğunu ve bunların değişimi engellediği ve güçleştirdiğidir.
Yazılım geliştirmek için bu tortulu yapılara uygun kod geliştirmek ekstradan efor anlamına gelir. Aşağıda resimdeki her kahverengi daire yazılım geliştirmek için teknik borçtan doğan ekstra maliyettir. Yazılım geliştirme hızınızı ne kadar eksi yönde etkilediğini görebilirsiniz.
Aşağıdaki resimde ilk başta low internal quality ile daha hızlı kod geliştirip, daha fazla yetenek eklediğini düşünebilirsiniz ama zaman içerisinde tam tersine high internal quality göre yeni kabiliyet eklemenizin ne kadar zor olduğunun farkına varacaksınız.
Referanslar
- Technical Depth (Martin Fowler)
- Is High Quality Software Worth the Cost? (Martin Fowler)
- Principles of Software Construction: Objects, Design, and Concurrency Software engineering anti-patterns Charlie Garrod Chris Timperley
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
