Teknik borç: Rust kütüphanem artık bir CDO'ya dönüştü

Teknik borç: Rust kütüphanem artık bir CDO'ya dönüştü

• Teknik borçla ilgili bir şaka vardır: ortada teknik borç varsa, o borçla ilgilenmek için türev ürünler de olmalıdır.
• Rust ekosistemi, teknik borcu menkul kıymetleştiriyormuş gibi görünen bir çözüm üretir.
• Örneğin bir stuff kütüphanesi başka bir learned-rust-this-way kütüphanesine bağımlıdır; ancak learned-rust-this-way yazarının ilgisi kaybolur ve sorunlar birikmeye başlar.

Teknik borcun gerçekte ne olduğu

• learned-rust-this-way teknik borç olarak kabul edilir; bu, doğrudan bir soruna yol açmasa da yine de bir borçtur.
• Bir noktada biri learned-rust-this-way'in bir borç olduğunu fark eder, asıl yazara ulaşılamaz ve paket RUSTSEC veritabanına eklenir.
• Değerlendirme kurumu gibi çalışan RUSTSEC, bu borcu çöp olarak derecelendirir ve bunun sonucunda pek çok kişinin CI'ı (sürekli entegrasyon) başarısız olmaya başlar.

Borç nasıl ele alınır

• stuff'ın bakımcısı olarak, kullanıcılar learned-rust-this-way kullanımına dair sorun çıkardıkça stres artar ve sizden borçla ilgili bir adım atmanız istenir.
• Başka bir alternatife geçmek bir seçenektir, ancak bu durumda mevcut alternatiflerin hiçbiri cazip değildir.
• learned-rust-this-way'i fork etmek de aynı taleplerle karşı karşıya kalmak demektir; bu yalnızca geçici bir çözümdür ve sorunu çözmez.

Gerçekten işe yarayan çözüm

• İlgili kodu kendi kütüphanenize birleştirirseniz, o çöp teknik borç bir anda AAA notuyla derecelendirilir.
• Koda artık dokunmaz, birleştirdiğinizi gizler ve kütüphaneyi eskisi gibi bakımda tutarsanız dünya dönmeye devam eder.
• yaml-rust, insta içine vendor edilip birleştirilmiştir; böylece insta kodu ile yaml-rust'ın bir bileşimi ortaya çıkmış ve teknik borç AAA seviyesine yükseltilmiştir.

GN⁺ görüşü

• Bu yazı, teknik borcu finansal türev ürünlere benzeterek yazılım geliştirmede ortaya çıkan sorunları zekice anlatıyor.
• Teknik borç, yazılım geliştirmede sık karşılaşılan bir sorundur ve bu yazı geliştiricilere borcu yönetmek için yaratıcı bir yöntem sunuyor.
• Rust ekosistemindeki RUSTSEC gibi derecelendirme sistemleri, geliştiricilerin kütüphane kararlılığını değerlendirmesine yardımcı olabilir; ancak aynı zamanda gereksiz strese de yol açabilir.
• Kodu birleştirerek teknik borcu çözmek geçici bir çözüm olabilir; uzun vadede sürdürülebilir bir bakım stratejisi gerekir.
• Böyle durumlarda topluluk odaklı bakım, açık kaynak projelerde ortak bakım veya kütüphanenin alternatif sürümlerini aramak gibi çeşitli çözümler değerlendirilmelidir.

[GN⁺]

Hacker News görüşleri

• En popüler YAML ayrıştırıcısının yazarı projeyi aniden bıraktı ve onu kullanılmaması önerilen (deprecated) ve artık bakımı yapılmayan (unmaintained) olarak işaretledi. Bu, herhangi bir uyarı veya başka bir bakımcı ataması olmadan gerçekleşti; paket hâlâ çalışıyor, ancak 4000'den fazla başka crate tarafından kullanıldığı için denetim ve otomatik güncelleme araçları, bakımı yapılmayan crate kullanımına karşı uyarı verecek.
• CDO kısaltmasını kafa karıştırıcı bulanlar için bunun collateralized debt obligation anlamına geldiği tahmin ediliyor. Çünkü collateralized kelimesi birkaç kez kullanılmış.
• Eğer kodun zafiyet içeren yolu dış kütüphaneler tarafından çalıştırılamıyor veya erişilemiyorsa, bu güvenli bir kod yolu olur. Bir kütüphaneyi içe almak (vendoring) koda saldırmak için araçlar sağlar ve kendi kütüphaneniz için yeterli test kapsamınız varsa, içe alınan kütüphane üzerinde de kod kapsamı araçlarını çalıştırabilirsiniz. İçe alınan kütüphaneyi değiştirmek zor olabilir, ancak ihtiyaç duyulmayan kısımları silmek nispeten daha kolay olabilir. Elbette bu, içe alınan kütüphanenin yapısına bağlıdır.
• Eski bir nicel analist ve şu anda ekonomist olan bir yorumcu, yazarın Collateralized Debt Obligation terimini doğru kullandığını övdü. Teknik borç hakkında bir yazı yazmak istiyor, ancak borç benzetmesinin bu kavrama uygun olmadığını düşünüyor. Yüksek viskoziteli kod ifadesi daha iyi olabilir. Kod, yeni özelliklere uyacak şekilde kolayca değiştirilemediği için sanki yüksek endüktansa sahipmiş gibi hissettiriyor.
• junk tech debtin aniden AAA notu alması konusunda, yorumcu bunun, kodun içe alınmadan (vendoring) önce ve sonra aynı kodun daha iyi bir borç derecesine sahip olamayacağı anlamına geldiğini düşündüğünü söylüyor. Ancak bu, yalnızca kodun kendi değerine bakıyor ve toplam değer önerisinin en önemli kısmını kaçırıyor. Kodu içe alan bakımcı artık o kodun sahibi olur; ölü bir projeden kodu içe alan aktif bir bakımcı, sorunlara yanıt verebilen, pull request'leri inceleyebilen ve hataları düzeltebilen bir insan olduğu için kodun değerini artırır.
• Aynı örüntü JS npm ekosisteminde de görüldü. Npm audit çoğunlukla güvenlik sorunları konusunda abartılı uyarılar veriyor ve lisans izin verdiği sürece, kullanıcılardan gelen saçma sorunlardan kurtulmanın en güvenilir yollarından biri bu.
• yaml-rust'ı fork edip saf Rust ile yeniden yazarak yaml-rust2'yi oluşturmuş olmak şanslıydı. Bu fork, YAML test paketini tamamen geçiyor ve benchmark'larda da daha iyi performans gösteriyor. Geçiş de basit görünüyor. Sonuçta sorun hâlâ ortada: şu anda bize ücretsiz emek sağlayan başkalarına bağımlıyız, ama bunun sonsuza dek süreceğinin garantisi yok.
• Kaynak tabanlı bir paket yöneticisi, kayıt defterinin yayımlanmış paketlerin bakımını zorla devralmasına ilişkin yasal hakkı dayatamıyorsa korkunç sorunlarla karşılaşacaktır: terk edilme, kötü niyetli değişiklikler, kötü niyetli kaldırmalar, kimliğe bürünme vb. Topluluk için yeterince önemli görülen paketlerde, kayıt defteri girdisini asıl sahibinin elinden alıp bir fork ile değiştirebilmenin bir yolu olmalı.
• Kod çalışıyorsa ve yıllardır da böyleyse, bakımı yapılmıyor olmasının ne önemi var? Düzeltilmesi gerekmiyorsa ve sınırlarını ile yeteneklerini biliyorsanız sorun değildir. Kod kendi kendine kötüleşmez. On yıllar önceki kodu tekrar tekrar kopyalayıp kullanmakta veya entegre etmekte hiçbir sorun yoktu.
• Bağımlılıkları içe almak (vendoring) çözüm. 20 yıldır tamamlanmış olup geliştirilmesi ve bakımı yavaşlamış neredeyse tüm bağımlılıklar için bunu yapıyorum.