Nếu bạn cần làm gì đó trong Ruby, gem cho nó có thể tồn tại. Thực ra, một tá gem cho nó có thể tồn tại. Một số thanh lịch, giàu tính năng, được maintain tốt, những cái khác được viết để giải quyết một use case tác giả gặp một lần. Bạn có nhiều gem để chọn, vậy làm sao chọn cái đúng? Lựa chọn này quan trọng – khi bạn hối hận thêm gem vào project, nó đau đớn để quay lại.
Thống kê
Khi tôi cần thư viện giải quyết vấn đề, tôi bắt đầu với Ruby Toolbox. Ruby Toolbox là cách tuyệt vời lấy danh sách tất cả gem trong category (như "Subscription Management"), cùng với:
-
Bao nhiêu người dùng?
Gem phổ biến thường phổ biến vì lý do. Và dễ xin giúp đỡ hơn nếu mọi người trên internet dùng cùng gem.
-
Cập nhật gần đây / thường xuyên như thế nào?
Gem có update nhất quán, hay upgrade tương thích Rails 3.2 vẫn nằm trong pull request queue? Nếu release cuối là nhiều năm trước, bạn có thể muốn bỏ qua – nó có lẽ không tương thích với app bạn.
Với gem bạn tìm trên Ruby Toolbox, lọc bằng hai tiêu chí đầu, bạn nên có danh sách gem đang cân nhắc. Ruby Toolbox cũng cho link đến source, documentation, website, bug tracker, những thứ bạn cần tiếp theo.
Code & Documentation
-
Gem có documented tốt không?
Check website, nếu có. Doc có tốt không? Có RDoc không? Bạn có thể tìm câu trả lời khi cần không?
-
Có well-tested không?
Xem test. Nó thậm chí có thư mục
test/hoặcspec/không? Có test nào ngoàitest_truthkhông? Tác giả có biết nếu họ gây regression không? -
Xem issues và pull requests
Bug được fix nhanh không? Có thảo luận trên bug/PR và chúng được fix không? Hay chúng chỉ ngồi đó?
-
Search tên gem trên Google, StackOverflow, reddit
Người ta nói gì về nó? Gem nào được recommend, cái nào bị discourage?
-
Search GitHub cho vài class gem cung cấp
Chúng được dùng như thế nào trong app thực tế? Có vẻ dễ dùng không? Hay dev khác phải hack around vấn đề trong gem?
Lúc này bạn nên thu hẹp xuống vài candidate còn lại.
Điều "chữa chút cảm xúc"
Tiêu chí này hơi subjective, vì vậy bạn phải tìm gem đúng cho project của bạn. Nhưng nếu miss ở đây, bạn sẽ hối hận sau.
-
Dựa trên ví dụ trong doc, thư viện có cảm giác Ruby-ish không?
Nó dùng Ruby idiom? Hay bạn cảm thấy như viết Java hay PHP? Điều này xảy ra cực kỳ thường với API wrapper.
-
Nó được xây từ các phần nhỏ làm việc tốt cùng nhau không?
Bạn có thể dùng object tác giả cho để build thứ tác giả chưa bao giờ nghĩ đến? Vì bạn có thể sẽ muốn.
-
Gem đã được dùng bởi gem khác đã có trong project bạn không?
Bonus, bạn vừa tiết kiệm integration time, và biết bạn không phải đấu với Bundler về versioning.
-
Gem có giả định về app bạn không? App bạn fit giả định đó, và sẽ luôn fit không?
Một số gem, như ActiveResource, giả định về API của server chúng nói chuyện. Khác, như ResourceController, giả định về việc controller sẽ làm gì. Gem làm giả định có thể làm bạn nhanh hơn và code đơn giản hơn–miễn những giả định đó hold. Nếu giả định trở nên không tương thích với app, bạn sẽ thấy mình mất ngày monkey patch, debug, và cuối cùng gỡ gem ra.
Whoa, đó là nhiều.
Ừ, có ton tiêu chí chọn gem tốt nhất cho project. Và bạn thường không phải qua tất cả. Hầu hết thời gian, bạn chỉ lên Ruby Toolbox chọn gem phổ biến nhất.
Nhưng có gem trở thành phần cốt lõi của app. HTTP library, database library, hoặc bất cứ thứ hứa hẹn làm controller sạch hơn. Và đáng để dành thời gian thêm đảm bảo những gem này sạch, maintain tốt, documented tốt, và fit mental model của bạn về cách chúng nên hoạt động.
Tôi để tất cả tiêu chí này trong Google Spreadsheet, để khi bạn cần chọn từ số lượng gem tương tự nhau choáng ngợp, bạn có thể dễ dàng so sánh. Bạn có thể lấy nó ở đây.