Chương trình Build It Yourself tự tay xây dựng

• Một góc nhìn khác về dependency

  • Đề xuất một góc nhìn mới về dependency. Cần giảm việc lạm dụng dependency và chuyển sang hướng tự viết mã nhiều hơn.

• Vấn đề dependency

  • "Sự bào mòn vì dependency" là vòng lặp bất tận của cập nhật, bản vá, kiểm toán và dependency bắc cầu mà các lập trình viên cài vào để tăng năng suất.
  • JavaScript và Rust đặc biệt dễ gặp vấn đề về dependency. Ví dụ, một dự án Tokio mới bao gồm 28 crate, còn dự án Rocket tăng lên 172 crate.

• Vấn đề kích thước terminal

  • Crate terminal_size cung cấp chức năng đơn giản để đo kích thước terminal, nhưng lại cần thêm nhiều crate khác.
  • Điều này dẫn đến tình huống phải biên dịch hàng nghìn chức năng khác nhau.

• Sự cần thiết của dependency

  • Vì được xây dựng trên các thư viện trừu tượng hóa nền tảng, việc cập nhật là cần thiết để tránh trùng lặp mã và giảm thời gian biên dịch.
  • Chúng cũng thường là nguyên nhân chính của các vấn đề bảo mật.

• Mục tiêu của mã nguồn

  • Mã nên được viết theo cách không cần cập nhật. Trong hệ sinh thái Rust, mã ổn định lại bị bất lợi.

• Lợi ích của việc tự viết mã

  • Tự viết mã không cần crate mới và làm giảm nhu cầu bảo trì.
  • Có thể dùng các công cụ như ChatGPT để nhanh chóng viết các triển khai không phụ thuộc dependency.

• Mã nguồn mở và văn hóa doanh nghiệp

  • Văn hóa review code của doanh nghiệp ảnh hưởng đến phần mềm mã nguồn mở.
  • Việc dùng thư viện mới thường được xem là điều tích cực.

• Sự cần thiết của một góc nhìn mới

  • Nên khen ngợi những kỹ sư tự viết các chức năng nhỏ.
  • Nên hoài nghi với những đồ thị crate quá lớn.

• Những thư viện quan trọng

  • Vẫn có những thư viện quan trọng giải quyết các vấn đề phức tạp. Ví dụ như thư viện đồ họa hoặc các triển khai giao thức.

• Tầm quan trọng của việc tự xây dựng

  • Nên chúc mừng việc tự xây dựng khi phù hợp.
  • Nên ghi nhận công lao của các tác giả thư viện tạo ra thư viện mã nguồn mở có ít hoặc không có dependency.

• Kết luận

  • Cần chuyển hướng sang giảm dependency và tự viết mã.
  • minijinja là một ví dụ tối giản dependency, chỉ phụ thuộc vào serde.

[GN⁺]

Ý kiến Hacker News

• Tôi thích ngôn ngữ Rust, nhưng ghét vấn đề phụ thuộc của Rust. Quản lý phụ thuộc của C++ tốt hơn. Trong C++, bạn có thể tự kiểm soát phụ thuộc, nhưng trong Rust, số lượng phụ thuộc tăng quá nhiều đến mức khiến người ta bỏ cuộc. Xét về bảo mật, tôi cũng không biết mình đang phát hành chính xác thứ gì. Rust không có tương thích ABI và cũng thiếu văn hóa thư viện chia sẻ. Điều này phá vỡ mô hình phân phối gói của hệ điều hành.

• API terminal không ổn định. TIOCGWINSZ ioctl không được chuẩn hóa, và việc hàm tcgetwinsize() được thêm vào POSIX chỉ mới diễn ra trong năm 2024. Phía Windows còn phức tạp hơn.

• Tôi đã hồi sinh một web app làm từ năm 2006. Để học các công nghệ CI/CD mới, tôi đã thiết kế quá mức quy trình triển khai của ứng dụng. Tôi dùng PHP và MySQL, và tự viết hầu hết mã nguồn. Việc hồi sinh một ứng dụng đã 19 năm tuổi chỉ mất đúng một giờ. Trong khi đó, ứng dụng Spring Boot ở chỗ làm hiện tại thì rất khó cập nhật vì vấn đề phụ thuộc.

• NodeJS đã ảnh hưởng rất lớn đến sự nghiệp của tôi, nhưng NPM cũng gây ra rất nhiều vấn đề. Mỗi khi muốn thêm một phụ thuộc mới, nó lại xung đột với các phụ thuộc khác. Với Expo, thậm chí dự án React Native mặc định còn có vấn đề không build được trên Android. Điều đó lại khiến tôi tự tin hơn, vì ngay cả các dự án lớn cũng có thể phát hành những template không hoạt động.

• Hệ sinh thái Rust có nhiều phụ thuộc hơn khi so với Go. Trong Go, interface được thỏa mãn một cách ngầm định nên không cần thêm phụ thuộc bổ sung.

• Sự trừu tượng hóa của thư viện luôn có cái giá ẩn. Khi package thay đổi thiết kế, sự bất ổn sẽ xuất hiện. Những thứ đơn giản là thứ tồn tại lâu nhất. Tôi không chỉ thấy vấn đề này ở Rust mà còn ở các ngôn ngữ khác.

• Dùng ChatGPT hay Cursor để nhanh chóng tạo ra một triển khai không phụ thuộc còn nhanh hơn. Nhiều phụ thuộc vào dịch vụ SaaS/3rd party thực ra là những vấn đề đã được giải quyết từ lâu.

• Flask và Bottle có chức năng tương tự nhau, nhưng Flask trở nên phổ biến hơn. Bottle là một file đơn, không có phụ thuộc nên có thể dễ dàng sao chép vào dự án. Tuy nhiên, nó không theo kịp các thực hành Python hiện đại nên tạo cảm giác đã lỗi thời.

• Cần những kỹ sư đủ năng lực để tự phát triển giải pháp. Rất dễ tạo ra một giải pháp tốt hơn thư viện có sẵn. Tôi từng viết một parser cho biến thể Markdown trong dự án, nhưng các đồng đội không muốn dùng vì lý do bảo trì.

• Việc biên dịch hàng trăm hàm chỉ để dùng đúng một hàm là có vấn đề. Trong một dự án cập nhật phụ thuộc 3rd party, chúng tôi thực ra chỉ dùng một phương thức của thư viện toán học. Tôi khuyến khích kỹ sư tham khảo trang Wikipedia rồi tự viết phương thức đó. Vấn đề không phải là dùng phụ thuộc 3rd party, mà là cần một khái niệm cho phép chỉ lấy một phần nhỏ của thư viện. "Microframework" có thể là lời giải.