Phải làm gì khi chức năng quan trọng của một phụ thuộc bị phá vỡ và cản trở sự phát triển?


12

Hôm qua tôi đã làm việc với một dự án API Rails 5 đang sử dụng thư viện hành vi như có thể gắn thẻ để cho phép mọi thứ có thẻ (như câu hỏi trên SE). Rails 5 hiện đang hỗ trợ alpha. Hiện tại có một PR để sửa một lỗi đang chờ để được sáp nhập vào master; lỗi này đã khiến chi nhánh tính năng của tôi tạm dừng hoàn thành giữa chừng - tôi không thể thực hiện bất kỳ chức năng nào của thư viện vì quá trình tải bị hỏng.

Để khắc phục nhanh, tôi chỉ cần sao chép repo, sửa vấn đề với cùng mã mà PR có và chỉ Gemfile của tôi (tệp kiểm soát phiên bản phụ thuộc) vào ngã ba Github của riêng tôi, cho đến khi lỗi cuối cùng được hợp nhất trở lại thành chủ.

Tôi đã may mắn rằng việc khắc phục rất đơn giản ( và ai đó đã thực hiện nó ), vì vậy tôi đã có thể khắc phục được vấn đề. Nhưng điều gì sẽ xảy ra nếu thư viện này rất quan trọng đối với sự phát triển ứng dụng của tôi? Điều gì xảy ra nếu lỗi phát sinh sự phát triển của tôi không phải là vấn đề phổ biến đối với người khác , vì vậy, bản sửa lỗi không xuất hiện nhanh chóng như lần này?

Hãy tưởng tượng rằng tính năng này cần được hoàn thành trước khi phát triển các tính năng phụ thuộc khác - bạn sẽ làm gì trong tình huống đó? Điều gì sẽ xảy ra nếu, đối với tôi, việc gắn thẻ là cực kỳ quan trọng đối với cụm từ phát triển tiếp theo, nơi mọi thứ khác đều dựa vào nó - nhưng sự phụ thuộc gắn thẻ bị lỗi cho cấu hình của tôi? Người ta làm gì khi chức năng quan trọng của một phụ thuộc cản trở sự phát triển của (a) tính năng (s)?

Và, chắc chắn, đấu kiếm trên ghế văn phòng trong nhiều giờ hoặc nhiều ngày không phải là một lựa chọn ...

Câu trả lời:


19

Đây là một trong những lý do bạn đang sử dụng phần mềm nguồn mở, phải không?

Bạn có thể đưa ra lập luận tương tự cho "chuyện gì sẽ xảy ra nếu thư viện nguồn đóng, độc quyền, đắt tiền của tôi đột nhiên bị đổ? Sẽ có ai đó ở [công ty phần mềm lớn, nguyên khối] để sửa nó cho tôi chứ?" Với phần mềm nguồn mở, ít nhất bạn có cơ hội tự sửa lỗi đó.

Nếu phần mềm của bạn có sự phụ thuộc quan trọng vào thư viện nguồn mở, có ba điều bạn có thể làm để giảm thiểu rủi ro:

  1. Làm quen với cơ sở mã, thậm chí có thể tự đóng góp. Đây là một lý do khác tại sao bạn chọn nguồn mở, phải không?

  2. Có một thư viện dự phòng nếu thư viện đầu tiên rơi xuống. Đây là lý do tại sao bạn lập trình để giao diện; để bạn có thể thay đổi việc thực hiện nếu bạn phải, phải không?

  3. Cân bằng mong muốn của bạn về khả năng ổn định so với nhu cầu ổn định của bạn (ví dụ: không sử dụng phần mềm alpha). Bạn biết những gì bạn đang nhận được vào, phải không?


Cảm ơn câu trả lời của bạn Robert; có, tôi đã quyết định sử dụng Rails 5 cho các tính năng mới của nó và đã không hoàn toàn lên kế hoạch cho dự án và không biết rằng thư viện này sẽ có vấn đề tương thích với Rails 5. Mặc dù vậy, tôi chỉ rời chi nhánh đó dưới dạng WIP và Tôi đang theo dõi repo Github để sửa lỗi. Tôi đoán một trong những bài học chính ở đây là lên kế hoạch tốt . Nếu tôi đã thực hiện nghiên cứu có giá trị hơn một giờ trước khi bắt đầu phát triển, tôi sẽ thấy vấn đề!
Chris Cirefice

11

Giải pháp để phát triển các ứng dụng mà lỗi hoặc thiếu tính năng có nguy cơ cao khiến công việc của bạn dừng lại là không sử dụng các thư viện rủi ro cao. Chán và què, tôi biết ..

Bạn nói đây là một bản phát hành alpha. Đừng sử dụng các bản phát hành alpha cho các dự án quan trọng. Nó thậm chí không phải là một phiên bản beta, hãy để một mình 1.0 vì vậy điều này sẽ được mong đợi. Toàn bộ quan điểm của giai đoạn này trong một dự án là tìm ra các vấn đề và làm cứng dự án.

Nếu bạn thấy mình trong tình huống này, về cơ bản bạn phải làm những gì bạn đã làm (chúng tôi đã làm chính xác điều tương tự). Sửa chữa nó và PR dự án.

Nhưng giải pháp là sử dụng các thư viện ổn định hơn với chức năng và API được hiểu hoặc ít nhất là duy trì khả năng tương thích ngược với phiên bản ổn định. Bạn nên cảnh giác tùy thuộc 100% vào điều gì đó mà bạn không kiểm soát được và yêu cầu phải thành công.


1

Thông thường nên ẩn các thư viện của bên thứ ba đằng sau bộ điều hợp hoặc trình bao bọc mà bạn tự viết. Điều này có lợi thế gấp đôi:

  • Bạn có thể trao đổi thư viện của bên thứ ba với một thư viện khác mà không thay đổi bất kỳ mã nào của bạn
  • Bạn có thể lập trình phần còn lại của mã dựa trên giao diện bộ điều hợp của riêng bạn. Trong trường hợp có vấn đề tạm thời với thư viện, chỉ cần cắm vào phiên bản sơ khai / giả hoặc đơn giản của chức năng thư viện. Theo cách đó, việc phát triểnkiểm tra các tính năng hạ nguồn của bạn không bị chặn (mặc dù việc triển khai toàn bộ chương trình vẫn còn).
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.