Utang teknis: library Rust saya sekarang berubah menjadi CDO

Utang teknis: library Rust saya sekarang menjadi CDO

• Sebagai lelucon tentang utang teknis, ada candaan bahwa jika ada utang teknis, seharusnya juga ada derivatif untuk menangani utang tersebut.
• Ekosistem Rust tampaknya telah menghasilkan solusi yang terlihat seperti sekuritisasi utang teknis.
• Misalnya, sebuah library stuff bergantung pada library lain learned-rust-this-way, tetapi penulis learned-rust-this-way kehilangan minat dan masalah mulai menumpuk.

Wujud nyata utang teknis

• learned-rust-this-way dianggap sebagai utang teknis; ini tidak langsung menimbulkan masalah, tetapi tetap saja merupakan utang.
• Pada suatu titik, seseorang menyadari bahwa learned-rust-this-way adalah utang, dan karena penulis aslinya tidak dapat dihubungi, library itu ditambahkan ke basis data RUSTSEC.
• Sebagai lembaga pemeringkat, RUSTSEC menilai utang tersebut sebagai sampah, dan akibatnya CI (continuous integration) banyak orang mulai gagal.

Cara menangani utang

• Sebagai maintainer stuff, tingkat stres meningkat ketika pengguna mulai mengangkat masalah tentang penggunaan learned-rust-this-way, dan Anda dituntut mengambil tindakan untuk menangani utang itu.
• Berpindah ke alternatif adalah salah satu opsi, tetapi dalam kasus ini semua alternatifnya tidak menarik.
• Mem-fork learned-rust-this-way akan membuat Anda menghadapi tuntutan yang sama; itu hanya solusi sementara dan tidak benar-benar menyelesaikan masalah.

Solusi yang benar-benar berhasil

• Jika Anda menggabungkan kode tersebut ke library Anda sendiri, maka utang teknis sampah itu tiba-tiba dinilai berperingkat 'AAA'.
• Anda tidak lagi menyentuh kodenya, menyembunyikan fakta bahwa itu telah digabungkan, dan tetap memelihara library seperti sebelumnya, maka dunia terus berjalan.
• Dengan me-vendor dan menggabungkan yaml-rust ke dalam insta, hasilnya menjadi gabungan kode insta dan yaml-rust, dan dengan itu utang teknis berhasil di-upgrade ke peringkat AAA.

Pendapat GN⁺

• Artikel ini dengan cerdas menjelaskan masalah yang muncul dalam pengembangan perangkat lunak dengan menganalogikan utang teknis sebagai derivatif finansial.
• Utang teknis adalah masalah yang sering ditemui dalam pengembangan perangkat lunak, dan artikel ini menunjukkan cara kreatif bagi para pengembang untuk mengelolanya.
• Sistem pemeringkatan seperti RUSTSEC di ekosistem Rust dapat membantu pengembang menilai stabilitas library, tetapi pada saat yang sama juga dapat menimbulkan stres yang tidak perlu.
• Menggabungkan kode sebagai cara menyelesaikan utang teknis bisa menjadi solusi sementara, dan dalam jangka panjang tetap dibutuhkan strategi pemeliharaan yang berkelanjutan.
• Dalam situasi seperti ini, berbagai solusi patut dipertimbangkan, seperti pemeliharaan berbasis komunitas, co-maintenance pada proyek open source, atau mencari versi pengganti dari library tersebut.

[GN⁺]

Komentar Hacker News

• Penulis parser YAML yang paling populer tiba-tiba meninggalkan proyek tersebut, lalu menandainya sebagai deprecated dan unmaintained. Ini dilakukan tanpa peringatan atau penunjukan maintainer lain, dan meskipun paketnya masih berfungsi, paket itu digunakan oleh lebih dari 4000 crate lain, sehingga alat audit dan pembaruan otomatis akan memperingatkan penggunaan crate yang tidak dipelihara.
• Bagi orang-orang yang bingung dengan singkatan CDO, ada dugaan bahwa itu berarti 'collateralized debt obligation'. Alasannya karena kata 'collateralized' digunakan beberapa kali.
• Jika jalur kode yang rentan tidak bisa dijalankan atau diakses dari library eksternal, maka itu menjadi jalur kode yang aman. Melakukan vendoring pada library memberi alat untuk menyerang kode, dan jika cakupan pengujian untuk library sendiri sudah memadai, kita bisa menjalankan alat code coverage pada library yang di-vendor. Memodifikasi library yang di-vendor bisa jadi menantang, tetapi menghapus bagian yang tidak diperlukan bisa relatif mudah. Tentu saja, itu tergantung pada struktur library yang di-vendor.
• Seorang mantan analis kuantitatif yang kini menjadi ekonom memuji penulis karena menggunakan istilah 'Collateralized Debt Obligation' dengan tepat. Ia ingin menulis artikel tentang 'utang teknis', tetapi merasa metafora 'utang' tidak cocok untuk konsep itu. Istilah seperti 'kode viskositas tinggi' mungkin lebih tepat. Kode terasa seolah memiliki induktansi tinggi karena tidak bisa dengan mudah diubah agar sesuai dengan fitur baru.
• Mengenai 'junk tech debt' yang tiba-tiba dinilai berperingkat 'AAA', penulis tampaknya bermaksud bahwa kode yang sama tidak mungkin memiliki peringkat utang yang lebih baik sebelum dan sesudah di-vendor. Namun ini hanya melihat nilai kode itu sendiri, dan melewatkan bagian terpenting dari proposisi nilai secara keseluruhan. Maintainer yang melakukan vendoring kini memiliki kode itu, dan maintainer aktif yang mengambil kode dari proyek mati meningkatkan nilainya karena ada manusia yang bisa merespons issue, meninjau pull request, dan memperbaiki bug.
• Pola yang sama juga terlihat di ekosistem JS npm. Npm audit cenderung memberi peringatan berlebihan terutama untuk masalah keamanan, dan selama lisensinya mengizinkan, ini adalah salah satu cara paling andal untuk lepas dari masalah-masalah tidak masuk akal yang diterima dari pengguna.
• Untungnya, seseorang mem-fork yaml-rust dan menulis ulang dalam Rust murni sehingga menjadi yaml-rust2. Fork ini lulus seluruh YAML test suite dan juga menunjukkan performa yang lebih baik dalam benchmark. Migrasinya juga tampak sederhana. Pada akhirnya, masalah dasarnya tetap ada: kita masih bergantung pada orang lain yang saat ini memberi tenaga kerja gratis, tetapi tidak ada jaminan mereka akan terus melakukannya selamanya.
• Jika package manager berbasis source tidak memaksakan hak hukum bagi registry untuk mengambil alih pemeliharaan paket yang telah diterbitkan, maka akan muncul masalah-masalah mengerikan: penelantaran, perubahan jahat, penghapusan jahat, peniruan identitas, dan sebagainya. Untuk paket yang dianggap cukup penting bagi komunitas, perlu ada cara untuk merebut entri registry dari tangan pemilik aslinya dan mengalihkannya ke sebuah fork.
• Jika kode berfungsi dan sudah begitu selama bertahun-tahun, mengapa harus peduli jika tidak dipelihara? Jika tidak perlu diperbaiki dan kita tahu batasan serta kemampuannya, itu bukan masalah. Kode tidak memburuk dengan sendirinya. Dulu tidak ada masalah sama sekali untuk meminjam atau mengintegrasikan kode yang berumur puluhan tahun berkali-kali.
• Melakukan vendoring pada dependensi adalah solusinya. Selama 20 tahun, ini dilakukan untuk hampir semua dependensi yang sudah 'selesai' dan yang pengembangan maupun pemeliharaannya melambat.