Đó là điều hiển nhiên, nhưng lại khó thực hiện..

Tiêu đề của bài viết đã được đổi thành tên gốc.

Hóa ra việc gắn Rust vào một codebase C lớn không thú vị như tưởng tượng. Nếu nói là để tăng độ an toàn bộ nhớ thì rốt cuộc vùng unsafe cũng phình ra nên hiệu quả thực tế không lớn lắm.... Nó dường như không mang nhiều ý nghĩa ngoài việc phạm vi sử dụng Rust ngày càng rộng hơn.... nên việc gây ra phản ứng ngược từ các lập trình viên C hiện có có lẽ là diễn biến khá tự nhiên. Có lẽ sẽ tốt hơn nếu tập trung vào một dự án kernel thực sự được bắt đầu bằng Rust ngay từ đầu.

Ồ, chất lượng phần nội dung tốt hơn tôi nghĩ đấy, đọc rất thú vị.

Điều Torvalds muốn nói khi bảo rằng vấn đề nằm ở chính bạn là, bất kể việc áp dụng Rust hay không, lời giải cho các vấn đề kỹ thuật không thể đến từ SNS; nhưng nếu chỉ nhìn vào phần tóm tắt này thì có vẻ khá dễ gây hiểu lầm.

Nội dung bạn viết có vẻ hoàn toàn đúng như những gì Hellwig đã phát biểu, nhưng tôi không chắc có thể xem đó là ý kiến của đa số hay không.

https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr cho thấy quá trình mọi thứ leo thang thành một cuộc tranh cãi.

Chẳng phải Torvalds cũng cho phép Rust sao?

Nếu giỏi đến thế thì hãy fork kernel rồi viết toàn bộ bằng Rust đi. Đừng có lén lút len vào như ung thư nữa. Có vẻ có khá nhiều ý kiến như vậy.

Dựa trên tài liệu trên, có thể áp dụng kỹ nghệ tử tế trong phát triển như thế nào
Tôi đã thử xây dựng cái gọi là KDD (Kindness Driven Development) với sự hỗ trợ của AI.

Viết mã

• Hãy viết chú thích và tài liệu hóa với trọng tâm là "Tại sao?". Điều quan trọng là giải thích lý do tồn tại của đoạn mã và bối cảnh của nó.
• Với logic phức tạp, hãy sử dụng tên biến và tên hàm có dùng thuật ngữ miền nghiệp vụ để các lập trình viên khác dễ hiểu hơn.
• Khi đưa vào công nghệ hoặc pattern mới, hãy cân nhắc đường cong học tập của các thành viên trong nhóm.
• Đừng chỉ trích mã legacy. Chắc hẳn đã có những ràng buộc và bối cảnh ở thời điểm đó.
• Hãy tài liệu hóa cách xử lý các edge case và failure case cho người sẽ bảo trì trong tương lai.
  Thiết kế kiến trúc
• Khi thiết kế hệ thống, hãy cân nhắc cả góc nhìn của đội vận hành và đội QA.
• Làm cho việc giám sát và gỡ lỗi dễ dàng cũng là một phần của thiết kế tử tế.
• Thiết kế có khả năng mở rộng là sự quan tâm dành cho các thành viên tương lai của nhóm.
• Khi quản lý technical debt, hãy đặt mục tiêu là "mức có thể quản lý được" thay vì loại bỏ hoàn toàn.
• Điều quan trọng là tạo ra một cấu trúc giúp việc bổ sung tính năng mới trở nên dễ dàng.
  Code review
• Khi yêu cầu review, hãy giải thích đầy đủ ngữ cảnh của các thay đổi.
• Hãy dùng kiểu phản hồi mang tính đề xuất như "Làm thế này thì sao?".
• Nhất định cũng hãy nhắc đến những điểm tích cực. "Phần này thật sự rất gọn gàng"
• Khi đưa ra phương án thay thế, hãy giải thích cả lý do.
• Với những cải tiến không quá gấp, hãy đăng ký thành issue riêng để tôn trọng phạm vi của PR hiện tại.
  Mã kiểm thử
• Khi kiểm thử thất bại, hãy cung cấp thông báo lỗi rõ ràng.
• Test case cũng đóng vai trò như tài liệu. Hãy viết các bài kiểm thử giải thích tốt các quy tắc nghiệp vụ.
• Hãy tạo cấu trúc để các lập trình viên khác có thể dễ dàng bổ sung kiểm thử.
• Với dữ liệu kiểm thử, hãy dùng các ví dụ thực tế dễ hiểu.
• Hãy tự động hóa việc thiết lập môi trường kiểm thử để hạ thấp rào cản tham gia.
  Triển khai và vận hành
• Hãy đưa đủ phần giải thích và hướng dẫn vào script triển khai.
• Hãy chuẩn bị trước các log giúp ích cho việc gỡ lỗi khi xảy ra sự cố.
• Nếu cần thay đổi cấu hình, hãy tài liệu hóa mức độ ảnh hưởng.
• Khi phát hành tính năng mới, hãy chuẩn bị cả kế hoạch rollback.
• Hãy viết hướng dẫn vận hành từ góc nhìn của lập trình viên mới.
  Chia sẻ tri thức
• Hãy tài liệu hóa và chia sẻ kinh nghiệm troubleshooting.
• Khi đưa vào công nghệ mới, hãy tạo và chia sẻ tài liệu học tập.
• Hướng dẫn viết mã hãy bao gồm cả "Vì sao chúng ta quyết định làm như vậy".
• Hãy thúc đẩy sự phát triển của cả nhóm thông qua các buổi chia sẻ kỹ thuật định kỳ.
• Tạo ra môi trường dễ đặt câu hỏi sẽ giúp hỗ trợ sự phát triển của các lập trình viên junior.

Ngắn gọn nên rất hay đấy? Xin đừng thay đổi.

Vì Automattic là công ty do người tạo ra WordPress thành lập, nên việc chủ sở hữu tự đánh cắp đồ của mình là điều mâu thuẫn; có lẽ cách diễn đạt "bắt nạt theo kiểu mã nguồn mở" sẽ phù hợp hơn.

Mới chỉ 2 năm 2 tháng kể từ khi ChatGPT ra mắt. Công nghệ từng bị đem ra cười cợt khi meme kiểu "vụ Sejong Đại Vương ném MacBook" lan truyền, vậy mà chỉ hơn 2 năm đã đi được đến đây. Không ai dám bảo tốc độ phát triển trong tương lai sẽ vẫn như từ trước đến nay, nhưng nếu tính đến chuyện thay thế thì cùng lắm tôi thấy là 5 năm. Mà có khi như vậy còn là tính quá dài.

Đỉnh quá

Cảm ơn bạn đã góp ý.

Tôi cho rằng phát biểu của Linus là quan trọng nhất nên đã đưa nó vào tiêu đề, nhưng có vẻ như điều đó đã làm méo mó nội dung khá nhiều.

Tôi chắc chắn sẽ cẩn trọng hơn.

Tiêu đề gốc cho biết ngay câu chuyện nói về điều gì, trong khi tiêu đề anh/chị đã sửa có vẻ dễ khiến người ta hiểu nhầm là mang tính giật tít. Đây là ý kiến cá nhân của tôi.

Tôi có thói quen thêm phụ đề riêng vào tiêu đề để giải thích chính xác hơn, nhưng có vẻ tiêu đề đó không phù hợp với người khác, hơn nữa tôi cũng không biết là có quy định như vậy. Từ lần sau tôi sẽ đăng nguyên văn tiêu đề gốc.

'm 'b Chúc bạn một ngày tốt lành! Cảm ơn bạn, nhờ vậy tôi đã được đọc một bài viết hay. (__ )

Tôi sẽ tham khảo.

Xin chào. Cảm ơn bạn đã đăng một bài viết hay. Tôi đã đọc rất thích.

Tuy nhiên, sau khi kiểm tra bài gốc và xem tiêu đề gốc, tôi có đôi chút lo ngại nên xin để lại bình luận.

https://news.hada.io/guidelines

> Về cơ bản, vui lòng dùng tiêu đề gốc của bài viết, hoặc dịch tiêu đề sang tiếng Hàn rồi đăng lên.

Có đề xuất như vậy, và khi đọc nội dung bài viết này, tôi nghĩ rằng tiêu đề "Linus Torvalds 'Vấn đề là ở bạn'" thay cho "Tranh cãi về Rust trong Linux kernel lại bùng lên" thậm chí còn dễ khiến người đọc hiểu sai nội dung bài viết hơn cả tiêu đề gốc.

Một lần nữa xin cảm ơn bạn vì đã tóm tắt và giới thiệu bài viết. Chúc bạn một ngày tốt lành.