Teknik Borçları DX ve AI ile Yönetmek

Her şirket, büyük veya küçük, teknik borcu konusunda endişe duyar. Gartner tahminlerine göre, altyapı sistemlerinin yaklaşık %40’ında bu sorun vardır. CIO’lar arasında yapılan bir McKinsey anketinde, yaklaşık üçte biri, yeni ürün bütçesinin %20’den fazlasının teknik borcu çözme ile ilgili sorunlara gittiğini hissetti. Ancak banyak insanın düşündüğünün aksine, bu yalnızca bir kodlama sorunu değil; aynı zamanda bir geliştirici deneyimi (DX) sorunudur. Çünkü geliştiriciler yetersiz mimari, eski araçlar ve düşük kaliteli geliştirme iş akışları ile çalışmak zorunda kaldıklarında, verimlilik, performans ve moral olumsuz etkilenir.

Teknik borcu, geliştiricinin bakış açısını dikkate alarak, nasıl çalıştıklarına, kullandıkları araçlara ve kariyer gelişimlerine odaklanarak önceliklendirmek, ekiplerin odaklanmasına ve daha hızlı sevkiyata yardımcı olur. Bu nedenle, şirketlerin teknik borcu yönetme şekli, DX ve AI destekli araçlara odaklanmayla değişmektedir.

DX’yi Savunmak

Geliştiricilerin genellikle nasıl entegre edildiği çok istenen bir durum değildir. Bir projeye katkıda bulunmaya başlamak için birkaç hafta alone geçebilir. Sonunda küçük özellikler veya yamalar eklemeye başladıktan sonra, sürekli entegrasyon (CI) hizmetinin, yaptıkları değişikliklerle ilgili olmayan bir şey nedeniyle başarısız olması nadir değildir. Bu, temel olarak test süitesinin, kalitesizlik sorunları nedeniyle başarısız olmasıdır ve geliştirici, test süitesini bozmak için değişiklik göndermedi. Bu, yalnızca %90 oranında çalışan, kararsız ve kötü yazılmış bir testtir. Mevcut ekip muhtemelen buna alışkın, ancak dışardan gelenler için demoralize edici ve işlemleri yavaşlatan bir araç olabilir.

Bu, doğru DX’yi engelleyen birçok örneğin sadece biridir. Bunu önlemenin bir yolu, yazılım mühendisliği ve geliştirme ekibinizde bir DX şampiyonu belirlemektir. Küçük organizasyonların çoğunda DX lideri yoktur, ancak büyük ve başarılı olanlar vardır. Bu uzmanlar, yeni bir geliştiricinin bir ortamı kurmak için ne kadar süre harcadığını izler. Ve iki hafta çok uzunsa, bu süreyi yarıya indirme yollarını bulurlar.

DX’yi iyileştirmeye yardımcı olacak araçlar vardır, örneğin CircleCI, test süitesinin kararsızlığını izleyen yerli özelliklere sahiptir. Gereken, liderlik yapmak ve her sprint sonunda, gelecekte kodun bakımını ve çalışmasını kolaylaştıracak bazı değişikliklere odaklanmaktır. DX’yi iyileştirmeye ilgi duyan bir liderin olması gerekir. Bunu gerçekleştirmek için, bir senior seviye mühendis ve yeni bir personel üyesi ile geri bildirim sağlamak için olası boşluklar hakkında görüş alışverişi yapabilirsiniz.

Ayrıca, IDC, AI destekli yazılım test otomasyon pazarının 2027’ye kadar %31,2’lik bir CAGR ile büyümeye devam edeceğini tahmin ediyor, bu nedenle bu teknolojiyi mümkün olan en iyi şekilde kullanmanız önemlidir.

Uyarı İşaretleri ve Metrikler

Teknik borcun ekibinizi nasıl etkilediğini değerlendirdiğinizde izleyebileceğiniz birçok metrik vardır. Temel olanlar “hata düzeltme süresi” veya “özellik süresi” olabilir. Diyelim ki bir hatayı fark ettiniz ve nasıl düzeltileceğini biliyorsunuz. Bazı araçlar, kod yazma yoluyla üretime kadar harcanan zamanı izleyebilir. Örneğin, çok küçük bir yama iki iş günü sürdü ve ekibinizin bunu birkaç saat içinde yapması gerekiyor. Ayrıca, hata düzeltme sayısı ile tamamlanan özellikler arasındaki oranları da izleyebilirsiniz.

Ekibinizin performansını etkileyen moral sorunlarını belirlemenin yolları da vardır. DX liderleri, geliştiricilerin bir proje veya bir parçası üzerinde çalışmaktan ne kadar mutlu olduklarını belirlemek için çeyrek olarak anketler düzenleyebilir. Belirli alanlar hakkında, örneğin CI işlemleri hakkında, derinlemesine soru sorabilirler. Ayrıca, ekibinizdeki personel değişimini veya devir oranını her zaman izleyebilirsiniz. Eğer insanların sürekli ayrıldığını fark ederseniz, endişeleri duyulmuyor olabilir.

AI ile Araçlar

AI destekli araçların yükselişi, geliştiricilerin ve mühendislerin daha verimli olmasını ve ürünlerin daha hızlı sevkiyatını sağlamayı amaçlamaktadır, ancak teknik borcu azaltma yavaşlatır. Diyelim ki GitHub veya Copilot gibi bir aracı kod değişiklikleri için kullanıyorsunuz, ardından bir çekme isteği gönderiyorsunuz ve CI size birkaç saat sonra geri dönebilir. Bu sırada, geliştirici başka bir şey üzerinde çalışır mı? E-postalarını kontrol eder mi? Bu, bir bağlam değişikliği ve verimlilik öldürücüdür.

Geliştiriciler, yalnızca kod üzerinde çalışabileceği ürünlerde çalışmak ister. Araçlar, kodu üretime ulaştırmaya yardımcı olmak için vardır, sürekli bir engel olmamalıdır. AI, zaman kazandırabilir, ancak mühendislik ekiplerinin kabul edilebilir karmaşıklık standartlarını tanımlaması gerekir. Bunu yapmak için, önce ana dalınıza eklenen herhangi bir kodun kabul edilebilir bir teknik borcu seviyesine sahip olduğundan emin olun. Öncesinde, teknik borcu ve kod kalitesini kabul edilebilir bir eşikte belirlemek için mühendislik ekibi ile açık bir tartışma yapın ve ekibinizden onay alın. Herkesin, bu eşiği aşmanın hemen düzeltilmesini gerektirdiğini bilmesini sağlayın. Bu standartları belirledikten sonra, AI devreye girer.

Mühendislerin AI ajanlarıyla birlikte çalışabileceği bir durum vardır. Capgemini’nin 1.100 büyük kuruluş yöneticisiyle yaptığı bir anket, %82’sinin gelecek üç yıl içinde AI ajanlarını entegre etmeyi planladığını ortaya koydu ve bunlar çalışmanın geleceğini zaten etkilemektedir. Bir hata raporunu inceliyorsunuz ve AI ajanının başlangıçtan kod incelemesine kadar küçük bir şeyi ele alabileceğini görüyorsunuz, böylece ekibinizin zaman kazandığını ve daha karmaşık işlerle ilgilenmesine olanak tanıyorsunuz. Ancak bazen bu araçları kör olarak takip ettiğimizde, AI’nın dikkate alamadığı trade-off’lar vardır.

Bu durumda, insan görüşü karar verici olur.

Hedeflerle Teknik Borcu Bağdaştırmak

Teknik borcu azaltmayı nasıl hedeflerle veya ölçülebilir sonuçlarla bağdaştırabilirsiniz? Kabul edilebilir teknik borca geri dönmektedir ve bazen iş dünyasında hızlı sevkiyat gerekir. Bir ürünün ölçeklenmediğini ve zamanla performans sorunları olabileceğini bilerek bunu yapabilirsiniz. Genellikle, bir geliştirici daha sonra bu sorunlara geri döneceğini not eder, ancak bu nadiren gerçekleşir. Ve bu kötü kültür, sürekli ertesi gün sevkiyat yapmanız gerektiğini düşünerek, teknik borcun etkisini açıkça ortaya koyar.

Bu, bir startup için anlaşılabilir, ancak on yıldan uzun süredir faaliyet gösteren bir iş için değil. Teknik borcu yönetmek için kültürünüzü erken ve aktif olarak değiştirmeye başlamalısınız; aksi takdirde, üretim hatalarını düzeltmek veya güvenlik ve uyumluluk konusunda endişe etmek için çok para harcayacaksınız.

Son olarak, teknik borcu azaltmanın veya teknik borcu ödemmenin değerini paydaşlara iletmeye yardımcı olacak metrikler vardır. Zaman, başlangıçtan üretime veya bir çekme isteğinin açılmasından üretimine kadar olabilir. Başka bir metrik, ortalama onarım süresi (MTTR) olabilir. Bu durumda, bir hatayı veya bozulan bir yapıyı bulmuş olabilir ve ekibinizin bunu düzeltmesi ne kadar sürdüğünü ölçebilirsiniz. Ayrıca, üretimdeki hata sayısını da izleyebilirsiniz. Eğer bu sayının arttığını görürseniz, teknik borcu ile ilgili bir sorun olabilir.

Technik Borcu ile Faiz

Her organizasyon, teknik borcu azaltmaya yardımcı olmak için her hafta birkaç saat ayırabilir. Eğer bunu yapmazsanız, muhtemelen daha sonra yavaş performans, önemli bir gelişim hızı düşüşü veya güvenlik sorunları ile ödemek zorunda kalırsınız. Örneğin, mühendis ve geliştirici ekibiniz, Ruby on Rails’i on yıl boyunca erteleme kararı alabilir. Aniden, bir proje maliyeti yarı milyon dolar artar, çünkü Ruby sürümü dört nesil geridedir ve eski bağımlılıklarla birlikte bir kod yığını bırakır.

Eğer yavaş yavaş güncelleme yapmış olsaydınız, bu durumda olmayacaktınız. Bu nedenle, yazılım geliştirme ekibinizi destekleyin ve ödemeyi yapın. Aksi takdirde, teknik borcu faiz ile geri dönecektir.