技術的負債: 私のRustライブラリ、いまやCDOに転換

技術的負債: 私のRustライブラリはいまやCDOになった

• 技術的負債に関するジョークとして、技術的負債があるなら、その負債を扱うためのデリバティブ商品もあるはずだ、というものがある。
• Rustエコシステムは、技術的負債を証券化しているかのように見える解決策を生み出した。
• たとえば、あるライブラリ stuff が別のライブラリ learned-rust-this-way に依存しているが、learned-rust-this-way の作者が興味を失い、問題が積み上がり始める。

技術的負債の実体

• learned-rust-this-way は技術的負債と見なされるが、これは直接的な問題を引き起こさない一方で、それでもなお負債である。
• ある時点で誰かが learned-rust-this-way が負債だと気づき、元の作者に連絡がつかないまま RUSTSEC データベースに追加される。
• RUSTSEC は格付け機関としてその負債をジャンクと評価し、その結果、多くの人の CI（継続的インテグレーション）が失敗し始める。

負債を解決する方法

• stuff のメンテナーとして、ユーザーが learned-rust-this-way の使用について問題を提起するたびにストレスが増し、負債に対処するための行動を求められる。
• 代替へ移行するのも一つの選択肢だが、このケースではどの代替も魅力的ではない。
• learned-rust-this-way をフォークしても同じ要求に直面することになり、それは一時しのぎの解決策にすぎず、問題そのものは解決しない。

実際に効果のある解決策

• 自分のライブラリにそのコードをマージすると、そのジャンクな技術的負債は突然「AAA」格付けになる。
• そのコードにはもう手を加えず、マージした事実を隠し、以前と同じようにライブラリをメンテナンスしていれば、世界は回り続ける。
• yaml-rust を insta にベンダーとして取り込みマージすることで、insta のコードと yaml-rust の結合体となり、これによって技術的負債を AAA 格付けへとアップグレードした。

GN⁺の見解

• この記事は技術的負債を金融デリバティブにたとえ、ソフトウェア開発で生じる問題を機知に富んだ形で説明している。
• 技術的負債はソフトウェア開発でよく直面する問題であり、この記事は開発者に負債を管理する創造的な方法を提示している。
• Rustエコシステムの RUSTSEC のような格付けシステムは、開発者がライブラリの安定性を評価する助けになる一方で、不要なストレスを引き起こすこともある。
• 技術的負債を解決する手段としてコードをマージすることは一時的な解決策かもしれず、長期的には持続可能なメンテナンス戦略が必要である。
• このような状況では、コミュニティ主導の保守、オープンソースプロジェクトの共同メンテナンス、あるいはライブラリの代替版を探すことなど、さまざまな解決策を検討する必要がある。

[GN⁺]

Hacker Newsの意見

• 最も人気のある YAML パーサーの作者が突然プロジェクトを放棄し、非推奨（deprecated）かつメンテナンスされていない（unmaintained）と表示した。警告や他のメンテナーの指名もなく行われたことで、パッケージは依然として機能するものの、4000 以上の他のクレートで使われているため、監査や自動更新ツールはメンテナンスされていないクレートの利用について警告を出すことになる。
• CDO という略語に戸惑った人のために言うと、これは "collateralized debt obligation" を意味するのだろう。"collateralized" という単語が何度も使われていたからだ。
• コード内の脆弱な経路が外部ライブラリから実行またはアクセスできないのであれば、それは安全なコード経路になる。ライブラリを取り込む（vendoring）ことはコードを攻撃するためのツールを提供し、自前のライブラリに対するテストカバレッジが十分であれば、取り込んだライブラリに対してコードカバレッジツールを実行できる。取り込んだライブラリを変更するのは難しいかもしれないが、不要な部分を削除するのは比較的簡単かもしれない。もちろん、取り込んだライブラリの構造による。
• 元クオンツアナリストで現在は経済学者だという人物は、作者が "Collateralized Debt Obligation" という用語を正しく使ったことを称賛している。自身は「技術的負債」について記事を書きたいが、「負債」という比喩はその概念に合っていないと考えている。「高粘性コード」という表現の方がよいかもしれない。コードを新機能に合わせて簡単に変更できず、まるで高い誘導性を持っているかのように感じられるからだ。
• "junk tech debt" が突然 "AAA" 格付けになることについて、投稿者は、コードは取り込まれる（vendoring）前後で同じコードなのだから、より良い負債格付けを持てるはずがないと言いたいようだ。しかしこれはコード自体の価値しか見ておらず、全体の価値提案の最も重要な部分を見落としている。コードを取り込んだメンテナーはそのコードを所有するようになり、死んだプロジェクトからコードを取り込んだアクティブなメンテナーは、課題に対応し、プルリクエストをレビューし、バグを修正できる人間がいるという点で、そのコードの価値を高める。
• JS の npm エコシステムでも同じパターンを見たことがある。npm audit は主にセキュリティ問題について大げさに警告し、ライセンスが許す限り、ユーザーから寄せられるばかげた問題から逃れる最も確実な方法の一つでもある。
• yaml-rust をフォークして純粋な Rust で書き直し、yaml-rust2 を作れたのは幸運だった。このフォークは YAML テストスイートを完全に通過し、ベンチマークでもより良い性能を示している。移行も簡単そうだ。結局のところ問題は依然として残っており、私たちは今も無償で労働を提供している他人に依存しているが、彼らが永遠にそうしてくれる保証はない。
• ソースベースのパッケージマネージャーが、レジストリに公開されたパッケージのメンテナンスを法的権利として強制的に引き継げないなら、恐ろしい問題に直面することになる。放置、悪意ある変更、悪意ある削除、なりすましなどだ。コミュニティにとって十分重要だと判断されるパッケージについては、元の所有者の手からレジストリエントリを取り上げてフォークに切り替える方法が必要だ。
• コードが動作していて何年もそうだったのなら、メンテナンスされていないことの何が問題なのだろうか。修正する必要がなく、その限界と能力を理解しているなら問題はない。コードはひとりでに悪くなったりしない。何十年も前のコードを何度も取り込んだり統合したりすることに何の問題もなかった。
• 依存関係を取り込むこと（vendoring）が解決策だ。20 年にわたって、「完成」して開発と保守が遅くなったほぼすべての依存関係についてこれを行ってきた。