Thế giới lập trình đang sôi sục với cuộc tranh luận gay gắt sau khi người tạo ra ngôn ngữ Odin , Bill Hall , xuất bản một bài viết gây tranh cãi có tiêu đề Package Managers are Evil (Các trình quản lý gói là tà ác). Lời phê bình của ông đã châm ngòi cho cuộc thảo luận sôi nổi về việc liệu các công cụ quản lý phụ thuộc tự động có đang giúp đỡ hay làm hại quá trình phát triển phần mềm.
Lập luận chính của Hall thách thức một giả định cơ bản trong lập trình hiện đại. Ông cho rằng các trình quản lý gói tự động hóa sai thứ - địa ngục phụ thuộc - khiến các nhà phát triển dễ dàng tích lũy hàng nghìn phụ thuộc mà không hiểu được tác động của chúng. Cuộc thảo luận đã bộc lộ sự chia rẽ sâu sắc trong cách các nhà phát triển tiếp cận việc tái sử dụng mã và quản lý dự án.
Các lập luận chính phản đối Package Managers:
- Tự động hóa dependency hell thay vì ngăn chặn nó
- Che giấu độ phức tạp và chi phí thực sự của các dependencies
- Cho phép tích lũy hàng nghìn dependencies chưa được kiểm tra
- Tạo ra các lỗ hổng bảo mật thông qua việc tin tưởng mù quáng
- Dẫn đến gánh nặng bảo trì và trách nhiệm pháp lý về lỗi
Tranh cãi về tự động hóa
Trọng tâm của cuộc tranh luận xoay quanh việc liệu quản lý phụ thuộc nên được tự động hóa hay thủ công. Hall lập luận rằng các trình quản lý gói che giấu độ phức tạp và khiến việc thêm phụ thuộc trở nên quá dễ dàng mà không cần cân nhắc đúng đắn. Ông đề xuất rằng quản lý phụ thuộc thủ công buộc các nhà phát triển phải suy nghĩ cẩn thận về mỗi lần bổ sung, có khả năng ngăn chặn các cây phụ thuộc phình to.
Phản hồi từ cộng đồng cho thấy những trải nghiệm trái chiều. Một số nhà phát triển chia sẻ câu chuyện về các dự án Rust kéo theo hàng chục phụ thuộc không mong muốn chỉ từ một hoặc hai lần import trực tiếp. Những người khác chỉ ra rằng quản lý thủ công không thể mở rộng quy mô cho các môi trường doanh nghiệp lớn nơi các sản phẩm kết hợp hàng trăm thành phần từ nhiều nhóm trên toàn thế giới.
Cuộc thảo luận làm nổi bật một căng thẳng chính giữa sự tiện lợi cho nhà phát triển và khả năng bảo trì dự án. Trong khi tự động hóa tiết kiệm thời gian, các nhà phê bình lập luận rằng nó có thể dẫn đến những tình huống mà các dự án trở nên phụ thuộc vào mã mà các nhà phát triển chưa bao giờ kiểm tra hoặc hiểu.
Câu chuyện tác động thực tế
Một số thành viên cộng đồng đã chia sẻ những ví dụ cụ thể về các vấn đề liên quan đến phụ thuộc. Một nhà phát triển mô tả việc tìm thấy nhiều lỗi trong SDL2 , một thư viện được sử dụng rộng rãi, khiến nhóm của họ cân nhắc việc viết hệ thống cửa sổ riêng từ đầu. Một người khác kể lại khó khăn trong việc tái tạo một bản build mô hình neural đã được tạo ra mà không có quản lý phụ thuộc đúng đắn.
Các trải nghiệm khác nhau đáng kể theo từng hệ sinh thái lập trình. Các nhà phát triển Go báo cáo cần ít gói bên thứ ba hơn do thư viện chuẩn toàn diện của ngôn ngữ này, trong khi các nhà phát triển JavaScript mô tả thách thức quản lý các cây phụ thuộc phức tạp trong các ứng dụng một trang.
Loại bỏ npm và làm mọi thứ thủ công sẽ không làm cho việc xây dựng SPA có ít phụ thuộc hơn, quá trình build sẽ cực kỳ chậm và đau đầu.
Bình luận này nắm bắt được một mối quan tâm chung - rằng một số môi trường phát triển đã phát triển đến mức phụ thuộc quá nhiều vào các hệ sinh thái gói đến nỗi quản lý thủ công trở nên không thực tế.
Khía cạnh tin cậy và bảo mật
Một phần đáng kể của cuộc thảo luận tập trung vào các tác động bảo mật của quản lý phụ thuộc tự động. Các thành viên cộng đồng tranh luận về việc liệu các nhà phát triển có đặt quá nhiều niềm tin vào mã ngẫu nhiên từ internet hay không, với một số lập luận rằng các lập trình viên từ các xã hội có độ tin cậy cao áp dụng mức độ tin tưởng không phù hợp đối với các kho mã trực tuyến.
Cuộc trò chuyện tiết lộ cái mà một số người gọi là hiệu ứng mất trí nhớ Gell-Mann trong lập trình - các nhà phát triển không tin tưởng mã của chính đồng nghiệp nhưng lại mù quáng tin tưởng các gói mã nguồn mở từ những tác giả không rõ danh tính. Nghịch lý này làm nổi bật những câu hỏi rộng lớn hơn về đánh giá chất lượng mã và quản lý rủi ro trong phát triển phần mềm.
Một số người tham gia lưu ý rằng các vấn đề bảo mật, mặc dù quan trọng, không phải là mối quan tâm duy nhất. Trách nhiệm lỗi, gánh nặng bảo trì và độ phức tạp tích hợp có thể gây vấn đề tương tự đối với nhiều dự án.
Các phương pháp thay thế và giải pháp
Cuộc tranh luận đã tạo ra nhiều đề xuất khác nhau cho các giải pháp trung dung. Một số đề xuất công cụ tốt hơn để kiểm toán phụ thuộc, bao gồm các dịch vụ quét bên thứ ba được tích hợp vào các trình quản lý gói. Những người khác ủng hộ quản lý phụ thuộc có chọn lọc hơn, chỉ sử dụng các trình quản lý gói cho những thư viện đáng tin cậy, quan trọng thay vì các gói vi mô.
Các nhà phát triển doanh nghiệp mô tả việc sử dụng các công cụ như Nix để quản lý phụ thuộc đáng tin cậy hơn, trong khi những người khác chỉ ra các phương pháp như vendoring phụ thuộc với các phiên bản bị khóa. Cuộc thảo luận tiết lộ rằng các bối cảnh phát triển khác nhau - từ phát triển game đến các hệ thống quan trọng về an toàn - có những yêu cầu và ràng buộc rất khác nhau.
Cuộc trò chuyện cũng đề cập đến vai trò của các thư viện chuẩn. Các ngôn ngữ có chức năng tích hợp toàn diện, như Go , dường như tạo ra ít sự lan tỏa phụ thuộc hơn so với những ngôn ngữ có thư viện chuẩn tối thiểu đẩy các chức năng thông dụng sang các gói bên ngoài.
Các Phương Pháp Thay Thế Được Thảo Luận:
- Quản lý dependency thủ công với vendoring
- Sử dụng các ngôn ngữ có thư viện chuẩn toàn diện (ví dụ Go )
- Quản lý dependency có chọn lọc chỉ cho các gói quan trọng
- Dịch vụ kiểm toán bên thứ ba tích hợp vào package manager
- Các công cụ như Nix để giải quyết dependency đáng tin cậy hơn
- Git subtrees thay vì submodules để quản lý dependency
Kết luận
Cuộc tranh luận này phản ánh những căng thẳng rộng lớn hơn trong phát triển phần mềm giữa phát triển nhanh và khả năng bảo trì lâu dài. Trong khi các trình quản lý gói chắc chắn đã tăng tốc phát triển phần mềm bằng cách làm cho việc tái sử dụng mã dễ dàng hơn, chúng cũng đã giới thiệu các loại vấn đề mới mà ngành công nghiệp vẫn đang học cách quản lý.
Cuộc thảo luận cho thấy rằng thay vì xem các trình quản lý gói là tốt hoặc xấu một cách tuyệt đối, các nhà phát triển có thể hưởng lợi từ các phương pháp tinh tế hơn có xem xét bối cảnh dự án, khả năng của nhóm và yêu cầu bảo trì lâu dài. Khi ngành lập trình tiếp tục trưởng thành, việc tìm ra sự cân bằng phù hợp giữa tự động hóa và kiểm soát thủ công vẫn là một thách thức đang diễn ra.
Tham khảo: Package Managers are Evil