- Teknik borç kavramı
- Daha uzun sürebilecek daha iyi bir yaklaşımı benimsemek yerine kolay ama sınırlı bir çözüm seçildiğinde ortaya çıkan, gelecekteki yeniden çalışma için örtük maliyet
- En etkili çözüm yerine en hızlı çözüm seçildiğinde oluşan ek iş maliyeti
- Yazılım mühendisi Martin Fowler’ın ayırdığı teknik borç türleri
- Temkinli ve kasıtlı teknik borç (Prudent & Deliberate)
- Ekip borçlandığını bilir, ancak “daha hızlı yayınlamanın getirisi borcu ödeme maliyetinden daha büyük mü?” sorusunu değerlendirir
- Temkinsiz ve kasıtlı teknik borç (Reckless & Deliberate)
- İyi tasarım pratiklerini bilir ve uygulayabilirler, ancak temiz kod yazacak zaman olmadığı için “hızlı ve dağınık” ilerlemeyi seçmenin sonucu
- Temkinli ama kasıtsız teknik borç (Prudent & Inadvertent)
- İyi bir yazılım geliştirilmiş ve kod da temizdir, ancak ancak zaman geçtikten sonra “tasarımın nasıl olması gerektiği” fark edilir
- Temkinsiz ve kasıtsız teknik borç (Reckless & Inadvertent)
- Yeterince bilinmediği için ortaya çıkan sonuç
- Teknik borcu çözme yolları
- Teknik borç listesini yönetmek
- Projeyi geriye dönük değerlendirip teknik borçları listeleyin ve paylaşın
- Teknik borç her ortaya çıktığında, bu borcu çözmek için gereken işi tahmini efor ve takvimle birlikte kaydedin
- Ekip içinde teknik borcun çözülüp çözülmeyeceğini ve ne zaman çözüleceğini tartışın, çözüm planı oluşturun
- İyi teknik borç ile kötü teknik borcu ayırmak
- Teknik borcu bu şekilde sınıflandırmak, en büyük sorunların önceliğini belirlemeye yardımcı olur
- Refactoring
- İş yürütülürken gerekli bölümleri düzenleyin, adım adım refactoring yapın
- Büyük ölçekli refactoring sırasında durumu ekiple paylaşın, teknik borcun riskini ve maliyetini bildirin
- Test kodu yazmak
- Kod ne kadar karmaşıksa ve refactoring ne kadar büyükse, kodu tek seferde hatasız değiştirmek o kadar zor olur
- Yan etkileri önlemek için test kodu yazın
- Kalite standartlarını belirlemek ve bunlara uymak
- Kalite standartları belirleyerek geliştiricilerin özensiz kod dağıtmasını engelleyin
- Ani kural veya takvim değişikliği yapmamak
- Geliştiricilerle ilgili kuralların sürekli değiştirilmesi ve teslim tarihlerinin kaydırılması teknik borçtan kaçınmayı zorlaştırır
- Teknik borcu yönetebilmek için gerçekçi takvim, metodoloji ve iş yükü sağlayın
- Teknik borç her zaman kötü müdür?
- Chris Riccomini ve Dmitriy Ryaboy’un 『Mutlaka Okuyun! Geliştirici Onboarding Rehberi: Sürdürülebilir yazılımı ve akıcı iş birliği kültürünü anlayan profesyonel geliştiricinin doğuşu』 adlı kitabından: “Eğer ekip daha sonra bunu çözebilecek şekilde eğitilmişse, bu bir ‘iyi borç’ sayılabilir”
- Ancak teknik borç iş üzerinde olumsuz etki yaratabileceği için çözülmelidir
- Bu durum hata olarak ortaya çıkar ve kullanıcı deneyimini düşürür
- Teknik borç ağırlaştıkça, geliştiricilerin mevcut kod tabanı içinde çalışması daha zor hale gelir
- Yeni özellik geliştirme ve mevcut özellikleri düzeltme arasında zaman bölünür; bunun sonucu olarak yazılım geliştirme yaşam döngüsü yavaşlar ve pazara çıkış tarihi gecikir
Henüz yorum yok.