Yazılım Projesinde Teknik Borç Nedir? Faturası Sonra Gelen Kararlar

Bu yazıda Talha Aslan ve ekibi olarak konuyu yazılımcı gözüyle değil, işletme sahibinin gözüyle ele alıyoruz. Yani kodu okumadan teknik borcu nasıl fark edeceğinizi, teklif karşılaştırırken neyi soracağınızı ve sözleşmeye hangi maddeleri koyacağınızı anlatıyoruz. Rakam ya da süre vaadi yok; çünkü her proje farklıdır. Bunun yerine her bölümde uygulayabileceğiniz bir kontrol aracı veriyoruz.

Önce şunu netleştirelim: teknik borç her zaman kötü değildir. Bazen bilinçli bir karardır. Örneğin bir fikri hızla piyasada denemek için sade bir ilk sürüm çıkarırsınız ve bunu kabul edersiniz. Sorun, borcun kayda geçmemesi, kimsenin farkında olmaması ve hiç ödenmemesidir.

Teknik borç neden oluşur?

Teknik borcun kaynağı çoğu zaman tek bir kötü niyet değil, birçok küçük baskıdır. Sahada en sık gördüğümüz nedenler şunlardır:

• Teslim tarihine yetişmek için testleri atlamak.
• Gereksinimleri netleştirmeden kodlamaya başlamak.
• Aynı mantığı birden çok yere kopyalayıp yapıştırmak.
• Eski kütüphaneleri ve bileşenleri güncellemeden bırakmak.
• Belge yazmayı "sonra yaparız" diye ertelemek.
• Proje boyunca ekibin sık sık değişmesi.

Bu nedenlerin ortak noktası, kısa vadede mantıklı görünmeleridir. Ama her biri sistemde bir iz bırakır. Üstelik izler birbirini besler: testsiz kod değişikliği korkutucu hale getirir, korku da düzeltmeyi erteler.

Microsoft'un yazılım geliştirme uygulamalarını standartlaştırma rehberi bu noktada önemli bir ilkeyi vurgular: "bitti" tanımını herkesin kabul etmesi gerekir ve bu tanım kodu, testi, belgeyi kapsamalıdır. Rehberin geliştirme uygulamalarını resmileştirme bölümüne göre net tanımlar, bitmemiş işin birikmesini önler. Bitmemiş iş ise teknik borcun ta kendisidir.

Teknik borcun türleri nelerdir?

Teknik borç tek bir şey değildir. Farklı türleri farklı belirtiler verir ve farklı yöntemlerle ödenir. Aşağıdaki tablo, işletme sahibinin anlayacağı dille ana türleri özetliyor.

Bu türlerin hepsi aynı anda var olabilir. Ancak hepsinin ağırlığı eşit değildir. Örneğin belge borcu can sıkıcıdır ama mimari borç kadar pahalı değildir. Bu yüzden ödeme planı yaparken türleri ayırmak gerekir.

Kod borcu ile mimari borç arasındaki fark nedir?

Kod borcu, bir odanın dağınık olmasına benzer. Rahatsız edicidir, işi yavaşlatır, ama birkaç gün düzenlemeyle toparlanır. Mimari borç ise evin temelinin yanlış yere atılmasıdır. Dağınıklığı toplamak yetmez; bazen duvarları yıkmanız gerekir.

İşletme açısından fark şudur: kod borcunu günlük işin içinde, küçük adımlarla ödersiniz. Mimari borç ise genellikle planlı bir proje ister. Örneğin tek kullanıcı için tasarlanmış bir sistemi çok şubeli yapıya taşımak, birkaç düzeltmeyle değil, yapısal bir değişiklikle olur.

Bu ayrımı bilmek, ekibinizden gelen talepleri doğru değerlendirmenizi sağlar. Yazılımcı "biraz temizlik lazım" diyorsa genellikle kod borcundan söz ediyordur. "Bu yapı artık bunu taşımıyor" diyorsa mimari borçtan söz ediyordur ve bu ikinci cümleyi ciddiye almanız gerekir.

Ayrıca mimari borcu en başta önlemek, sonradan ödemekten çok daha ucuzdur. Bu yüzden ilk sürümde bile büyüme senaryonuzu ekiple konuşun.

İşletme sahibi teknik borcu nasıl fark eder?

Kodu okumanıza gerek yok. Teknik borç, iş tarafında net belirtiler verir. Aşağıdaki kontrol listesini son birkaç ayınıza göre doldurun:

• Küçük görünen değişiklik talepleri giderek daha uzun sürüyor.
• Bir yeri düzeltince başka bir yer bozuluyor.
• Ekip yeni özellik yerine sürekli hata kapatıyor.
• Yayın günleri gergin geçiyor, geri alma sık yaşanıyor.
• Yeni bir yazılımcının işe alışması çok uzun sürüyor.
• Ekip belli bölgelere "oraya dokunmayalım" diyor.
• Tahminler sürekli tutmuyor.

Bu maddelerden üç ya da daha fazlası tanıdık geliyorsa, sisteminizde ciddi teknik borç birikmiş olabilir. Ancak tek bir madde de tek başına alarm sayılmaz. Örneğin tahminlerin tutmaması bazen belirsiz gereksinimden kaynaklanır.

Son madde özellikle önemlidir. "Oraya dokunmayalım" cümlesi, ekibin o bölümü anlamadığını ya da güvenmediğini gösterir. Böyle bölgeler zamanla işin en kritik parçasına dönüşür, çünkü kimse onları geliştirmeye cesaret edemez.

Teknik borç işletmeye neye mal olur?

Rakam vermeyeceğiz, çünkü maliyet projeden projeye çok değişir. Ama maliyetin nereden geldiğini görmek mümkündür.

İlk maliyet hızdır. Rakibiniz bir özelliği hızla çıkarırken siz aynı değişiklik için daha uzun beklersiniz. Dolayısıyla pazar fırsatlarını kaçırabilirsiniz.

İkinci maliyet kalitedir. Testsiz ve karmaşık kod, müşteriye ulaşan hataları artırır. Bu da destek yükünü büyütür ve itibarı zedeler.

Üçüncü maliyet insandır. İyi yazılımcılar, sürekli yangın söndürdükleri projelerden uzaklaşmak ister. Böylece bilgi kaybı artar ve borç daha da büyür.

Dördüncü maliyet güvenliktir. Güncellenmemiş bileşenler bilinen açıkları içerebilir. Bu, özellikle müşteri verisi tutan sistemlerde göz ardı edilemeyecek bir risktir.

Kısacası teknik borcun faizi, bütçe tablosunda ayrı bir satır olarak çıkmaz. Ama her satırın içine sessizce dağılır. Örneğin destek ekibinin artan mesaisi, kaçan bir kampanya tarihi ya da ayrılan bir yazılımcının yerine yenisini bulma çabası, aslında aynı borcun farklı kalemlerdeki yansımasıdır. Bu yüzden borcu yalnız yazılım bütçesinde değil, işin bütününde düşünmenizi öneriyoruz.

Ucuz teklif neden pahalıya gelebilir?

Yazılım teklifi karşılaştırırken en düşük fiyata yönelmek doğaldır. Ancak fiyat farkının nereden geldiğini sormazsanız, farkı teknik borç olarak sonra ödeyebilirsiniz.

Düşük teklif bazen gerçekten verimli bir ekibi gösterir. Bazen de test, belge, kod incelemesi ve güvenlik güncellemesi gibi görünmeyen işlerin kapsam dışında kaldığını gösterir. Bu işler teslim günü fark edilmez, çünkü ekran çalışır. Fark, birkaç ay sonra ilk büyük değişiklik talebinde ortaya çıkar.

Bu yüzden teklifleri yalnız fiyat ve süreyle değil, kalite kapsamıyla karşılaştırın. Bir sonraki bölümdeki soruları her teklif sahibine aynı biçimde sorun. Böylece elmayla armudu değil, benzer kapsamları karşılaştırırsınız.

Yazılımı sıfırdan yaptırma kararı aşamasındaysanız, bu değerlendirmeyi özel yazılım geliştirme sürecimizle de karşılaştırabilirsiniz; orada kalite adımlarını kapsamın içinde nasıl tuttuğumuzu açıkça anlatıyoruz.

Teklif karşılaştırırken hangi soruları sormalısınız?

Aşağıdaki soruları tüm teklif sahiplerine yazılı olarak iletin ve cevapları yan yana koyun:

1. Otomatik testleri kapsama dahil ediyor musunuz? Hangi bölümler için?
2. Her kod değişikliği başka bir yazılımcı tarafından inceleniyor mu?
3. Proje sonunda hangi belgeleri teslim edeceksiniz?
4. Kaynak kod ve erişim bilgileri kime ait olacak, nerede duracak?
5. Kullandığınız kütüphaneleri nasıl güncel tutuyorsunuz?
6. Bilinçli olarak aldığınız kestirmeleri nasıl kayda geçiriyorsunuz?
7. Yayın sürecini nasıl yürütüyorsunuz, bir hatayı nasıl geri alıyorsunuz?
8. Teslimden sonra bakım nasıl işliyor?

Cevaplar belirsizse ya da "gerek yok" şeklindeyse not alın. Özellikle altıncı soru çok şey anlatır. Kestirmelerini açıkça kaydeden bir ekip, teknik borcu yönetiyordur. Kestirme almadığını söyleyen bir ekip ise ya çok olgundur ya da gerçeği söylemiyordur.

Ayrıca ekibin çalışma düzenini sorun. Kısa döngülerle demo gösteren bir ekip, sorunları erken yakalar. Bu çalışma biçimini Agile ve Scrum yazımızda anlattık.

Teklifleri hangi tabloyla karşılaştırabilirsiniz?

Soruların cevaplarını tek bir tabloda toplamak, kararı netleştirir. Aşağıdaki şablonu kendi tekliflerinize uyarlayın:

Tabloyu doldurduktan sonra fiyata bakın. Böylece fiyat farkının hangi kalemden geldiğini görürsünüz. Örneğin iki teklif arasındaki fark tamamen test ve belgeden kaynaklanıyorsa, ucuz teklif aslında daha pahalı bir geleceği satıyor olabilir.

Teknik borcu nasıl ölçebilirsiniz?

Teknik borcu tek bir sayıyla ölçmek mümkün değildir. Ancak eğilimi izlemek mümkündür. İşletme sahibi olarak teknik metrik yerine şu iş göstergelerini takip edin:

• Benzer büyüklükteki değişikliklerin teslim süresi zamanla uzuyor mu?
• Yayından sonra çıkan hata sayısı artıyor mu?
• Ekibin zamanının ne kadarı hata düzeltmeye gidiyor?
• Geri alınan yayın sayısı artıyor mu?

Bu göstergeleri ekibinizden düzenli bir özet olarak isteyin. Ayrıca yazılım ekibinin kendi kullandığı kalite araçlarının çıktısını da sorabilirsiniz. Microsoft'un rehberi, kalite kapılarını ve statik kod analizini sürekli entegrasyonun bir parçası olarak önerir.

Kalite kavramına daha geniş bakmak isterseniz ISO/IEC 25010 ürün kalite modeli iyi bir çerçeve sunar. Bu model işlevsel uygunluk, performans, uyumluluk ve sürdürülebilirlik gibi kalite özelliklerini tanımlar. Bizim deneyimimizde teknik borç en çok bakım kolaylığı başlığını etkiler.

Teknik borç nasıl ödenir?

Teknik borcu ödemenin ana yolu refactor, yani yeniden yapılandırmadır. Refactor, yazılımın dışarıdan görünen davranışını değiştirmeden iç yapısını sadeleştirmektir. Kullanıcı bir fark görmez, ama ekip bir sonraki değişikliği daha hızlı ve güvenle yapar.

Ödeme planı için üç yaklaşım vardır:

1. Sürekli ödeme: her geliştirme döngüsünde zamanın bir bölümünü temizliğe ayırmak.
2. Fırsat ödemesi: bir bölüme yeni özellik eklerken o bölümü de düzeltmek.
3. Planlı proje: mimari borç gibi büyük kalemler için ayrı bir iyileştirme projesi açmak.

Sahada en sağlıklı sonucu genellikle ilk iki yaklaşımın birlikte kullanılmasında görüyoruz. Üçüncüsü ise yalnız gerçekten gerekli olduğunda devreye girmelidir. Çünkü büyük yeniden yazım projeleri kendi riskini taşır.

Önemli bir uyarı: refactor, testsiz yapılırsa risklidir. Bu nedenle borç ödemesine genellikle test borcunu azaltarak başlamak mantıklıdır. Test otomasyonunun nasıl kurgulandığını test otomasyonu ve STLC yazımızda bulabilirsiniz.

Hangi borcu önce ödemelisiniz?

Her borcu aynı anda ödeyemezsiniz. Önceliklendirme için iki soru yeterlidir: bu bölüm ne sıklıkla değişiyor ve buradaki bir hata işi ne kadar etkiliyor?

Bu tablo önemli bir gerçeği gösterir: hiç dokunmadığınız eski bir bölümdeki borç, size faiz ödetmiyor olabilir. Asıl faiz, sürekli değiştirdiğiniz bölümlerde birikir. Dolayısıyla temizliği oraya yoğunlaştırmak en yüksek getiriyi sağlar.

Ayrıca güvenlik açığı içeren bağımlılıklar bu tablonun dışında tutulmalıdır. Onlar her durumda önceliklidir, çünkü risk iş etkisinden bağımsız olarak dışarıdan gelir.

Sözleşmeye hangi kalite maddelerini eklemelisiniz?

Teknik borcu önlemenin en etkili aracı, beklentiyi baştan yazılı hale getirmektir. Sözleşmenizde ya da ekinde şu maddeleri değerlendirin:

• Kapsamdaki "bitti" tanımı: kod, test ve belge birlikte teslim edilir.
• Kritik iş akışları için otomatik test beklentisi.
• Her değişiklik için kod incelemesi uygulaması.
• Kaynak kodun ve tüm erişim bilgilerinin müşteriye ait olması.
• Kurulum, yayın ve mimariyi anlatan teknik belge teslimi.
• Kullanılan bileşenlerin güncellenmesine dair bakım yükümlülüğü.
• Bilinçli kestirmelerin ortak bir listede kayda geçirilmesi.

Bu maddeler bir hukuk metni değil, iş beklentisidir. Sözleşmenin hukuki çerçevesi için mutlaka hukuk danışmanınızla çalışın; bu yazı hukuki danışmanlık değildir.

Maddeleri çok katı yazmak da sorun yaratabilir. Örneğin her satır için test istemek, gereksiz maliyet doğurur. Doğru yaklaşım, kritik akışları birlikte belirleyip beklentiyi orada yoğunlaştırmaktır.

Bilinçli teknik borç nasıl yönetilir?

Bazen teknik borcu bilerek alırsınız. Örneğin bir fuara yetişmek için bir modülü sade çıkarırsınız. Bu kabul edilebilir bir iş kararıdır, yeter ki üç koşulu sağlasın.

İlk koşul kayıttır. Alınan her kestirme, neden alındığı ve ne zaman ödenmesi planlandığıyla birlikte ortak bir listeye yazılmalıdır. Listeyi ekip ile işletme birlikte görmelidir.

İkinci koşul sınırdır. Kestirme, sistemin geri kalanına yayılmayacak şekilde izole edilmelidir. Böylece borç tek bir bölümde kalır.

Üçüncü koşul geri ödeme tarihidir. "Sonra bakarız" bir tarih değildir. Somut bir döngü ya da olay belirleyin; örneğin fuardan sonraki ilk geliştirme döngüsü gibi.

Bu üç koşul sağlanmadığında bilinçli borç, kısa sürede bilinçsiz borca dönüşür. Kayıt tutmak için ekibin zaten kullandığı iş takip aracı yeterlidir; seçenekleri yazılımcılar için proje yönetim araçları yazımızda karşılaştırdık.

Teknik borç ekip içinde nasıl konuşulur?

Teknik borcun en büyük sorunu çoğu zaman teknik değil, iletişimseldir. Yazılımcı "kod kötü" der, yönetici "yine mi gecikme" diye duyar. Böylece iki taraf aynı sorunu farklı dillerle konuşur ve kimse ikna olmaz.

Bu kopukluğu kapatmak için borcu iş diline çevirmek gerekir. Örneğin "bu modülün testleri yok" demek yerine "bu modüle her dokunduğumuzda müşteri tarafında hata riski var" demek, kararı kolaylaştırır. Benzer şekilde "mimari yetersiz" yerine "ikinci şubeyi eklemek bu yapıyla haftalar sürer" demek, konuyu somutlaştırır.

Ekibinizden borç konuşmalarında şu üç bilgiyi isteyin:

• Sorun hangi iş akışını etkiliyor?
• Ödemezsek önümüzdeki dönemde ne olur?
• Ödemek için kabaca ne kadar emek gerekir ve bunu nasıl parçalara ayırabiliriz?

Bu üç cevap, teknik bir şikâyeti karar verilebilir bir iş önerisine dönüştürür. Ayrıca düzenli aralıklarla, örneğin her ay sonunda, kısa bir borç gözden geçirme toplantısı yapmayı öneriyoruz. Bu toplantıda yeni kestirmeleri, ödediğiniz borçları ve öncelik değişikliklerini konuşursunuz. Toplantının amacı suçlu bulmak değil, ortak bir resim oluşturmaktır.

Öte yandan yazılımcının dürüstçe "burada borç aldık" diyebildiği bir ortam kurmak da işletmenin sorumluluğudur. Borcu saklamak zorunda hisseden bir ekip, sorunu ancak büyüdüğünde gösterir.

Devraldığınız bir projede teknik borcu nasıl değerlendirirsiniz?

Başka bir ekipten ya da serbest çalışan bir yazılımcıdan proje devraldığınızda, teknik borcun boyutunu bilmeden yeni iş planlamak risklidir. Bu nedenle devir sırasında kısa bir değerlendirme yapmanızı öneriyoruz.

Değerlendirme için şu adımları izleyin:

1. Kaynak kodun, veritabanının ve tüm erişim bilgilerinin elinizde olduğunu doğrulayın.
2. Sistemi yeni bir ortamda belgeye bakarak kurmayı deneyin; kurulamıyorsa belge borcu vardır.
3. Mevcut otomatik testleri çalıştırın ve ne kadarının geçtiğine bakın.
4. Kullanılan bileşenlerin güncel ve destekli olup olmadığını listeleyin.
5. Son dönemde en çok hata çıkan bölümleri işaretleyin.
6. İş kurallarının nerede yazılı olduğunu, yoksa kimin bildiğini tespit edin.

Bu adımların sonunda elinizde bir borç haritası olur. Harita, yeni ekibin ilk haftalarda nereye odaklanacağını belirler. Üstelik gerçekçi tahmin yapmanın da ön koşuludur, çünkü borçlu bir bölüme eklenecek özellik her zaman daha uzun sürer.

Devraldığımız projelerde en sık karşılaştığımız durum, sistemin yalnız önceki yazılımcının bilgisayarında kurulabilir olmasıdır. Bu durumda ilk iş, kurulumu ve yayını tekrarlanabilir hale getirmektir.

Teknik borç güvenliği nasıl etkiler?

Teknik borcun en az konuşulan ama en riskli yüzü güvenliktir. Güncellenmemiş bir bileşen, yıllar önce kapatılmış bir açığı hâlâ taşıyor olabilir. Kimse o bölüme dokunmadığı için de risk fark edilmez.

Güvenlik tarafında teknik borç genellikle şu biçimlerde ortaya çıkar:

• Desteği sona ermiş dil veya çatı sürümleri.
• Kod içine gömülü parola ve erişim anahtarları.
• Yetki kontrolünün yalnız arayüzde durması, arka tarafta ikinci bir kontrolün olmaması.
• Hata kayıtlarının hiç tutulmaması ya da kimsenin bakmaması.

Bu maddeler teslim günü hiçbir belirti vermez. Ama bir saldırı ya da veri sızıntısı yaşandığında maliyetin en büyük kısmını oluşturur. Bu yüzden güvenlik borcunu öncelik tablosunun dışında, her zaman ilk sıraya koymanızı öneriyoruz.

Microsoft'un geliştirme rehberi de bağımlılıkların sürekli taranmasını ve güvenlik taramalarının entegrasyon sürecine eklenmesini önerir. Yani güvenlik, projenin sonunda bakılan bir kontrol değil, her değişiklikte çalışan bir alışkanlık olmalıdır. Kişisel veri işleyen sistemlerde yasal yükümlülükler için hukuk danışmanınıza başvurun.

Yapay zekâ destekli kodlama teknik borcu artırır mı?

Yapay zekâ destekli kod araçları, yazılımcıların rutin işleri daha hızlı yapmasını sağlar. Ancak hız, teknik borç açısından iki yönlü bir etkidir. Doğru kullanıldığında test yazmayı ve standart kalıpları kolaylaştırır. Denetimsiz kullanıldığında ise kimsenin tam anlamadığı kodu hızla çoğaltır.

Microsoft'un geliştirme rehberi bu noktada dengeli bir tavır önerir: yapay zekâ tekrarlayan doğrulama işlerini üstlenebilir, ama iş mantığının doğru uygulanması için insan incelemesi vazgeçilmez kalır. Biz de sahada aynı ilkeyi uyguluyoruz.

İşletme sahibi olarak ekibinize şu soruları sorabilirsiniz:

• Yapay zekâ ile üretilen kod da aynı inceleme sürecinden geçiyor mu?
• Bu kod için de test yazıyor musunuz?
• Üretilen kodun lisans ve güvenlik açısından kontrolünü kim yapıyor?

Bu soruların cevabı netse, yapay zekâ teknik borcu azaltan bir araç olabilir. Değilse, borcu daha hızlı biriktiren bir hızlandırıcıya dönüşür. Kısacası araç değil, onu çevreleyen disiplin belirleyicidir. Bu konuda belirli bir aracı en iyi ilan etmiyoruz; güncel özellikleri sağlayıcıların resmi sayfalarından kontrol edin.

Yeniden yazmak mı, iyileştirmek mi daha doğru?

Teknik borç büyüdüğünde ekipten sık duyulan öneri "baştan yazalım" olur. Bu cazip gelir, çünkü temiz bir sayfa hissi verir. Ama sıfırdan yazım, mevcut sistemin yıllar içinde öğrendiği tüm küçük iş kurallarını yeniden keşfetmeyi gerektirir.

Karar için şu soruları sorun:

• Mevcut sistemin iş kuralları yazılı mı, yoksa yalnız kodda mı?
• Sistemin temel teknolojisi hâlâ destekleniyor mu?
• Bölüm bölüm iyileştirme mümkün mü?
• Yeniden yazım süresince mevcut sistem ayakta kalabilecek mi?

Çoğu durumda bölüm bölüm iyileştirme daha düşük risklidir. Yeni yapıyı eski sistemin yanında kurar, işlevleri parça parça taşırsınız. Böylece her adımda çalışan bir sisteminiz olur.

Öte yandan temel teknoloji artık desteklenmiyorsa ya da güvenlik güncellemesi alamıyorsa, kapsamlı bir yenileme kaçınılmaz olabilir. Bu kararı tek bir kişinin görüşüyle değil, bağımsız bir teknik değerlendirmeyle vermenizi öneriyoruz.

Teslim sonrası bakım teknik borcu nasıl etkiler?

Yazılım teslim edildiği gün eskimeye başlar. Kütüphaneler güncellenir, tarayıcılar değişir, güvenlik açıkları ortaya çıkar. Bakım planı yoksa, sistem hiç değişmese bile borç birikir.

Bu duruma bağımlılık borcu diyoruz ve en sinsi türdür. Çünkü kimse kod yazmadığı halde sistem zamanla kırılgan hale gelir. Bir gün küçük bir güncelleme yapmak istediğinizde, zincirleme bir güncelleme ihtiyacıyla karşılaşırsınız.

Bakımda dikkat edilecek temel kalemler şunlardır:

1. Bileşen ve kütüphanelerin düzenli güncellenmesi.
2. Güvenlik bildirimlerinin takibi.
3. Yedekleme ve geri yükleme testleri.
4. Performans ve hata kayıtlarının gözden geçirilmesi.

Web tarafındaki benzer düzeni aylık web sitesi bakım kontrol listesi yazımızda anlattık; özel yazılımlar için de mantık aynıdır.

Excel'den yazılıma geçerken teknik borcu nasıl önlersiniz?

Tablolardan özel yazılıma geçen işletmeler, teknik borç riskiyle özellikle erken karşılaşır. Çünkü ilk sürüm aceleyle çıkarsa, tablodaki karmaşa koda taşınır.

Bu riski azaltmak için geçiş öncesinde iş kurallarını yazılı hale getirin, veri temizliğini koddan önce yapın ve ilk sürümü küçük tutun. Ayrıca ilk sürümde bile test ve belge beklentisini sözleşmeye ekleyin.

Geçiş kararının işaretlerini ve adımlarını Excel'den özel yazılıma geçiş rehberimizde ayrıntılı anlattık. İki yazıyı birlikte okumak, hem doğru zamanda harekete geçmenizi hem de doğru şekilde başlamanızı kolaylaştırır.

Kısacası teknik borcu önlemenin en ucuz anı, projenin ilk haftasıdır. Bu haftada konuştuğunuz kalite beklentisi, yıllarca sürecek bir sistemin bakım maliyetini belirler.

Teknik borçla ilgili en sık yanılgılar nelerdir?

Sahada sık karşılaştığımız yanılgıları kısaca düzeltelim:

• "Teknik borç yalnız kötü yazılımcılarda olur." Hayır, iyi ekipler de borç alır; fark, onu yönetmeleridir.
• "Çalışıyorsa sorun yoktur." Çalışan ama değiştirilemeyen sistem, işletmenin büyümesini durdurur.
• "Refactor boşa harcanan zamandır." Aksine, bir sonraki özelliğin süresini kısaltan yatırımdır.
• "Baştan yazarsak borç biter." Disiplin değişmezse yeni sistemde de borç birikir.
• "Bunu yalnız yazılımcılar takip eder." Borcun önceliğini iş etkisi belirler, bu da işletmenin kararıdır.

Son madde bu yazının ana fikridir. Teknik borç teknik bir terim gibi görünse de, aslında bir iş kararıdır. Ne kadar borç alacağınıza ve ne zaman ödeyeceğinize, iş hedeflerinizle birlikte karar verirsiniz.

Ayrıca hata ayıklama alışkanlıkları da borcun büyümesini etkiler. Sistematik bir yaklaşım için hata ayıklama teknikleri yazımıza göz atabilirsiniz.

Teknik borç için ne zaman dış destek almalısınız?

Ekibiniz borcu kayıt altına alıyor, düzenli ödüyor ve iş göstergeleri sağlıklıysa, dış desteğe çoğu zaman gerek yoktur. Ancak değişiklik süreleri sürekli uzuyorsa, ekip belli bölgelere dokunmaktan kaçınıyorsa ya da mevcut yazılımcı sistemi bırakıp gidiyorsa, bağımsız bir göz faydalı olur.

Talha Aslan ve ekibi olarak bu tür durumlarda önce mevcut sistemi inceliyor, borcu türlerine ayırıyor ve iş etkisine göre bir ödeme planı öneriyoruz. Yeniden yazımın gerekmediği durumda bunu açıkça söylüyoruz. Yeni bir proje başlatıyorsanız, kalite beklentisini baştan kapsamın içine yerleştiren firmaya özel yazılım yaklaşımımızı inceleyebilirsiniz.

Hiçbir ekip sıfır teknik borç vaat edemez; biz de etmiyoruz. Vaat edilebilecek olan, borcun görünür, ölçülebilir ve planlı ödenir halde tutulmasıdır.