Teknik borçlara giriş
Teknik borç , tamamlanması daha uzun sürecek daha iyi uygulamalar kullanmak yerine bugün kolay bir çözüm seçmekten gelecek maliyeti açıklayan bir terimdir.
"Teknik borç" terimi, mali borçlara benzer olduğu için seçilmiştir. Mali borcu olan kişilerin o zaman doğru veya tek seçenek gibi görünen kararlar almaları yaygındır, ancak bunu yaparak faiz artar.
Ne kadar çok ilgi artarsa, gelecekte onlar için o kadar zorlaşır ve daha sonra sahip oldukları seçenekler o kadar az olur. Finansal borçla, kısa süre içinde faiz üzerine faiz artar ve kartopu etkisi yaratır. Benzer şekilde, teknik borç, geliştiricilerin neredeyse tüm zamanlarını değer katmak yerine planlı veya plansız olarak sorunları çözmek ve yeniden çalışma yapmak için harcadıkları noktaya kadar gelebilir.
Peki, nasıl oluyor?
En yaygın bahane sıkı teslim tarihleridir. Geliştiriciler hızlı bir şekilde kod oluşturmaya zorlandığında genellikle kısayollar alır. Örneğin, bir yöntemi yeni işlevler içerecek şekilde yeniden düzenlemek yerine yeni bir sürüm oluşturmak üzere kopyalayabilirler. Ardından yalnızca yeni kodu test ederler ve kodun diğer bölümleri onu kullandığından, özgün yöntemi değiştirirlerse gereken test düzeyini azaltabilirler.
Artık aynı kodun bir kopya yerine gelecekte değiştirilmesi gereken iki kopyasına sahipler ve mantığın farklı olma riskiyle karşılaşıyorlar. Birçok nedeni vardır. Örneğin, geliştiriciler arasında teknik beceri ve olgunluk eksikliği olabilir ya da net bir ürün sahipliği veya yönü olmayabilir.
Kuruluşun kodlama standartları olmayabilir, bu nedenle geliştiriciler ne üretmeleri gerektiğini bile bilmiyordu. Geliştiricilerin hedeflemek için net gereksinimleri olmayabilir veya son dakika gereksinimleri değişikliklerine tabi olabilir.
Gerekli yeniden düzenleme çalışmaları gecikebilir. El ile veya otomatik kod kalitesi testi olmayabilir. Sonuç olarak, makul bir zaman diliminde ve makul bir maliyetle müşterilere değer sunmak daha da zorlaşıyor.
Teknik borç, projelerin son tarihlerini karşılayamamasının başlıca nedenlerinden biridir.
Zamanla parasal borcun arttığı gibi artar. Teknik borcun ortak kaynakları şunlardır:
- Kodlama stili ve standartları eksikliği
- Birim testi çalışmalarının tasarım eksikliği veya zayıflığı
- Nesne odaklı tasarım ilkelerini yoksayma veya anlamama
- Monolitik sınıflar ve kod kitaplıkları
- Kötü planlanmış teknoloji, mimari ve yaklaşım kullanımı (bakımı, kullanıcı deneyimini, ölçeklenebilirliği ve diğerlerini etkileyen tüm sistem özniteliklerinin dikkate alınması gerektiğini unutmak)
- Fazla mühendislik kodu (gerekli olmayan kod ekleme veya oluşturma, mevcut kitaplıklar yeterli olduğunda özel kod ekleme veya gerekli olmayan katmanlar veya bileşenler oluşturma)
- Yetersiz açıklamalar ve belgeler
- Kendi kendine belgeleyen kod yazmıyor (açıklayıcı veya amacı gösteren sınıf, yöntem ve değişken adları dahil)
- Son tarihleri karşılamak için kısayolları alma
- Ölü kodu bulunduğu yerde bırakmak
Not
Zamanla teknik borcun geri ödenmesi gerekir. Aksi takdirde, ekibin sorunları çözme ve yeni özellik ve geliştirmeleri uygulama becerisi daha uzun sürer ve sonunda maliyet engelleyici hale gelir.
Teknik borcun geliştirme sırasında sorunlar kattığını ve ekstra müşteri değeri eklemeyi çok daha zor hale getirdiğini gördük.
Bir projede teknik borcun olması üretkenliği azaltır, geliştirme ekiplerini rahatsız eder, kodu hem anlaşılmasını zorlaştırır hem de kırılgan hale getirir, değişiklik yapma süresini artırır ve bu değişiklikleri doğrular. Plansız çalışma genellikle planlı çalışmanın yoluna çıkar.
Daha uzun vadede kuruluşun gücünü de zayıflatır. Teknik borçlar, bir kuruluşta ansızın artma eğilimindedir. Küçük başlar ve zamanla büyür. Değişikliklerin aceleye getirilmesi gerektiğinden her hızlı hack yapıldığında veya test atlandığında, sorun daha da kötüleşir. Destek maliyetleri daha yüksek ve daha yüksek olur ve sonunda ciddi bir sorun ortaya çıkar.
Sonunda kuruluş, müşterilerinin ihtiyaçlarına zamanında ve uygun maliyetli bir şekilde yanıt veremiyor.
İzleme için otomatik ölçüm
Teknik borcun sürekli birikme şeklini en aza indirmenin temel yollarından biri otomatik test ve değerlendirme kullanmaktır.
Ardından gelen tanıtımlarda, borcu değerlendirmek için kullanılan yaygın araçlardan birine göz atacağız: SonarCloud. (Özgün şirket içi sürümü SonarQube'dı).
Kullanabileceğiniz başka araçlar da var ve bunlardan birkaçını ele alacağız.
Daha sonra, sonraki uygulamalı laboratuvarda Azure Pipelines'ınızı SonarCloud kullanacak şekilde yapılandırmayı, analiz sonuçlarını anlamayı ve son olarak projelerinizi analiz ederken SonarCloud tarafından kullanılan kural kümelerini denetlemek için kalite profillerini yapılandırmayı öğreneceksiniz.
Daha fazla bilgi için bkz . SonarCloud.
Gözden geçirmek için:
Azure DevOps, derlemeler sırasında kod kalitesini denetlemek için kullanılan çok çeşitli mevcut araçlarla tümleştirilebilir.
Şu anda hangi kod kalitesi araçlarını (varsa) kullanıyorsunuz?
Araçlar hakkında neleri beğendiniz veya beğenmediniz?