"Küçük bir buton ekletmek istedik, yazılımcımız iki hafta sürer dedi." Bu cümleyi duyduğumuzda teşhis genelde hazırdır: teknik borç faizi ödüyorsunuz. Teknik borç, hızlı gitmek için bugün alınan kısayolların yarın ödenen bedelidir ve tıpkı finansal borç gibi, yönetilmezse faizi anaparayı geçer. Bu yazıda borcun belirtilerini, nereden doğduğunu, nasıl ölçüldüğünü ve makul bir ödeme planının nasıl kurulduğunu yönetici gözüyle ele alıyoruz.
Teknik borcun belirtileri
Yöneticiyseniz kod göremezsiniz ama belirtileri görebilirsiniz:
- Basit değişikliklerin süresi ay geçtikçe uzuyor; eskiden bir günlük iş artık bir hafta.
- Her yeni özellik, alakasız görünen eski bir özelliği bozuyor.
- Ekip "ona dokunmayalım, çalışıyor" dediği kara kutu modüller biriktiriyor.
- Yeni geliştirici işe alıyorsunuz, verimli hale gelmesi aylar alıyor.
- Sürüm çıkmak korku dolu bir tören: gece yarısı, herkes tetikte, geri dönüş planı elde.
Borcu ölçmeden yönetemezsiniz
16 yılda onlarca proje devraldık ve ilk işimiz hep aynı: envanter ve ölçüm. Statik analiz araçlarıyla (PHP tarafında PHPStan, kod stili ve karmaşıklık metrikleri) kodun fotoğrafını çekiyoruz: hangi modüller ne kadar karmaşık, test kapsamı nerede sıfır, hangi bağımlılıklar kaç yıl geride. Sonra bu teknik fotoğrafı iş tarafıyla birleştiriyoruz: en çok değişiklik alan modül hangisi? Çünkü borcun maliyeti, borcun büyüklüğü çarpı o koda dokunma sıklığıdır. Kimsenin dokunmadığı çirkin kod ucuzdur; her hafta dokunulan orta karar kod pahalıdır.
Borç nereden doğar?
Teknik borcun tek kaynağı "kötü yazılmış kod" değildir; en az üç kaynağı daha var. Birincisi bilinçli ticari kararlar: fuara yetişmek için alınan kısayol o gün doğru karardı, sorun geri dönülüp ödenmemesinde. İkincisi bilgi eksikliği: ekip o gün daha iyisini bilmiyordu; yazılımcılık öğrenilen bir zanaat ve dünkü "en iyi pratik" bugün anti-pattern olabiliyor. Üçüncüsü çevresel eskime: siz hiçbir şey yapmasanız bile bağımlılıklarınız eskir, framework sürümleri kapanır, güvenlik yamaları kesilir; kod aynı kalırken borç kendiliğinden büyür. Bu ayrım pratik olarak önemli, çünkü tedavileri farklı: birincisi süreç disipliniyle, ikincisi eğitim ve kod incelemesiyle, üçüncüsü düzenli bağımlılık güncelleme rutiniyle yönetilir. Suçlu aramak yerine kaynak teşhisi yapmak, hem ekip motivasyonunu korur hem doğru yatırımı gösterir.
Ödeme stratejisi: büyük patlama değil, taksit
"Her şeyi sıfırdan yazalım" cazip gelir ve çoğu zaman felakettir; çalışan işi durdurur, iki yıl sonra aynı borçla yeni bir sistem doğar. Bizim önerimiz taksitli ödeme: her sprint kapasitesinin belli bir yüzdesi (genelde %15-20) borç azaltmaya ayrılır. Öncelik sırası da nettir: önce güvenlik riski taşıyan borçlar, sonra en sık dokunulan modüller, sonra geliştirici verimliliğini en çok yiyen alanlar. Strangler fig deseniyle eski modülleri tek tek modern yapıya taşımak, big bang yeniden yazımdan neredeyse her zaman daha güvenlidir.
Karar vericiye özet
Teknik borç bir yazılımcı kaprisi değil, bilanço kalemidir. Görmezden gelirseniz yok olmaz; teslim sürelerinize, personel devir hızınıza ve müşteri memnuniyetinize fatura edilir. Rich Design olarak mevcut yazılımınız için bağımsız teknik borç analizi yapıyor; yönetim diliyle yazılmış, önceliklendirilmiş bir yol haritası teslim ediyoruz. Yazılımınızın gerçek durumunu merak ediyorsanız bir analiz görüşmesi planlayalım.