Technical Debt - Teknik Borç
Teknik Borç (Technical Debt)
Kaynaklar
Teknik Borç Kavramına Giriş
Çevik Geliştirme Manifestosunun (Agile Manifest) yazarlarından Ward Cunningham’ın ortaya attığı bir metafordur. Design Debt olarak da bilinir.
Özetle günü kurtaran kısa vadeli çözümler geliştirmek, gelecekte yapılacak geliştirmeler için, gerekenden daha fazla efor gerektiren bir yapı oluşturur ve zamanla verimlilik sürekli düşer. Bu fazladan, aslında bir şey üretmeyen çalışmalar teknik borcun faizinin ödenmesidir.
Nedenleri: Teknik borç sadece kötü koddan ortaya çıkmaz. Gerçekçi olmayan proje kısıtları altında çalışan iyi programcılar da bu borcu üretebilir.
Kötü kod ise zaten kötü koddur. Ve kötü kod teknik borç yaratır.
Teknik borç proje ilerlerken de belirebilir. Zaman geçtikçe uygulama alanında (domain) yeni bir şey öğrenilir, başlangıçtaki mimarinin teknik borç kazandığını görebiliriz. Bu durumda neyi başlangıçta gözden kaçırdığımızı düşünüp ders alabiliriz. Ancak geleceği görmek çoğu zaman mümkün olmaz. Y.A.G.N.I. prensibine uymaya devam edilmeli.
Extreme Programming’de (XP) Refactoring - Yeniden Düzenleme yöntemlerini uygulamak geliştirme metodolojisinin önemli bir parçasıdır. Refactoring sadece kötü kodu düzeltmek değil, aynı zamanda gelişen / evrim geçiren sorun anlayışıyla sorununun en iyi çözümünü uygulamaktır.
Teknik borç Refactoring - Yeniden Düzenleme ile giderilir. Ana parayı (principal) refactoring ile ödeyebiliriz. Zaman alır ancak gelecekte ödenecek faizi düşürür ya da belki de ortadan kaldırır. Borçlu kodda geçirilen her dakika faizi arttırır.
Biraz borca girmek geliştirmeyi hızlandırabilir, ancak hemen refactoring ile borç ödenmelidir. Ödenmezse tehlike belirir.
Uygulamayı hızlıca yayınlamak ve bir tecrübe edinmek iyi bir fikir. Ancak eninde sonunda geri dönüp edinilen tecrübeyi koda yansıtmak için refactoring yapılarak borç ödenecek.
Borcun ve kod kalitesinin ne olduğu, ne olması gerektiği tartışmaya açık. Ancak şu söylenebilir:
“Eğer kodda değişiklikler yapılması gerektiğinde (yeni özellik eklemek, mevcut özelliği değiştirmek veya hata düzeltmesi yapmak) verimlilik yüksek kalıyorsa, kod yüksek kaliteye sahiptir.”
Özet: Anlık çözümlerle, kestirmelerle üretilip yeterince kaliteli olmayan kodlarla iş tamamlandığında geliştirme ekibi Teknik Borca maruz kalır.
Bu borç verimliliği düşürür.
Verimliliğin düşmesiyle oluşan kayıp Teknik Borcun faizidir.
Çözüm (Engelleme):
Takım eforu
İhtiyacı karşılama durumu
Kod kalitesi ölçülmeli.
Teknik borcun konuları:
Mimari
Yapı
Kod tekrarı
Test kapsamı
Yorumlar ve dokümantasyon
Olası hatalar
Karmaşıklık
Kod pratikleri ve tarzı
Bu konuların her biri üretkenlikte olumsuz bir etkiye sahiptir.
Teknik borç kötü bir şey mi?
Kısayollar kullanarak iş değeri oluşturan bir ürünü hızlıca yayına almak genelde kötü bir karar değildir.
Ancak teknik borcun eninde sonunda zarar vereceği konusunda bilinçli olunmalıdır.
Takım zamanla bu birikmiş borcun en azından bir kısmını ödemeye başlar.
Teknik borç detaylı bir şekilde analiz edilmeli ve giderilmesi için gerekli strateji belirlenmelidir.
Teknik borç nasıl analiz edilir?
Her borç kalemi aynı değildir. Durumu anlamak ve yapılacak refactoring işlemlerini belirlemek ve önceliklendirmek için analiz yapmak önemlidir. Aşağıdaki tablo dikkate alınması gereken konuları içeren bir liste sunar:
Teknik borç kalemi özelliği | Detay, Mantık |
Etkinin tipi | Hangi aktiviteler ve yetenekler zarar görecek? |
Etkinin miktarı | Ne kadar zarar verecek? İşe olan olası olumsuz etki kısıtlı mı, … yoksa çok mu yüksek? |
Etkinin süresi ve tekrarlama sıklığı | Etki bir kez mi yaşanacak, yoksa tekrar mı edecek? |
Etkinin zamanlaması | Etki çok yakın bir zamanda mı yaşanacak, yoksa daha ileri bir tarihte, yayına alındıktan sonra mı? (örneğin ne zaman yüksek bir test kapsamı elde etmeliyim?) |
Teknik borç kaleminin yaşı | Eskiden kalma bir teknik borç mu, yoksa ekip bunu son versiyonda mı ekledi? |
Kasıtlı mı, değil mi? | Kasıtlı olmayan teknik borç takımın eğitilmesi ve takıma koçluk yapılması ihtiyacını tetikleyebilir. |
Refactoring maliyeti | Bu aşama borcun geri ödenmesi aktivitelerinin planlanması ve önceliklendirilmesine yardımcı olur. |
Diğer teknik borç kalemleriyle bağımlılığı | Teknik borç kalemi bir başka kalemin etki alanında da tanımlanmış mı? |
Aşağıdaki harici konular da refactoring çalışmalarının seçimi ve önceliklendirilmesi konusunda dikkate alınmalı:
Bileşenin iş açısından değeri
Bileşenin tarihçesi, yaşı ve gelecekte devreden çıkarılma durumu
Olumsuz etkiye maruz kalınması olasılığı (Teknik borcun yer aldığı kod parçasının kullanımına ve değişme sıklığına bağlıdır.)
Proje Yönetimi ve Teknik Borç
Bir atasözü: “Act in haste, repent at leisure.”
Bu atasözü teknik borç kavramına tamamen uyar.
İnsanlar teslim tarihi baskısıyla kısayollar kullanır, ki bu proje yönetiminin teknik borcun belirleyicisi olduğu çeşitli yollardan birisidir. Proje yönetimi şu açılardan da önemlidir:
Gerçekçi bir proje planı teknik borcun etkisini dikkate alır.
Daha iyi bir proje planı ise plana teknik borcun ödenmesi için zaman da dahil eder.
Teknik borcu gidermek için çeşitli seçenekler var. Yine de önemli olan şu:
Mümkün olduğunca teknik borç oluşturmaktan kaçınılmalı. |
Çevik proje yönetimi teknik borcun üstesinden gelmekle ilgili birçok seçenek sunar.
Teknik Borcu Yayına Hazırlama Sürecine Dahil Et
İş ve teknik endişeleri uzlaştır (alignment)
Teknik borç ile
Bugün hızlı yayınlarsın
Yarın ve gelecekte yayınlaman (gittikçe) daha uzun sürer
Teknik borca yaklaşım açık seçik belirtilmeli ve bu konuda uzlaşılmalı. (Kısa ve uzun vade planları)
Çalışma Sözleşmesi
Ekip teknik borç endişesini içeren bir çalışma sözleşmesine sahip olmalı. Örneğin statik kod analizi ile belli 10 kurala her zaman uymak.Şu konuları da içerebilir:
Mentoring
Pair programming
Diğer ölçme, engelleme ve çözme aktiviteleri
Uzun vadeli iyileştirmeler için kısa vadeli yatırımlar
Uzun vadede verimliliği nasıl arttırırız? → Teknik borcu azaltacak kısa vadeli yatırım çalışmaları ile.
Statik kod analizi
Planlara bu analiz dahil edilebilir.
Eğer yoksa bir kez analiz yapıp bir baseline oluşturmak.
Sonra periyodik olarak yeniden ölçerek baseline ile karşılaştırmak ve kontrol etmek.
Statik kod analizi, kod teftişinin yapamayacağı şekilde, teknik borcu farklı yollarla görünür hale getirebilir.
Teknik borç iterasyonları
Borç birkaç refactoring ile çözülemeyecek kadar büyükse, sadece bu borcu azaltmaya bir veya daha fazla iterasyon (versiyon) adanabilir. (Özellikle kodla yeni bir takım çalışmaya başlıyorsa özellikle yararlı olur.)
Experimentation
Teknik borç giderme önlemlerinin sonuçları duruma göre değişebilir. Ayrıca kod incelemesi / teftişi gibi bazı önlemler takımdan takıma değişebilir. Test otomasyonu gibi bazı aktiviteler, teknik borç üzerinde doğrudan bir etkiye sahip olmasalar da takımın teknik borç giderme yeteneğinde güçlü ikinci-seviye etkilere sahip olabilir. Önlemlerle denemeler yaparak uygun yöntemleri zamanla seçin.
Başarılı deneyleri terfi ettir ve sürece kat
Deneylerin başarılı ve etkili sonuçlarını sürece kat. Ya da daha fazla zaman ayırarak detaylı ve kapsamlı bir şekilde uygulamaya yoğunlaşarak verimi arttır. Örneğin CI takımın koduna daha fazla dikkat etmesini sağlıyorsa CI araçlarını ve pratiklerini incelemeye ve uygulamaya daha fazla zaman ayır.
Eğitim
Takım dışındakileri teknik borç azaltıcı aktivitelerin değeri konusunda eğitmeyi planla.
Teknik Borcu Her İterasyon Seviyesinde Dikkate Al
Test kod kapsamı
Kod kapsamı sadece hataları bulmaya yaramaz, kodun hedeflenen davranışı hakkında fazladan bilgiler içerir, test yolları karmaşıklık ve diğer teknik borç kalıplarını ortaya çıkarır. (Örneğin Cyclomatic Complexity)
Maliyet
Teknik borcun sabit maliyetini ölç. Soru: “Zamanın yüzde kaçını teknik borç yüzünden verimsiz (üretken olmadan) harcadın?” Bu verinin trendini çıkararak teknik borcun etkisini görselleştirebilirsin.
Sabit maliyet (overhead) Teknik borç takımların sorunları tespitin zorlaştırır, genel sabit maliyete yük bindirir ve yeni özelliklerin geliştirilmesi için gerekli süreyi daraltır / kısıtlar. Sorunların ve diğer konuların tespitini toplam sabit maliyetin yüzde kaç arttırdığını kabaca hesaplayabilirsin. Örneğin refactoring yapma süresini oluşturur ve kullanırsan yayındaki hataların tespitindeki süreyi %30'dan %20'ye indireceğini tahmin edebilirsin.
Hız azalması (Velocity Reduction) Teknik borç takımların yeni özellik geliştirmesini de zorlaştırır. Aynı şekilde kaba bir tahminle, eğer koddaki temel teknik borç nedenlerini giderirsen, özelliğin geliştirilmesinin ne kadar kolaylaşacağını hesaplayabilirsin. Örneğin kod tekrarı ve zayıf hata yönetimi düzeltilirse 8 saat yerine 5 saatte bitebileceğini hesaplayabilirsin.
Geliştirici mutluluğu
“Bu kod deposuyla çalışmaktan ne kadar mutlusun?” Eğer teknik borç nedeniyle geliştirici kodda etkin bir şekilde çalışamıyorsa mutluluk ve verimlilik düşer.
Refactoring
Özelliği geliştirme süresi verilirken Refactoring - Yeniden Düzenleme eforunu da dahil etmelisin.
Teknik borç özellikleri / storyleri
Takımın belli bir kısmını teknik borç giderme işlerine ayırabilirsin.
Slack (Gevşek zaman)
Yeteri kadar gevşeklik yarat ki, geliştiriciler eğer zaman uygunsa refactoring yapabilsinler.
(Çünkü yarın demek hiçbir zaman demektir. LeBlanc's Rule)
Mentoring (Koçluk)
Geliştiricilere teknik borcu nasıl engelleyeceklerini öğretmek için zaman ayır. Çift veya grup programlamalarıyla iyi pratikler hakkında daha derin tartışmaları öner.
Gidişat (Flow)
İterasyonda gidişatı izle, teknik borç oluşturucu nedenler işe karışıyor mu? (Örneğin bir sorunu sadece bir geliştirici çözebiliyor, çünkü kodun nasıl çalıştığını sadece o biliyor.)
Statik kod analizi
Teknik borcu azaltmak için statik kod analizi yaparak genel durumu görebilirsin.
Retrospectives (Geçmişi değerlendirme)
Geçmişe dönük vakaları, bunların takımı nasıl etkilediklerini değerlendirebilir, borcu azaltmak için kullandığınız fikirleri gözden geçirebilirsin.
Yeni Özellikleri Geliştirirken Teknik Borcu Dikkate Almak
Kötü kod yazmak için iyi bir neden olamaz. |
Kod incelemesi / teftişi
Kod incelemeleri yapılması “Yapıldı Tanımı”na eklenebilir.
Yapıldı tanımı: Bu tanım borcu engelleyebilir. Kod kapsama ve kod teftişi gibi aşamaları dahil etmek teknik borcu engellemek için gerekli disiplini enjekte etmeyi sağlar.
Çift / grup programlama
İyi ve kötü kod hakkında anlayışı paylaşmak, teknik borçtan kaçınmak ve borcu gidermek konusunda öğrenmeyi teşvik etmek için çift / grup programlamayı öner.
“Kodu bulduğundan daha temiz bırak” Kodun en sık değiştiği yerlere odaklanarak, teknik borcu giderme verimi artabilir. Kod her değiştiğinde biraz daha iyileştirilirse zamanla doğal olarak borç giderilecektir.
Bu kuralı “Çalışma Sözleşmesi”ne eklemeyi düşün.
Fırsatçı Yeniden Düzenleme: Refactoring için planlama yapmayı bekleme, fırsat bulduğun anda yap.
Kodlama standartları
Takım kodlama standartları hakkında uzlaşmalı ve herkes birbirini buna uymaktan sorumlu tutmalı. Teknik borca yönelik standartlarla başlayabilirsin. Zamanla takım kendini ayarlayıp geliştirecek.
Teknik borcu görünür kıl
Kodu geliştirirken teknik borca odaklanmayı sağlayan ve kod kalitesini görünür kılan araçlar kullan.
NCrunch (Sürekli Test)
SonarQube (Statik kod analizi ile Sürekli Kod Teftişi)
SonarLint, Refactoring Essentials, Code Cracker (Statik analiz ile kod iyileştirme önerileri ve hızlı uygulama seçenekleri)
NDepend (Statik kod analizi, kod karmaşıklık ve bağımlılık incelemesi ve teknik borç tespiti)
CodeMaid (Kod temizliği, organizasyonu ve formatlama ile ilgili analiz ve öneriler.)
Bu mikro geribildirim döngüsünü sağlamak için
Kodlama standartlarını highlight eden editörler
Statik kod analizi yapan ve kod kapsamını ölçen araçlar kullan.
Sonuç
Her takım bu borcu gidermek konusunda nereden başlayacağı hakkında karar vermeli.
Nihayetinde bir “Çalışma Sözleşmesi” oluşturulmalı, bu sözleşme teknik borcu nasıl ele aldığını ve giderdiğini içermeli.
Her takım veya projenin yapısı farklıdır. Bu yüzden sözleşmeye hangi konuların ekleneceği konusunda takdirde bulunmayı tecrübe etmek gerek.
Tabi ki işe yarar ve çalışan, zamanla da gelişecek bir sözleşme oluşturma konusunda dikkatli olunmalı. (Hiçbir zaman uygulanmayacak, ideal bir sözleşme oluşturmak yerine)
Last updated