NeoVim và bài học về trách nhiệm bảo vệ dữ liệu người dùng

Có những tranh cãi nhỏ trong giới phần mềm lại hé lộ những vấn đề rất lớn về triết lý thiết kế. Câu chuyện về tính năng persistent undo (hoàn tác lâu dài) của Vim và cách NeoVim xử lý nó là một ví dụ như vậy.

Khi phần mềm xóa dữ liệu của bạn mà không hề do dự

Nhà khoa học máy tính David Chisnall chia sẻ trên Mastodon rằng ông dùng Vim từ khoảng năm 2000, viết năm cuốn sách, một luận án tiến sĩ, hàng chục bài báo và hơn 150 bài viết bằng trình soạn thảo này. Đến mức các ngón tay ông gõ lệnh Vim mà không cần não bộ tham gia.

Với Chisnall, persistent undo là một trong những tính năng ông yêu thích nhất. Ông hiếm khi cần đến nó, nhưng khi cần thì nó vô giá: lỡ xóa mất một đoạn trong file từ tuần trước, qua một lần khởi động lại máy — đoạn đó là gì nhỉ? Cứ hoàn tác ngược dần cho đến khi tìm thấy, sao chép rồi dán vào bản hiện tại. Hoặc tình huống phổ biến hơn: code đang chạy tốt, dọn dẹp lại cho gọn trước khi commit thì hỏng — rốt cuộc mình đã đổi cái gì?

Vim đã giữ cho tính năng này hoạt động qua nhiều lần nâng cấp phiên bản lớn trong khoảng 20 năm. Chisnall nói ông thậm chí không phải nghĩ về nó, vì đó là một phần của Định luật đầu tiên của Raskin: Một chương trình không được làm hại dữ liệu người dùng, hoặc thông qua sự thụ động, để dữ liệu người dùng bị tổn hại. Dù Vim hay máy tính có sập, hay bạn đóng file rồi sáu tháng sau mở lại, lịch sử hoàn tác vẫn còn nguyên đó.

NeoVim và sai lầm không thể tha thứ

Chisnall kể lại trải nghiệm của mình với NeoVim — bản fork của Vim, vốn cũng đang được nhắc đến nhiều vì những lý do khác. Ông thử nó khi còn khá mới, với kỳ vọng đơn giản: Vim quen thuộc nhưng tốt hơn.

Điều đầu tiên ông nhận ra là tính năng undo không hoạt động. Thử mở file bằng Vim gốc, undo cũng không hoạt động luôn. Hóa ra NeoVim đã thay đổi định dạng file undo, nhưng không nâng cấp file cũ, cũng không dùng tên khác cho file undo của mình. Nó chỉ đơn giản là phát hiện file undo của Vim, xóa nó (mất toàn bộ dữ liệu bên trong) và thay bằng file mới mà Vim không đọc được.

Khi Chisnall mở issue phản ánh, ông nhận được câu trả lời rằng định dạng persistent undo là "không ổn định" và người dùng không nên tin tưởng dữ liệu sẽ được giữ lại trong một tính năng được gọi đúng tên là persistent undo. Nó đã thay đổi một lần và chắc chắn sẽ thay đổi lần nữa.

Việc phá vỡ tính năng persistent undo là điều tôi có thể bỏ qua như một lỗi. Nhưng thái độ cho rằng chỉ vì đó là một file trên hệ thống của bạn, chứa dữ liệu bạn có thể cần, nên chương trình của họ có quyền xóa nó — điều đó cho thấy họ hoàn toàn không có khái niệm về trách nhiệm bảo vệ người dùng.

Và đó là dấu chấm hết cho mối duyên của Chisnall với NeoVim.

Ba định luật Raskin và bài học cho nhà phát triển

Câu chuyện này khiến người ta nhớ đến Jef Raskin — người khởi xướng dự án Macintosh tại Apple và tạo ra chiếc máy Canon Cat. Trong cuốn The Humane Interface (2000), ông đưa ra ba định luật:

• Máy tính không được làm hại công việc của bạn, hoặc thông qua sự thụ động, để công việc của bạn bị tổn hại.
• Máy tính không được lãng phí thời gian của bạn, cũng không được bắt bạn làm nhiều việc hơn mức cần thiết.
• Một giao diện là thân thiện với con người nếu nó đáp ứng nhu cầu con người và thấu hiểu những điểm yếu của con người.

Với giới phát triển phần mềm hiện đại, câu chuyện là một lời nhắc nhở đắt giá. Người dùng nhớ rất dai khi phần mềm làm mất công sức của họ, và họ cũng nhớ cách mà đội ngũ phát triển phản hồi. Một thay đổi định dạng dữ liệu tưởng chừng nhỏ nhặt có thể phá vỡ niềm tin được xây dựng trong nhiều năm.

Với người dùng công cụ lập trình tại Việt Nam, đây cũng là bài học khi chọn và khi tự xây dựng sản phẩm: khả năng tương thích ngược với dữ liệu cũ là một phần của chất lượng phần mềm, không phải là chi tiết phụ. Đừng để người dùng phải tự đoán xem dữ liệu của họ có an toàn qua lần nâng cấp tiếp theo hay không.