Chọn đúng phụ thuộc: Hướng dẫn thực hành toàn diện

Nếu bạn là đầu bếp tại một nhà hàng cao cấp được gắn sao Michelin, bạn có mua rau và thịt từ những nguồn ngẫu nhiên không được kiểm chứng không? Chi phí của hầu hết các dự án trung bình được đo bằng hàng trăm nghìn hoặc thậm chí hàng triệu đô la. Tôi tin rằng ngành của chúng ta nên có cách tiếp cận giống như các nhà hàng.

Câu hỏi đầu tiên bạn cần tự hỏi mình ngay lập tức: bạn có thực sự cần một sự phụ thuộc mới không? Có thể giải quyết vấn đề bằng cách sử dụng môi trường hiện tại, chẳng hạn như ngôn ngữ hoặc thư viện đã cài đặt không? Ví dụ: không cần cài đặt thư viện bổ sung để tạo UUID. Node.js và các trình duyệt hỗ trợ nó ngay lập tức: crypto.randomUUID()

Câu hỏi thứ hai: bạn có cần toàn bộ thư viện không? Chẳng hạn, nếu bạn chỉ cần một danh sách thả xuống, thì có đáng để cài đặt thứ gì đó như Bootstrap không? Có lẽ tốt hơn là bạn nên giới hạn bản thân trong một thư viện tập trung, duy nhất với thành phần thả xuống chưa được chỉnh sửa từ Radix UI ?

Được rồi. Chúng tôi có một vài ứng cử viên trong tâm trí. Vì vậy, làm thế nào để chúng ta chọn đúng?

Một README được định dạng đẹp mắt? Một cái tên nổi tiếng? Nhiều nhánh, sao và tải xuống hơn những cái khác? Thật không may, chỉ những yếu tố này là không đủ. Ở đây, chúng tôi đang chọn một nhà cung cấp dịch vụ. Chúng tôi muốn mọi vấn đề phát sinh phải được giải quyết nhanh chóng, chức năng luôn được cập nhật và trên hết là dịch vụ phải an toàn và đáng tin cậy. Các chỉ số bên ngoài đơn giản không phải lúc nào cũng chỉ ra chất lượng hoặc sự phù hợp lâu dài. Trước khi cài đặt những gì chúng tôi tìm thấy trên danh mục kho lưu trữ, sẽ rất tuyệt nếu bạn truy cập kho lưu trữ GitHub và phân tích nội dung của nó.

Tôi đã chuẩn bị một danh sách các tiêu chí mà tôi đã sử dụng trong vài năm qua. Tôi hy vọng họ sẽ giúp bạn chọn các thư viện phù hợp nhất. Điều cần thiết là phải xem xét chúng một cách toàn diện và trong một số trường hợp, hãy thỏa hiệp khi lựa chọn giữa chúng.

Tuyên bố miễn trừ trách nhiệm: Tôi không chỉ trích các thư viện được đề cập bên dưới hoặc cố gắng ngăn cản việc sử dụng chúng. Trong một số trường hợp, tôi đã cố ý bỏ qua các tên để tập trung vào ví dụ về tiêu chí trong khi vẫn đảm bảo tính chính xác của thực tế.

1. Bảo mật

Làm thế nào là nó an toàn để sử dụng? Nghe có vẻ hư cấu, nhưng vâng, sự phụ thuộc có thể nguy hiểm. Ví dụ: một tính năng thú vị đã được thêm vào thư viện với 500 nghìn lượt tải xuống: tính năng này cố gắng thay thế tất cả các tệp trên máy tính bằng ❤️ nếu địa chỉ IP của bạn nằm trong một phạm vi cụ thể.

Một sự thật thú vị là sự phụ thuộc này đã được sử dụng trong vue-cli . Làm thế nào chúng ta có thể phát hiện ra những vấn đề như vậy? Kiểm tra trang vấn đề hoặc thử tra cứu tên thư viện trên Google. Thông thường, những thông tin như vậy xuất hiện nhanh chóng.

2. Bảo trì

Lần phát hành cuối cùng là khi nào? Tần suất phát hành xảy ra như thế nào? Các bản phát hành thường xuyên đảm bảo rằng các vấn đề được giải quyết và các bản cập nhật hỗ trợ các công nghệ thay đổi liên tục. Trong bối cảnh phát triển di động, các bản phát hành thường xuyên cũng đảm bảo rằng dự án biên dịch thành công.

Đây là một ví dụ từ thế giới cờ vây: các tác giả của một thư viện có 18,2 nghìn sao đã quyết định ngừng duy trì sự phụ thuộc của họ và lưu trữ nó. Điều này có nghĩa là trong một vài năm tới, việc thiếu hỗ trợ và cập nhật sẽ trở thành một vấn đề. Bây giờ hãy tưởng tượng cài đặt một phần phụ thuộc tương tự mà không cần kiểm tra GitHub trước. Đó là loại kiểm tra ngày hết hạn của sản phẩm.

Dưới đây là một ví dụ về các bản phát hành tốt thường xuyên:

3. Vấn đề Mở/Đóng

1. Tỷ lệ các vấn đề mở so với các vấn đề đã đóng là bao nhiêu? Các tác giả sẵn sàng chấp nhận những thay đổi như thế nào? Có thể là bạn có thể cần phải đóng góp một cái gì đó vào một ngày nào đó. Chẳng hạn, thư viện này khá phổ biến và có 98% phần trăm các sự cố đã đóng. Chỉ có 18 được mở.

   

   
   

2. Các vấn đề quan trọng được giải quyết nhanh như thế nào? Một lần, tôi đã chọn một ORM có 31 nghìn sao, nhưng đến một lúc nào đó, chúng tôi gặp sự cố khiến chúng tôi bị chặn. Chúng tôi đã phải tìm cách giải quyết và cuối cùng chuyển sang giải pháp khác. Thật không may, gần 4 năm đã trôi qua mà vấn đề vẫn chưa được giải quyết.

   

   Những vấn đề như vậy có thể được xác định bằng cách sắp xếp theo bình luận nhiều nhất.

   
   

3. Quá trình đóng góp đã được tổ chức bởi những người sáng tạo? Có một quy trình làm việc rõ ràng, được xác định tại chỗ không? Chẳng hạn, những người tạo Next.js thậm chí đã ghi lại một video dài 40 phút về quá trình đóng góp của họ.

   
   

4. Chất lượng mã

Vâng, có thể có rất nhiều mã, nhưng luôn có thể kiểm tra các phần khác nhau của nó. Dự án được tổ chức như thế nào? Nó có dễ hiểu, có cấu trúc tốt và có áp dụng các phương pháp hay không? Mã được viết càng tệ thì khả năng dự án sụp đổ trong tương lai càng cao. Nhiều thí sinh nhỏ đã bị loại ở giai đoạn này vì tôi.

5. Phạm vi kiểm tra

Thư viện có bài kiểm tra không? Phạm vi kiểm tra là gì? Các bài kiểm tra được viết như thế nào? Ngay cả khi người bảo trì xem xét các yêu cầu hợp nhất, vẫn có khả năng một số thứ có thể bị bỏ qua. Có rất nhiều người khác nhau đóng góp cho thư viện. Thông thường, thông tin về phạm vi kiểm tra được hiển thị trên các huy hiệu ở đầu kho lưu trữ. Tuy nhiên, nếu không, chúng ta luôn có thể tìm kiếm các bài kiểm tra trong dự án. Chẳng hạn, họ thư viện formatjs có phạm vi kiểm tra tuyệt vời và bao gồm nhiều loại kiểm tra khác nhau.

6. Kích thước thư viện

Các ứng dụng dành cho thiết bị di động thường có kích thước phụ thuộc lớn và toàn bộ ứng dụng thậm chí có thể lớn hơn 200 MB, điều này có thể gây ra sự cố trong quá trình tải xuống qua mạng di động và tiêu tốn nhiều dung lượng lưu trữ. Điều này đặc biệt có vấn đề đối với các ứng dụng CSR ngoại vi, nơi tốc độ internet chậm có thể làm tăng đáng kể thời gian tải.

Đối với các dự án web, có một công cụ tuyệt vời để xác định kích thước gói: https://bundlephobia.com . Tất nhiên, kết xuất phía máy chủ và rung cây có thể làm giảm kích thước, nhưng điều này cần phải luôn được xác minh.

Một ví dụ phổ biến là các thư viện thao tác ngày tháng. Chức năng do dayjs (2,9KB) cung cấp có thể là đủ, loại bỏ nhu cầu cài đặt moment.js (72,1KB) hoặc date-fns (26,8KB).

7. Số lượng phụ thuộc

Tất cả các điểm được liệt kê ở trên được nhân lên, ở một mức độ nào đó, bởi số lượng phụ thuộc trong toàn bộ cây phụ thuộc của dự án. Một công cụ tuyệt vời để kiểm tra cây phụ thuộc đầy đủ: https://npm.anvaka.com

8. Giấy phép

Bạn đã bao giờ nghĩ về điều này chưa? Tôi cũng không. Ví dụ: giấy phép MIT và Apache 2.0 cho phép sử dụng miễn phí thư viện trong các dự án thương mại, trong khi một số giấy phép GPL v2 có các yêu cầu và hạn chế cụ thể. Trong một trong những dự án của chúng tôi, chúng tôi có một bảng do luật sư chuẩn bị để kiểm tra tất cả các giấy phép của cây phụ thuộc của chúng tôi. Vì vậy, nếu bạn thấy điều gì đó bất thường trong giấy phép, tốt hơn hết bạn nên tham khảo ý kiến luật sư để tránh các vấn đề trong quá trình kiểm toán. Chúng tôi có thể trích xuất tất cả các giấy phép từ các phụ thuộc npm hiện có bằng cách sử dụng tiện ích hợp pháp . PS Tôi không phải là luật sư và đây không phải là lời khuyên pháp lý. Đó là một trường hợp hiếm hoi và đặc biệt mà một cái gì đó có thể không phù hợp do giấy phép, nhưng nó vẫn có thể xảy ra.

Kết thúc!

Cảm ơn bạn đã đọc bài viết của tôi! Điểm mấu chốt của nó là đưa ra các ví dụ thực tế rằng việc ra quyết định nông cạn và nhanh chóng đôi khi không dẫn đến lựa chọn tốt nhất. Bằng cách xem xét các tiêu chí này, bạn sẽ có thể đưa ra quyết định sáng suốt hơn.

Xin vui lòng để lại bất kỳ ý kiến hoặc đề nghị bạn có thể có. Đừng ngần ngại chia sẻ kinh nghiệm của bạn trong phần bình luận. Thích và bình luận của bạn truyền cảm hứng cho tôi để viết bài viết mới. Nấu ăn vui vẻ :)