Teknik Borç Hesaplaması: Hıza Dayalı vs. Soruna Dayalı Vs. Kaliteye Dayalı Ölçümlerin Açıklaması

Faiz oranları yüzde 157 arttı!

Hayır, Fed'in son kararından değil, Fictional Inc.'in platformunun 3.0 sürümünü yayınladıktan sonra karşılaştığı yavaşlamadan bahsediyorum.

Neyse ki ürünün piyasaya sürülmesi inanılmaz derecede başarılıydı ve gelir artışının hızla arttığını görmeye başlıyorlar, ancak artık sürümün bir parçası olarak getirdikleri teknik borçlarla nasıl başa çıkacaklarını düşünmeleri gerekiyor.

Yeni bir sürüm kapsamında uygulamaya konan yeni teknoloji borcunun, faiz oranını arttırdığı ve ekibin gelecekte karşılaşacağı yavaşlamayı artırdığı düşünülebilir.

(Burada teknik borç kavramına oldukça aşina olduğunuzu varsayıyorum, ancak hızlanmak için bilgilerinizi tazelemeye ihtiyacınız varsa, burada hızlı bir astar )

Tamam, muhtemelen bir mühendislik yöneticisinin teknik borçları hakkında böyle konuştuğunu duymayacaksınız.

Ama neden olmasın?

Devam eden etkinizi ölçebilme ve ölçebilme Teknoloji borcu kritik önemde Eğer bu sorunu çözmek için uygulanabilir bir plan hazırlamak istiyorsanız.

Teknik borcu düşündüğümüzde faiz , mevcut ve gelecekteki gelişimde kaybedilen zamanın mevcut teknik borç seviyenize oranıdır.

Bu, anaparayı geri ödemeye yönelik gelecekteki kararları düşünürken borcun dikkate alınması gereken kritik kısmı olduğu anlamına gelir (borçtan sorumlu kodun yeniden yazılması, yeniden düzenlenmesi veya düzeltilmesi maliyeti) - çünkü bunu yalnızca faizin ödenmesi durumunda dikkate alacağız. yeterince yüksektir.

Sağlıklı Teknik Borç Düzeyi Nedir?

Teknik borç yeni gelişmeleri açıkça yavaşlatıyor; ancak bu tek başına teknoloji borcunu her yerde düzeltmemiz gerektiği anlamına gelmiyor. Mevcut kodu yeniden yazmaya veya yeniden düzenlemeye geri dönmek önemli ölçüde maliyetli olabilir; bu nedenle teknik borç anaparamızı yalnızca faizimiz (ileriye doğru ilerlememizi yavaşlatan miktar) anaparamızı aşarsa geri ödemek isteriz.

Bariz bir sorun hemen ortaya çıkıyor - temel, sabit bir zaman birimidir (düzeltme/yeniden yazma saatleri), ancak faiz, zaman başına kaybedilen saatlerin oranıdır. Bunu açıklamak için bir etki aralığı fikrini ortaya koymamız gerekiyor; bu, teknik borçtan kaynaklanan gelecekteki yavaşlamaların yeniden yazma maliyetini aşıp aşmadığını önemsediğimiz zaman. Önemsediğiniz etki aralığı büyük ölçüde şirketinize, tipik planlama sürecinize ve aşamasına veya kod tabanınızın yaşam döngüsüne bağlı olacaktır - ancak ben şahsen genellikle 3 aylık etki aralığına bakacağım. Bir şirket olarak ilk aşamamızda, herhangi bir şeye yıl + zaman çizelgeleri içinde bakmak çok geniş kapsamlı olacaktır, ancak daha sonra göreceğimiz gibi, 2-3 aydan kısa olan herhangi bir şey, teknik borcun etkisini büyük ölçüde hafife alacaktır.

Bu, aşağıdaki durumlarda teknoloji borcumuzun ele alınmaya değer olmadığı anlamına gelir:

Örneğin: bizi haftada 2 saat yavaşlatan teknoloji borcu olduğunu bildiğimiz küçük bir projemiz olsaydı, bu borcu yeniden düzenlememiz 4 günümüzü alırdı ve 3 aylık etki aralığını önemserdik, o zaman bunu yapmazdık. henüz bu borcu ödemek için zaman ayırın.

Aslında bu, sağlıklı bir teknik borç düzeyine cevap vermiyor; çünkü sanırım hepimiz takımda büyük yavaşlamalarla karşı karşıya kalmanın sağlıklı olmadığı konusunda hemfikir olabiliriz. Bunun yerine artık yeniden yazmaya ve yeniden düzenlemeye ne zaman odaklanmamız gerektiğini veya odaklanmamamız gerektiğini belirlemenin hızlı bir yoluna sahibiz. Makalenin ilerleyen kısımlarında sağlıklı bir borç seviyesinin aslında ne olduğuna bir göz atacağız.

Teknik Borcu Nasıl Ölçeriz?

Teknoloji borcu faiz oranımızı belirlemek, aldığımız farklı kararlardan dolayı ne kadar yavaşladığımızı anlamamızı gerektirir. Ne yazık ki, gelişiminizin ne kadar yavaşladığını takip etmenin bariz veya önemsiz bir yolu yok; ancak iyi tahminler elde etmek için uygulayabileceğiniz üç farklı yaklaşım var.

Hız Esaslı Ölçüm

Yavaşlamaları kod tabanımızın farklı bölümlerine bağlamanın en doğrudan yolu, projenizin farklı bölümleri arasında hızın zaman içinde nasıl değiştiğine bakmaktır. Kod tabanının farklı alanlarına bakarak, farklı bölümlerdeki varyasyonları (örneğin, bu analiz bölümüne dokunan herhangi bir geliştirme, diğer her şeyden 3 kat daha uzun sürer) tanımlamaya başlayabilirsiniz. Bir alanın zaman içindeki değişimine bakmak, size yeni gelişmenin gelecekteki gelişme oranını nasıl etkilediğine dair bazı ipuçları verebilir ve ekibinizin uğraştığı ilgi düzeyine dair bir fikir verebilir.

Örneğin: Üzerinde çalışacağımız 4 farklı alandan oluşan nispeten basit bir projemiz varsa, o zaman hızın zaman içinde nasıl değiştiğine bakabiliriz (burada hızı hikaye noktaları/geliştirici ayı cinsinden izliyoruz).

Teknik Borcun Etkisinin Hız Bazlı Ölçümü

Buradan D'nin benzer karmaşık görevler için diğer alanlardan herhangi birinin üzerinde çalışmasının her zaman ~3 kat daha uzun sürdüğünü görebiliriz. Bu, kod tabanının diğer tüm bölümlerinden 3 kat daha fazla ilgiye sahip olduğu anlamına gelir. B, A & C ile nispeten aynı seviyedeydi, ancak 4. aydan itibaren aniden yükseldi ve 2 kat daha fazla zaman aldı. Bu, B'ye göre daha önce faiz oranımızı ikiye katlayan bir miktar borç getirdiğimizi gösteriyor.

Dikkat edilmesi gereken bir nokta da, kod tabanının tamamı için faiz oranından değil, bireysel bileşenler/alanlar için faiz oranından bahsediyor olmamızdır; bunun nedeni, teknik borçtaki artışların neden olduğu yavaşlamaların genellikle önemli sorunlar olmamasıdır. yaptığımız her şeyi etkiler, bunun yerine kod tabanının bir bölümünde yerelleştirilirler.

Hıza dayalı ölçüm söz konusu olduğunda dikkate alınması gereken bazı önemli uyarılar vardır.

• Hız değişken olabilir ve yeni (veya mevcut) hatalar, yanlış hizalanmış tahminler, teknik engeller veya harici proje gecikmeleri gibi teknik borçtan bağımsız faktörlere bağlı olabilir.

• Tahminlerin doğası gereği bir belirsizlik düzeyi vardır ve başlangıçta hatalı bir ölçüm olabilir.

• Bu verileri toplamak ve analiz etmek zor ve zaman alıcı olabilir.

  
  

Hıza dayalı ölçüm için hızlı bir örnek, mühendislik ekibinizden, kod tabanınızın her bir ana alanında bir projeyi/görevi tamamlamanın göreceli olarak ne kadar süreceğini tahmin etmesini istemektir. İyi anlaşılan/sık kullanılan bir alan için belirlenmiş bir temel üzerinde anlaşın ve ardından herkesin diğer alanı bu temel çizginin yüzdesi veya katları olarak tahmin etmesini sağlayın. Tam hıza dayalı bir ölçüm yaklaşımı kadar titiz olmasa da, ekibinizin içgörüsü ve sezgisine dayalı olarak göreceli teknoloji borcu faiziniz hakkında hızlı bir fikir verebilir.

Sorun Bazlı Ölçüm

Farklı bir yaklaşım, projenizdeki belirli teknik borç örneklerini belirlemek ve bunların her birinin sizi ne kadar yavaşlatabileceğini tahmin etmektir. Bunun bir kısmı, bir projenin okunabilirliği, genişletilebilirliği veya sürdürülebilirliği üzerinde etkisi olabilecek kod kalitesiyle ilgili ortak sorunları bulmak için statik analiz araçları gibi otomatik araçlar kullanılarak yapılabilir. Her bir sorun türü için, ekibinizin bu tür sorunlarla baş etme konusundaki deneyimine bağlı olarak, ona bir faiz maliyeti (örneğin, haftada 5 dakika veya %1) atayabilirsiniz.

Ancak bu yalnızca sorunlara neden olan teknik borcun bir alt kümesini yakalayacaktır; diğerleri ise daha incelikli veya kod tabanınıza daha özel olacak ve yalnızca ekibiniz kodun o alanı üzerinde aktif olarak çalışırken gözlemlenecektir. Bu durumda, belirli bir sorunu (kod tabanınızın bir alanına bağlı) ve bunun geliştirmeyi yavaşlatmadaki tahmini etkisini kaydetmek isteyeceksiniz. Bu sorunları takip etmek için GitHub, Jira vb.'deki bir sorun biriktirme listesinde bir tür sorun izleyici kullanmanızı veya aşağıdaki gibi amaca yönelik oluşturulmuş bir teknik borç sorunu izleyici kullanmanızı öneririz. Adım boyutu .

Bu yaklaşımın dezavantajlarından bazıları şunlardır:

• Belirli konulara bağlı zaman tahminleri hatalı olabilir
• Bazı sorunlar uzun süre kolaylıkla fark edilmeden kalabilir

Kaliteye Dayalı Ölçüm

Kod tabanınızın durumuna ilişkin genel bir fikir edinmek ve bunun karşılığında, her alanda gelecekteki gelişimi etkileyen şu anda ne kadar teknik borcunuz olduğuna dair bir tahmin almak için kullanabileceğiniz çeşitli kod kalitesi ölçümleri vardır. Sourcery'de şöyle bakma eğilimindeyiz: Karmaşıklık , Çalışan bellek ve Yöntem Uzunluğu, bir işlev veya sınıf içinde bakarken kritik ölçümler olarak kullanılır; ancak Sürdürülebilirlik Dizini, Belge ve Test Kapsamı, Çoğaltma Oranı ve diğerleri gibi şeylere de bakabilirsiniz.

Soruna dayalı yaklaşıma benzer şekilde, teknik borç nedeniyle gelişimde devam eden ve gelecekteki yavaşlamaya farklı puanların (veya genel kalite veya sağlık puanının) göreceli etkisini atayabilirsiniz. Araştırmalar, Karmaşıklık ve Hız gibi şeylerin yanı sıra kod kalitesi ile hata riski, bakım yükü ve daha fazlası arasında güçlü bir negatif korelasyon olduğunu göstermiştir.

Bir örneğe bakarak, Hız Tabanlı Ölçüm bölümünde incelediğimiz 4 parçalı basit kod tabanını tekrar gözden geçirelim.

Bu projenin sorun bölümlerini tabloda (kırmızıyla vurgulanmıştır) kolayca görebiliriz ve Faiz tahmininin hesaplanması nispeten basittir; farklı bileşenlerin faiz etkilerini özetlemeniz yeterlidir.

Bu yaklaşımın dezavantajlarından bazıları şunlardır:

• İlgi alanı etki tahminlerini farklı kalite ölçümlerine göre tanımlamanız gerekir (bazılarını temel olarak bir araya getirmeyi düşünüyorum, ancak bu oldukça kod tabanına bağlı olacaktır). Bunu yapmak için muhtemelen hıza dayalı ölçümlere bakmak ve bunu kaliteye bağlamak isteyeceksiniz.
• Kalite ölçütlerinin kendisi kusurludur ve dilden dile önemli ölçüde farklılık gösterir .

Bu kaliteye dayalı ölçüm yaklaşımı, incelediğimiz üç yaklaşım arasında en az kesinliğe sahip olanıdır; ancak zaman içinde projenizin farklı alanlarına bütünsel bir bakış sunma konusunda çok etkilidir. Projenizin her bölümünde genel kalite ve sağlık sorunlarını izlemenin yanı sıra belirli sorunları izlemeyi dengelemek için bu yaklaşımı az önce tartıştığımız soruna dayalı yaklaşımla birleştirebilirsiniz.

Kod Tabanı Etkileşim Sıklığına Bakmak

Bu yaklaşımların üçü için de, kod tabanımızın farklı bölümlerindeki etkiyi, kod tabanının o bölümüne fiilen dokunduğumuz sıklığa göre haritalayacak bir yola ihtiyacımız var. Projemizde başa çıkılması gereken bir kabus olan ama artık kimsenin dokunmadığı bir bölüm varsa, bu aslında devam eden teknik borcumuzu çok fazla etkilemiyor demektir. Tersine, kod tabanının her gün katkıda bulunan bir bölümündeki küçük ama kalıcı bir yavaşlama, çok hızlı bir şekilde büyük zaman kayıplarına neden olabilir.

Bunu hesaba katmak için projemizin her alanına ne sıklıkla katkıda bulunulduğuna bakmamız gerekecek. Burada uygulayabileceğimiz birkaç farklı yaklaşım var; Git geçmişine bakarak hangi alana en sık dokunulduğunu anlamak için daha odaklanmış araçlar kullanırız: Kod sahnesi daha anlaşılır tarihsel katkı verileri elde etmek veya ekibimizin önümüzdeki birkaç ay içinde zamanının çoğunu nerede geçireceğini anlamak için gelecek planlarımıza ve önceliklerimize bakarak ileriye dönük bir yaklaşım kullanmak.

Verileri nasıl elde ettiğimize bakılmaksızın, zamanımızın yüzde kaçını kod tabanımızın her bir bölümüyle etkileşimde bulunarak harcayacağımızın bir dökümünü alabiliriz. Bunu daha önce belirlediğimiz İlgi katkısıyla birleştirirsek, artık kod tabanımızın her bir bölümüyle ileriye doğru ilerlerken ne kadar yavaşlamayı beklediğimizi tam olarak görebiliriz.

Önceki örneğimize devam edersek - ileriye dönük bir bakış açısına sahip olsaydık ve önümüzdeki 3 ay içinde üzerinde çalışacağımız tüm projeleri yenileseydik ve bunun kod tabanının her alanında harcanan zaman miktarı olduğunu güvenle tahmin edebilseydik ( bunun çok basit bir proje olduğunu unutmayın):

Artık bunu Hız Tabanlı yaklaşımımızdan ve Kalite Ölçüt Tabanlı yaklaşımımızdan elde ettiğimiz İlgi tahminlerine bağlayabilir ve en çok nerede yavaşladığımıza dair iyi bir fikir edinebiliriz.

Burada, daha önce hıza dayalı ölçüme baktığımızda B ve C bölümleri üzerinde çalışırken gördüğümüz hız yavaşlamalarını kullanıyoruz ve bunu önümüzdeki üç ay içinde teknoloji borcundan dolayı ne kadar zaman kaybı beklediğimizi hesaplamak için kullanıyoruz. Genel olarak, sadece borca harcanacak 28 geliştirici aydan fazla ekstra çaba görmeyi bekliyoruz. Bu yaklaşımda göz önünde bulundurulması gereken önemli bir nokta, tüm bunların göreceli hıza bakmasıdır; dolayısıyla temel projelerin fiilen hiçbir borcu yokmuş gibi ele alınır ki bu normalde doğru değildir. Bu yaklaşımın bir diğer sorunu da gelecekteki borç seviyelerinde meydana gelmesi muhtemel değişiklikleri hesaba katmamasıdır. Ancak bunları tahmin etmek zordur, dolayısıyla onları göz ardı etmek daha kolaydır.

Burada, her bölümün kod kalitesine dayalı olarak tipik öngörülen gecikmelerimizi aldık ve bunu önümüzdeki üç aya yansıttık. Genel olarak, hız yöntemini kullandığımız zamana göre önemli ölçüde daha düşük borç etkisi tahminleri görüyoruz. Bunun nedeni, teknoloji borcuna dayalı yavaşlama tahminlerinin hız durumunda gördüğümüzden daha düşük olmasıdır; bu durumda biraz daha kalibrasyon yapmamız gerekebilir! Tıpkı hıza dayalı ölçümde olduğu gibi, bu da teknoloji borcundaki gelecekteki değişiklikleri hesaba katmıyor; ancak her iki tahmin de projemizin farklı bölümlerini yeniden yazmaya ve yeniden düzenlemeye nasıl öncelik vermemiz gerektiğini belirlememize yardımcı olabilir.

Faiz ve Borç Yönetimi

Teknik borcumuzun bizi sürekli olarak ne kadar etkilediğini açıklamak için birkaç farklı yola baktık, ancak sağlıklı bir teknik borç seviyesinin ne olduğu sorusuna tam olarak yanıt vermedik.

Maalesef kesin bir rakam yok. Kısa vadede bir miktar borcu kabul etmek pragmatik olabilir. Ancak uzun vadede borcumuzu sıfıra yakın tutmayı hedefliyoruz. Çünkü devam eden faiz çok maliyetli olacak ve teknoloji borcu kendi üzerine büyümeye devam edecek. Ancak tüm zamanımızı, bize yalnızca marjinal kazançlar sağlayan konuları yeniden düzenleyerek ve yeniden yazarak harcamak istemiyoruz.

Daha önce tartıştığımız gibi, genellikle kod tabanının şu alanlarına değinerek zaman harcamak istemiyoruz:

Ancak bunun en uç örneğinde, düzeltilmesi son derece maliyetli olan yüksek seviyedeki borç nedeniyle büyük ölçüde yavaşladığımız bir durumla karşı karşıya kalabiliriz ki bu da iyi bir durum değildir.

En iyi yaklaşım ortada bir yere düşmektir. Devam eden planlamanızda teknik borç sorunlarını ele almak ve mevcut kodu yeniden düzenlemek için zaman ayırın; şu anda sizin için en maliyetli olana öncelik verin. Ve borcunuzu azaltmanın getirilerinin önemli ölçüde azaldığını görene kadar bunu zorlamaya devam edin.