Nợ kỹ thuật: thư viện Rust của tôi giờ đã chuyển thành CDO

Nợ kỹ thuật: thư viện Rust của tôi giờ đã trở thành CDO

• Có một câu đùa về nợ kỹ thuật rằng nếu đã có nợ kỹ thuật thì cũng nên có các công cụ phái sinh để xử lý khoản nợ đó.
• Hệ sinh thái Rust đã tạo ra một giải pháp trông như thể đang chứng khoán hóa nợ kỹ thuật.
• Ví dụ, một thư viện stuff phụ thuộc vào một thư viện khác là learned-rust-this-way, nhưng tác giả của learned-rust-this-way đã mất hứng thú và các vấn đề bắt đầu chất đống.

Bản chất của nợ kỹ thuật

• learned-rust-this-way được xem là nợ kỹ thuật; bản thân nó không gây ra vấn đề trực tiếp, nhưng dù vậy vẫn là một khoản nợ.
• Đến một thời điểm nào đó, ai đó nhận ra learned-rust-this-way là nợ, không liên lạc được với tác giả ban đầu, và nó bị thêm vào cơ sở dữ liệu RUSTSEC.
• Với vai trò là cơ quan xếp hạng, RUSTSEC đánh giá khoản nợ đó là rác, và vì thế CI (tích hợp liên tục) của rất nhiều người bắt đầu thất bại.

Cách xử lý khoản nợ

• Với tư cách là người bảo trì của stuff, mức độ căng thẳng tăng lên khi người dùng nêu vấn đề về việc sử dụng learned-rust-this-way, và bạn bị yêu cầu phải có biện pháp xử lý khoản nợ này.
• Chuyển sang một lựa chọn thay thế là một phương án, nhưng trong trường hợp này thì mọi lựa chọn thay thế đều không hấp dẫn.
• Fork learned-rust-this-way sẽ khiến bạn đối mặt với cùng một yêu cầu, nên đó chỉ là giải pháp tạm thời chứ không thực sự giải quyết vấn đề.

Giải pháp thực sự có hiệu quả

• Nếu bạn gộp đoạn mã đó vào thư viện của chính mình, thì khoản nợ kỹ thuật rác rưởi đó đột nhiên được xếp hạng “AAA”.
• Bạn không còn đụng tới đoạn mã đó nữa, che giấu việc đã gộp nó vào, và tiếp tục bảo trì thư viện như trước, thế giới vẫn cứ vận hành.
• Bằng cách vendoring yaml-rust vào insta rồi gộp nó vào, nó trở thành một thể kết hợp giữa mã của insta và yaml-rust, qua đó nâng hạng khoản nợ kỹ thuật lên AAA.

Ý kiến của GN⁺

• Bài viết này ví nợ kỹ thuật với các công cụ phái sinh tài chính để giải thích một cách dí dỏm những vấn đề phát sinh trong phát triển phần mềm.
• Nợ kỹ thuật là vấn đề thường gặp trong phát triển phần mềm, và bài viết đưa ra cho lập trình viên một cách sáng tạo để quản lý khoản nợ đó.
• Các hệ thống đánh giá như RUSTSEC trong hệ sinh thái Rust có thể giúp lập trình viên đánh giá độ ổn định của thư viện, nhưng đồng thời cũng có thể gây ra căng thẳng không cần thiết.
• Việc gộp mã để xử lý nợ kỹ thuật có thể là một giải pháp tạm thời; về lâu dài vẫn cần một chiến lược bảo trì bền vững.
• Trong những tình huống như vậy, nên cân nhắc nhiều hướng giải quyết khác nhau như bảo trì do cộng đồng dẫn dắt, đồng bảo trì các dự án mã nguồn mở, hoặc tìm một phiên bản thay thế của thư viện.

[GN⁺]

Ý kiến trên Hacker News

• Tác giả của trình phân tích YAML phổ biến nhất đã đột ngột từ bỏ dự án, đồng thời đánh dấu nó là không nên dùng nữa (deprecated) và không còn được bảo trì (unmaintained). Việc này diễn ra mà không có cảnh báo hay chỉ định người bảo trì khác, và dù gói vẫn hoạt động, nó đang được hơn 4.000 crate khác sử dụng, nên các công cụ kiểm toán và cập nhật tự động sẽ cảnh báo về việc dùng crate không được bảo trì.
• Với những ai thấy bối rối trước chữ viết tắt CDO, có người đoán rằng nó có nghĩa là collateralized debt obligation, vì từ collateralized đã được dùng nhiều lần.
• Nếu đường thực thi dễ bị tổn thương trong mã không thể bị chạy hoặc truy cập từ thư viện bên ngoài, thì đó trở thành một đường mã an toàn. Việc vendoring thư viện cung cấp công cụ để tấn công vào mã, và nếu bạn có độ bao phủ kiểm thử đủ tốt cho thư viện của chính mình, bạn có thể chạy công cụ đo code coverage trên thư viện đã được vendoring. Việc chỉnh sửa thư viện đã vendoring có thể là một thách thức, nhưng việc xóa những phần không cần thiết có thể tương đối dễ hơn. Tất nhiên, điều này còn tùy vào cấu trúc của thư viện được vendoring.
• Một cựu nhà phân tích định lượng, hiện là nhà kinh tế học, khen tác giả đã dùng đúng thuật ngữ Collateralized Debt Obligation. Người này muốn viết một bài về “nợ kỹ thuật”, nhưng cho rằng phép ẩn dụ “nợ” không thật sự phù hợp với khái niệm đó. Cụm “mã có độ nhớt cao” có lẽ phù hợp hơn. Mã không thể dễ dàng thay đổi để đáp ứng tính năng mới, nên nó tạo cảm giác như có độ cảm ứng cao.
• Về ý tưởng rằng “junk tech debt” bỗng được xếp hạng AAA, có vẻ tác giả muốn nói rằng cùng một đoạn mã thì không thể có xếp hạng nợ tốt hơn trước và sau khi được vendoring. Nhưng cách nhìn này chỉ xét giá trị của bản thân mã, và bỏ lỡ phần quan trọng nhất của đề xuất giá trị tổng thể. Người bảo trì thực hiện vendoring giờ đây sở hữu đoạn mã đó, và một người bảo trì tích cực mang mã từ dự án đã chết vào sẽ làm tăng giá trị của nó, vì lúc này đã có con người có thể phản hồi issue, xem xét pull request và sửa lỗi.
• Người ta cũng đã thấy cùng một kiểu mẫu trong hệ sinh thái JS npm. Npm audit chủ yếu đưa ra các cảnh báo phóng đại về vấn đề bảo mật, và miễn là giấy phép cho phép, việc vendoring là một trong những cách đáng tin cậy nhất để thoát khỏi những vấn đề vô lý mà người dùng ném vào bạn.
• Việc fork yaml-rust và viết lại nó bằng Rust thuần để tạo ra yaml-rust2 là một điều may mắn. Bản fork này vượt qua hoàn toàn bộ kiểm thử YAML và cho hiệu năng tốt hơn trong benchmark. Việc di chuyển sang nó cũng có vẻ đơn giản. Cuối cùng thì vấn đề vẫn còn đó: hiện tại chúng ta vẫn đang phụ thuộc vào những người khác đang cung cấp lao động miễn phí, nhưng không có gì đảm bảo họ sẽ làm điều đó mãi mãi.
• Nếu trình quản lý gói dựa trên mã nguồn không buộc registry phải có quyền pháp lý để cưỡng chế tiếp quản việc bảo trì các gói đã được phát hành, họ sẽ phải đối mặt với những vấn đề kinh khủng: bị bỏ hoang, thay đổi độc hại, gỡ bỏ độc hại, mạo danh, v.v. Với các gói được xem là đủ quan trọng đối với cộng đồng, cần có cách tước mục registry khỏi tay chủ sở hữu ban đầu và thay bằng một bản fork.
• Nếu mã vẫn chạy và đã như vậy trong nhiều năm, thì việc nó không được bảo trì có gì đáng ngại? Nếu không cần sửa và bạn biết rõ giới hạn cũng như khả năng của nó, thì không thành vấn đề. Mã không tự nhiên trở nên tệ đi. Trong nhiều thập kỷ trước đây, việc sao chép hoặc tích hợp mã cũ nhiều lần hoàn toàn không có vấn đề gì.
• Vendoring dependency mới là lời giải. Trong 20 năm qua, người ta đã làm vậy với gần như mọi dependency đã “hoàn thiện” và vì thế chậm lại trong phát triển lẫn bảo trì.