Kariyerimin başlarında, henüz ürün yöneticisi yardımcısı olarak işe yeni başlamışken, teknik borcu (diğer adıyla teknik borç) ilk duyduğumda ne anlama geldiğinden pek emin değildim. Komik bir şekilde, bunun üçüncü taraf yazılımlar satın almak için çektiğimiz bir kredi olduğunu düşündüm ve bu terimi iki ya da üç hafta boyunca kendimden emin bir şekilde yanlış kullandım. Mühendislerimin günlük toplantıdan sonra beni bir kenara çekip nazikçe düzeltmeleri karşısında yaşadığım mahcubiyeti hayal edin!

Öyleyse, iş başında hepimizin kızarmasını önlemek ve mühendislerimiz nezdinde itibar kazanmamıza yardımcı olmak için teknik borcun ne olduğunu ve ürün yöneticileri olarak neden önemsememiz gerektiğini inceleyelim.

Teknik Borç Nedir ve Ne Zaman Sorun Oluşturur?

Yazılım geliştirme, ürün işlevselliğinin kapsamı ile yüksek kaliteli kod arasında denge kurmaktan ibarettir. Bu süreçte, geliştirme sürecini hızlandırmak için bazen kestirme yollara başvururuz; bu kestirme yollar teknik borç veya teknik borç olarak adlandırılır.

Teknik borçlanmak ne zaman iyi bir fikirdir ve ne zaman patlamaya hazır bir bombaya dönüşür? Bu soruyu yanıtlamak için önce teknik borcun geçmişine bakalım.

Teknik Borç Nedir?

Bu terimi ortaya atan kişi olan Ward Cunningham, teknik borcu finansal borca benzetir: Gelecekteki hız ve istikrar karşılığında borçlanmak sorun değildir, ancak eninde sonunda bu borcu ödememiz gerekir. Bu, her geliştirme ekibinin anlaması ve her ürün yöneticisinin ürün kararları alırken dikkate alması gereken bir kavramdır.

Teknik borç, ürünleri planlanandan önce yayımlamamıza ve müşterilerin kullanımına daha hızlı sunmamıza yardımcı olur. Ancak eninde sonunda kod tabanımızın kalitesine yatırım yaparak “borcu azaltmamız” gerekir.

İdeal olarak, teknik borçtan yararlanmak isteyip istemediğimize veya bundan kaçınmak isteyip istemediğimize aktif olarak karar vermeliyiz. Finansal borca benzer şekilde, daha sonra ortaya çıkacak öngörülmemiş bir maliyet karşısında şaşırmak istemeyiz!

Teknik Borcun Basitleştirilmiş Tanımı

Teknik borç (bazı ekiplerde kod borcu olarak da adlandırılır), daha uzun sürecek daha iyi bir yaklaşım yerine kısa vadeli bir kestirme yolu tercih ettiğinizde gelecekte yapılması gereken yeniden çalışmanın örtük maliyetini ifade eder. Bu, bir krediye faiz ödemeye benzer; teknik borcun maliyeti zaman içinde artar.

Kullandığım benzetmelerden biri sakal tıraşı olmaktır. Acelem varsa ve hızlıca tıraş olursam, muhtemelen şimdiye kadarki en temiz tıraş olmaz ve daha sonra geri dönüp düzeltmem gerekir.

Hem ilk tıraş hem de sonradan yapılan düzeltme tıraşı için gereken toplam zaman ve çaba, en başta düzgün bir tıraş olsaydım harcayacağımdan daha fazla olacaktır.

Ancak bazen, zamanımız tükenirken hızlı tıraşı tercih etmek zorunda kalırız!

Finansal Borç ile Teknik Borcun Karşılaştırılması

Bu kavramı daha anlaşılır hâle getirmek için finansal borç ile teknik borç arasındaki karşılaştırmayı biraz daha derinlemesine inceleyelim. Sonuçta ürün yöneticilerinin hem işletme finansı kavramlarını hem de teknik kodlama kavramlarını anlaması gerekir!

Finansal borcun avantajları: Finansal borç kaldıraç etkisi sağlar. Borç para almak, büyüme fırsatlarına yatırım yapmak için gereken sermayeyi sağlayabilir. Ayrıca finansal borç, peşin ödeme gerektirmeden kaynaklara veya varlıklara anında erişim olanağı sunar.

Finansal borcun dezavantajları: Finansal borç, birçok farklı türde maliyeti beraberinde getirir. Finansal borcun faiz ödemeleri zaman içinde birikerek genel kârlılığı azaltabilir. Ayrıca finansal borcun gerektiği gibi yönetilememesi finansal istikrarsızlığa yol açabilir.

Ayrıca borç, finansal esnekliği kısıtlayabilir ve gelecekte belirli yolları izlememizi engelleyebilir. Finansal yükümlülüklerin yerine getirilmemesi de bir kuruluşun itibarına zarar verebilir.

Teknik borcun avantajları: Teknik borç, ilk ürün geliştirme sürecini hızlandırarak sıkı teslim tarihlerine uymaya veya pazardaki fırsatlardan yararlanmaya yardımcı olur. Ayrıca finansal kaldıraca benzer şekilde, teknik borçlanmaya gitmek başlangıçtaki geliştirme maliyetlerini azaltabilir.

Teknik borcun dezavantajları: Finansal borçta faiz biriktiği gibi, mevcut kestirme yolların üzerine ek özellikler veya değişiklikler inşa edildikçe teknik borç da katlanarak artar; bu durum gelecekteki geliştirmeyi daha karmaşık ve maliyetli hâle getirir. Ayrıca teknik borç çoğu zaman kod kalitesinin idealin altında kalmasına ve zaman içinde bakım maliyetlerinin yükselmesine yol açar.

Teknik borç, bir ürünün değişen pazar koşullarına uyum sağlama veya yeni özellikler ekleme becerisini engelleyebilir. Ayrıca ele alınmayan teknik borç; sistem arızalarına, güvenlik açıklarına veya performans sorunlarına yol açarak ürünün sürdürülebilirliğini etkileyebilir.

Bu bizim için ne anlama geliyor? Hem finansal borç hem de teknik borç açısından amaç borçtan tamamen kaçınmak değildir. Bunun yerine, ihtiyatlı yönetim kilit önem taşır.

Belirli bir borç düzeyi büyüme açısından stratejik olabilir; ancak uzun vadeli olumsuz sonuçları en aza indirmek için borcu dikkatle izlemeli ve yönetmeliyiz.

Teknik Borç Örnekleri

Yazılım mühendisliği alanında geliştirme ekipleri düzenli olarak teknik borçla karşılaşır. En yaygın örneklerden birkaçını ele alalım.

Eski kod

Bazı ekipler, bir özelliği hızlıca kullanıma sunmak için güncelliğini yitirmiş eski kodlar kullanabilir. Bu, hemen işlevsellik sağlayabilir ancak özellikle yeni özellikler eklendikçe daha sonra kapsamlı bir yeniden düzenleme gerektirebilir. Tıpkı eski bir el yazması gibi, eski kod da geliştirici nesilleri boyunca aktarılmış ve tarihin ağırlığını biriktirmiştir.

En parlak döneminde amacına başarıyla hizmet etmiş olsa da zaman, uyarlanabilirliğini ve sürdürülebilirliğini aşındırır. Eski koda gereğinden fazla güvendiğimizde üretim ortamında kesintiler ve hatalar ortaya çıkma eğilimindedir!

Sabit Kodlama

Sabit kodlama, yapılandırılabilir ayarlar kullanmak yerine belirli değerlerin veya sabitlerin doğrudan kodun içine yerleştirilmesi uygulamasını ifade eder.

Bu yaklaşım kısa vadede geliştirmeyi hızlandırsa da ilerleyen süreçte çoğu zaman sorunlara yol açar. Büyük bir kod tabanında dosya yolu veya zaman aşımı eşiği gibi sabit kodlanmış bir değerin değiştirilmesi gerektiğini düşünün. Bu durum hızla zaman alan ve hataya açık bir göreve dönüşerek yazılımın sürdürülebilirliğini ve esnekliğini tehlikeye atabilir.

Bu tuzaktan kaçınmak için geliştiriciler, kodlarının uyarlanabilirliğini artıran yapılandırılabilir seçenekleri tercih etmelidir.

Kod Tekrarı

Kod tekrarı, benzer veya aynı kod parçacıklarının proje genelinde birden çok yerde bulunması durumunda ortaya çıkar. Başlangıçta geliştirme sırasında zaman kazandıran kullanışlı bir kestirme yol gibi görünebilir. Ancak yazılım geliştikçe ve gereksinimler değiştikçe tutarlılığı korumak ve güncellemeler yapmak karmaşık bir dansa dönüşür.

Kod tekrarı yalnızca hata oluşturma riskini artırmakla kalmaz, gelecekteki geliştirmeler ve hata düzeltmeleri için gereken çabayı da katlar. Kodun yeniden kullanılabilirliğini sağlamak ve gereksiz kodları ortadan kaldırmak, bu soruna karşı koymanın temel ilkeleridir.

Belgelendirme Eksikliği

Belgelendirme, mevcut ve gelecekteki geliştiriciler için yolu aydınlatan kılavuz ipliği görevi görür. Kapsamlı belgelendirmenin bulunmaması, harita olmadan karmaşık bir yolculuğa çıkmaya benzer. Bu durum, belirli kod seçimlerinin ardındaki gerekçeyi açıklayan satır içi yorumların eksikliğiyle başlayabilir veya eksik kullanıcı kılavuzlarına ve sistem mimarisi belgelerine kadar ilerleyebilir.

İlk geliştirme aşaması sorunsuz ilerleyebilse de uzun vadeli sonuçlar ciddi olabilir. Hata ayıklama şifreli bir uğraşa dönüşür, ekip üyeleri arasındaki bilgi aktarımı zorlaşır ve projeyi ölçeklendirmek çoğu zaman karanlıkta bir labirentte yol bulmaya benzer. Kapsamlı belgelendirmenin benimsenmesi, yazılım geliştirmede ileriye giden yolu aydınlatan ışıktır.

Otomatik Test Eksikliği

Otomatik testlerin bulunmaması, bir teknenin sızıntısı olup olmadığını önceden kontrol etmeden denize açılmaya benzer. Otomatik testler (birim, entegrasyon ve gerileme testleri dahil), kod kalitesinin ve kararlılığının dikkatli koruyucularıdır.

Testler göz ardı edildiğinde sonuçlar hemen fark edilmeyebilir. Başlangıçta geliştirme hızla ilerleyebilir ve yazılım işlevsel görünebilir. Ancak kod tabanı büyüyüp geliştikçe öngörülemeyen sorunlar ortaya çıkmaya başlar. Daha önce çalışan özelliklerin yeni değişikliklerle bozulduğu gerileme hataları yaygınlaşır.

Güvenlik ağı sağlayacak otomatik testler olmadan geliştirme ekibi, zaman alan ve hataya açık bir süreç olan manuel testlere güvenmek zorunda kalır. Otomatik testleri en baştan benimsemek, yazılım geliştirmenin çalkantılı denizinde istikrarlı bir rota sağlar.

Çevik Geliştirmede Teknik Borcun Rolü Nedir?

Ah, Çevik geliştirme! Scrum metodolojileri ve Çevik Manifesto'daki ilkeleri değişimi ve hızı benimser. Peki teknik borç bu tabloya nasıl uyuyor? Ne de olsa teknik borç, Çevik yaklaşımın kurucu belgelerinde özel olarak ele alınmaz.

Şöyle bir Star Wars benzetmesi yapabiliriz: Millennium Falcon, maceraları için en iyi durumda kalmak amacıyla Han Solo ve Chewbacca tarafından sürekli bakımdan geçiriliyordu. Benzer şekilde, bir Çevik ürün ekibi, yazılım kalitesini korumak ve müşterileri için kahramanca maceralara olanak sağlamak üzere teknik borcu yönetir! 

Teknik Borç Nasıl Kullanılır ve Yönetilir?

Çevik ekipler, iş gereksinimlerini hızla karşılamak için bazen teknik borç üstlenebileceklerinin farkındadır. Bunun her zaman kötü bir şey olmadığını unutmayın. Çevik yazılım geliştirme alanında düşünce lideri olan Martin Fowler, bunun ödünlerle ilgili olduğuna dikkat çeker. Bir kavramı doğrulamak veya pazara daha hızlı ulaşmak için yazılım ürünü yaşam döngüsünün ilk aşamalarında bir miktar borcu kabul edebilirsiniz.

Önemli olan teknik borcu yönetmektir. Teknik borç iş listesinde belgelenmeli, önceliklendiril meli ve gelecekteki sprintlerde ele alınmalıdır. Bunun gerçekleşmesi için ürün yöneticileri güçlü proje yönetimine dayanmalı ve şimdiye kadar üstlenilen teknik borcun miktarını iyi anlamalıdır.

Teknik Borç Ne Zaman Sorun Olur?

Paydaşlar teknik borçtan habersiz olduğunda veya geliştirme süreci büyük ölçüde geçici çözümlere dayandığında, işte o zaman alarm zilleri çalmaya başlamalıdır. Neden?

1. Görünmezdir: Metrikler veya düzenli kod incelemeleri olmadan, gizli güvenlik açıkları ortaya çıkabilir.
2. Kullanıcı Deneyimini Etkiler: Altta yatan sorunlar işlevselliği etkilemeye başlarsa, bu yalnızca geliştiricinin sorunu değil, işletmenin de sorunudur.
3. Yeni Özellikleri Engeller: Kötü kodun içinde sıkışıp kalan programcılar daha az üretken olur ve yaratıcılık azalır.
4. Yol Haritasında Yer Almaz: Ekipler teknik borcun farkında olmalı ve buna yönelik bir stratejiye sahip olmalıdır. Bir eylem planı oluşturmak için harici web seminerlerinden ve kaynaklardan yararlanmaktan çekinmeyin.

Teknik Borç Nasıl Ölçülür?

DevOps uygulamaları ve otomasyon gibi araçları kullanarak ekipler kod tabanlarını takip edebilir ve şimdiye kadar birikmiş teknik borcu izleyebilir. Aşağıda, teknik borcu takip edebileceğiniz on iki farklı yöntemi bir araya getirdim.

Bunların hepsini kullanmak zorunda değilsiniz! Bunun yerine, bu listeyi bir başlangıç noktası olarak değerlendirin. Önümüzdeki ay içinde uygulamak üzere bir veya iki tanesini seçin, ardından teknik borcu takip etme ve çözme konusunda ekibinizin yetkinliğini yavaş yavaş geliştirin.

1) Statik Kod Analizi: SonarQube, ESLint veya FindBugs gibi araçlar; kod karmaşıklığı, kod kokuları ve olası hatalar gibi çeşitli sorunlar açısından kodu otomatik olarak analiz edebilir. Önceden tanımlanmış kurallara ve eşiklere dayanarak kod kalitesi ve teknik borç hakkında nicel metrikler sağlarlar.

2) Kod Kapsamı: JaCoCo veya Istanbul gibi araçlarla kod kapsamını ölçerek kod tabanının ne kadarının otomatik testler tarafından kapsandığını değerlendirebiliriz. Düşük kod kapsamı, test eksikliğine ve olası teknik borca işaret edebilir.

3) Eşler Arası Kod İncelemeleri: Eşler arası kod incelemeleri gerçekleştirmek, geliştiricilerin olası teknik borç unsurlarını belirlemesine ve tartışmasına olanak tanır. Ayrıca iki akıl bir akıldan iyidir; kötü kod kalıplarından kaçınmak için harika bir yoldur! Ekipler kod kalitesini değerlendirmek ve belirlenen sorunları belgelemek için kontrol listeleri veya yönergeler kullanabilir. İncelemelerde bulunan sorunların sayısı ve önem derecesi, teknik borcun niteliksel bir ölçüsü olarak kullanılabilir.

4) Manuel Kod İncelemeleri: Geliştiriciler ve ekipler, yeniden düzenlemeden yararlanabilecek kod tabanı alanlarını belirlemek için manuel kod incelemeleri veya kod üzerinden geçme çalışmaları gerçekleştirebilir. Bu süreç genellikle deneyimli geliştiricilerin kodu incelemesini ve sorunları belgelemesini içerir; çünkü bu kişiler teknik tasarım borcunu en iyi şekilde değerlendirme eğilimindedir. 

5) Teknik Borç İş Listesi: Ürün iş listesini veya belirlenen teknik borç unsurlarının listesini tutmak yaygın bir uygulamadır. İş listesindeki her unsur bir açıklama, etki değerlendirmesi ve öncelik derecelendirmesi içermelidir. İş listesindeki unsurların boyutu ve önceliği, teknik borcun niteliksel bir ölçüsünü sağlar.

6) Hata ve Sorun Takibi: Hata önceliklendirme sürecini analiz etmek, teknik borçla ilişkili sorunların sıklığını ve önem derecesini ortaya çıkarabilir. Çok sayıda hata raporu veya aynı sorunların sık sık tekrarlanması, altta yatan teknik borca işaret edebilir.

7) Tahmin ve Hikâye Puanları: Yeni işler veya kullanıcı hikâyeleri planlanırken geliştirme ekipleri, teknik borç unsurlarını ele almak için gereken çabayı tahmin edebilir. Genellikle Çevik metodolojilerde hikâye puanları biçiminde ifade edilen bu çaba tahmini, teknik borcu çözmek için gereken işi nicelendirir.

8) Kod Karmaşıklığı Metrikleri: Döngüsel karmaşıklık, kod satırı sayısı ve kod değişim sıklığı gibi metrikler, kod tabanının karmaşıklığı ve sürdürülebilirliği hakkında içgörü sağlayabilir. Daha yüksek karmaşıklık ve belirli kod alanlarında aşırı değişiklik yapılması teknik borca işaret edebilir.

9) Kullanıcı Geri Bildirimi: Kullanıcı geri bildirimleri ve destek talepleri, teknik borcu dolaylı olarak ortaya çıkarabilir. Sistem performansı, güvenilirliği veya beklenmedik davranışlarla ilgili sık kullanıcı şikâyetleri, ele alınması gereken altta yatan sorunlara işaret edebilir.

10) Otomatik Test Metrikleri: Test yürütme süresi, test başarısızlık oranları ve kararsız testler gibi otomatik testlerle ilgili metrikleri izlemek, test altyapısının sağlığını değerlendirmeye ve teknik borçtan etkilenen alanları belirlemeye yardımcı olabilir.

11) Anketler ve Görüşmeler: Geliştirme ekipleriyle anketler ve görüşmeler yapmak, algılanan teknik borç düzeyi ile bunun üretkenlik ve kod kalitesi üzerindeki etkisi hakkında niteliksel içgörüler sağlayabilir. Ayrıca paydaş geri bildirimlerini toplamak, yeniden çalışma gerektirebilecek alanlar hakkında içgörü edinmeye yardımcı olabilir.

12) Teknik borç çeyreği: Özellikle yararlı araçlardan biri, Martin Fowler tarafından tanıtılan teknik borç çeyreğidir. Teknik borcun nedenlerini kasıtlı ve kasıtsız olmanın yanı sıra dikkatsiz ve ihtiyatlı olarak kategorilere ayırarak ekiplerin ödünleşimleri anlamasına yardımcı olur.

Bu teknik borcu ölçmenin on iki yolunun dışında, ekibinizin teknik borç takibini ve çözümünü yönetmeye yardımcı olması için ürün yönetimi araçlarını kullanmaktan çekinmeyin!

Teknik Borcun Kapatılması

Teknik borcun nasıl oluştuğu hakkında çok konuştuk, ancak şimdiye kadar bu borcun nasıl kapatılacağını ele almadık. Ürün yöneticileri olarak ekiplerimize borcun ne zaman kapatılacağına ve ne zaman ek teknik borç üstlenileceğine karar verme konusunda rehberlik etmek bizim sorumluluğumuzdur.

Mühendisler daha önce belirlenmiş teknik borç maddelerini ele almak için kod tabanını güncellediğinde teknik borcu kapatırız. Bu; işlevselliği daha verimli olacak şekilde yeniden tasarlamayı, otomatik testleri uygulamaya koymayı veya kod hakkında derinlemesine dokümantasyon sağlamayı içerebilir.

Teknik borcu azaltmanın en iyi yollarından biri, her sprintte kod tabanını güçlendirmeye ve borcu azaltmaya zaman ayırmaktır. Bunu aylık konut kredisi ödemeleri yapmak gibi düşünün; konut kredisi borcunu ne kadar hızlı azaltabilirsek, genel olarak ödememiz gereken faiz de o kadar azalır!

Genel bir kural olarak 80/20 kuralı iyi bir yaklaşımdır. Yani her sprintte zamanın yaklaşık %80'ini yeni özellikler geliştirmeye, %20'sini ise teknik yatırımlara ve iyileştirmelere öncelik vermeye ayırın.

Teknik borcu azaltmayı planlarken, bunu ürün yol haritanıza uygun şekilde dahil etmeyi düşünün.

Teknik Borç Hakkında Son Düşünceler

Tüm bunları özetlemek gerekirse, teknik borcu yönetmek yalnızca geliştiricilerin işi değildir. Ürün yöneticileri, Çevik ekipler ve iş paydaşları da bu süreçte rol oynar.

Nihai hedef mi? Sürdürülemez bir borca yol açmadan iş hedeflerini karşılayan yüksek kaliteli bir yazılım ürünü sunmak.

Dolayısıyla ister yazılım geliştirmenin derinliklerine dalıyor olun, ister geliştirme ekibinizin neden sürekli yeniden düzenlemeden söz ettiğini anlamaya çalışıyor olun, teknik borcu anlamak ve yönetmek ihtiyacınız olan pusuladır.

Ürün kariyerinizin henüz başında olun ya da ürün yönetiminde deneyimli bir uzman olun, teknik terminolojiye ilişkin anlayışınızı derinleştirmekten neredeyse her zaman fayda sağlarsınız.

Umarım kariyerimin başlarında yaptığım hatanın aynısını yapmazsınız—bilmediğiniz teknik kavramları tahmin etmek için yalnızca bağlam ipuçlarına güvenmeyin!

Bunun yerine araştırma yapmaya, bunun gibi harici kılavuzlara başvurmaya ve değerli bilgilerinizi tazelemek için mühendislerinizle zaman geçirmeye vakit ayırın.

Daha fazla ürün yönetimi içgörüsü ve kılavuzu için bültenimize abone olmayı unutmayın!