Các Nhà Phát Triển Thách Thức Định Kiến "Not Invented Here" Khi Chi Phí Phụ Thuộc Tăng Cao

Nhóm Cộng đồng BigGo
Các Nhà Phát Triển Thách Thức Định Kiến "Not Invented Here" Khi Chi Phí Phụ Thuộc Tăng Cao

Cộng đồng phát triển phần mềm đang ngày càng đặt câu hỏi về quan điểm thông thường rằng các phụ thuộc bên ngoài luôn tốt hơn việc xây dựng giải pháp nội bộ. Ngày càng nhiều nhà phát triển đang phản đối định kiến về hội chứng Not Invented Here ( NIH ), lập luận rằng việc viết mã tùy chỉnh thường có thể hiệu quả về chi phí hơn so với việc áp dụng các thư viện của bên thứ ba.

Chi Phí Ẩn Của Các Phụ Thuộc

Mặc dù các phụ thuộc hứa hẹn chức năng miễn phí, các nhà phát triển đang phát hiện ra rằng chúng đi kèm với những chi phí ẩn đáng kể. Việc học các thư viện phức tạp thường mất nhiều thời gian hơn so với việc viết các giải pháp tùy chỉnh đơn giản. Những thay đổi đột phá trong các phụ thuộc có thể kích hoạt việc viết lại mã hiện có một cách tốn kém. Việc triển khai trở nên phức tạp khi nhiều phụ thuộc cần được đóng gói và phân phối đến các máy khách.

Độ phức tạp tăng lên gấp bội khi các hệ thống containerization và bundling được giới thiệu chỉ để quản lý chuỗi phụ thuộc. Nhiều nhóm phát triển thấy mình dành nhiều thời gian hơn để quản lý cơ sở hạ tầng triển khai thay vì xây dựng các tính năng ứng dụng cốt lõi.

Các Yếu Tố Rủi Ro Phụ Thuộc

Phụ Thuộc Thương Mại:

  • Động cơ khóa chặt nhà cung cấp
  • Nguồn hỗ trợ duy nhất
  • Rủi ro liên tục kinh doanh
  • Chi phí dài hạn cao hơn

Chi Phí Phụ Thuộc Chung:

  • Đầu tư thời gian học tập
  • Quản lý thay đổi đột phá
  • Độ phức tạp triển khai
  • Rủi ro bảo mật chuỗi cung ứng
  • Tác động hiệu suất

Khung Đánh Giá Cho Quyết Định Phụ Thuộc Thông Minh

Các cuộc thảo luận cộng đồng đã nêu bật năm tiêu chí chính để đánh giá các phụ thuộc: tính phổ biến, tính ổn định, độ sâu, tính ergonomic và tính watertight. Tính phổ biến đề cập đến mức độ sẵn có rộng rãi của một phụ thuộc trên các môi trường đích. Tính ổn định đo lường tần suất xảy ra các thay đổi đột phá. Độ sâu xem xét lượng chức năng cơ bản sẽ khó tái tạo. Tính ergonomic đánh giá độ dễ chịu của API . Tính watertight kiểm tra xem abstraction có rò rỉ chi tiết triển khai hay không.

Một kỹ thuật để làm cho phần mềm mạnh mẽ hơn là giảm thiểu những gì phần mềm của bạn phụ thuộc vào – càng ít thứ có thể xảy ra sai sót, thì càng ít thứ sẽ xảy ra sai sót.

Các nhà phát triển lưu ý rằng những người ủng hộ phụ thuộc thường chỉ tập trung vào tính ergonomic trong khi bỏ qua các yếu tố quan trọng khác.

Ví dụ Đánh giá Dependencies Tốt

Lệnh gọi Hệ thống POSIX:

  • Tính phổ biến: Có sẵn trên Linux , Android , macOS , BSDs
  • Tính ổn định: Cực kỳ ổn định, hiếm khi có thay đổi gây lỗi
  • Độ sâu: Một lệnh gọi duy nhất ẩn đi hàng trăm nghìn dòng code kernel
  • Tính tiện dụng: Tạm được (quy ước C , nhiều flag)
  • Tính kín: Hầu hết tốt với một số ngoại lệ ở thiết bị lưu trữ

Nền tảng Web (HTML, CSS, JS, Web APIs):

  • Tính phổ biến: Nền tảng được triển khai rộng rãi nhất toàn cầu
  • Tính ổn định: Cam kết mạnh mẽ về khả năng tương thích ngược
  • Độ sâu: Viết browser tùy chỉnh là không khả thi
  • Tính tiện dụng: Đầy đủ với tài liệu xuất sắc
  • Tính kín: Tốt ngoại trừ các tương tác với file/audio/video

Các Phụ Thuộc Thương Mại Bị Xem Xét Kỹ Lưỡng

Các phụ thuộc trả phí đối mặt với sự hoài nghi đặc biệt từ cộng đồng nhà phát triển. Các giải pháp thương mại tạo ra rủi ro bị khóa nhà cung cấp, vì các công ty có động cơ tài chính để làm cho việc chuyển đổi trở nên tốn kém. Khi các nhà cung cấp ngừng hoạt động hoặc ngừng hỗ trợ, các dự án phụ thuộc vào giải pháp của họ sẽ đối mặt với rủi ro liên tục nghiêm trọng. Các lựa chọn thay thế mã nguồn mở, mặc dù không hoàn hảo, nhưng thường cung cấp tính ổn định lâu dài và hỗ trợ cộng đồng tốt hơn.

Các Phương Pháp Phụ Thuộc Tối Thiểu Thành Công

Các ví dụ thực tế chứng minh tính khả thi của các chiến lược phụ thuộc tối thiểu. TigerBeetle , một cơ sở dữ liệu tài chính, hoạt động với chính sách không phụ thuộc ngoài bộ công cụ cốt lõi. Phương pháp này loại bỏ rủi ro tấn công chuỗi cung ứng, cải thiện hiệu suất và giảm độ phức tạp cài đặt.

Chiến lược này hoạt động đặc biệt tốt cho cơ sở hạ tầng nền tảng, nơi chi phí phụ thuộc được khuếch đại trong toàn bộ ngăn xếp công nghệ. Các nhóm áp dụng phương pháp này đầu tư mạnh mẽ vào việc thành thạo các công cụ cốt lõi đã chọn thay vì học nhiều framework chuyên biệt.

Tìm Kiếm Sự Cân Bằng Phù Hợp

Cuộc thảo luận không ủng hộ việc tránh hoàn toàn các phụ thuộc. Các tiêu chuẩn như lệnh gọi hệ thống POSIX , mã điều khiển terminal và API nền tảng web đại diện cho các phụ thuộc xuất sắc do tính phổ biến, ổn định và độ sâu của chúng. Những thứ này cung cấp chức năng khổng lồ mà việc tái tạo sẽ không thực tế trong khi vẫn duy trì khả năng tương thích rộng rãi.

Chìa khóa nằm ở việc đánh giá phê phán. Mỗi quyết định phụ thuộc nên cân nhắc chi phí so với lợi ích, xem xét bảo trì lâu dài, độ phức tạp triển khai và yêu cầu cụ thể của dự án. Quản lý phụ thuộc thông minh có nghĩa là lựa chọn một cách khôn ngoan thay vì mặc định sử dụng các giải pháp bên ngoài.

Tham khảo: NIH Is Far Cheaper Than The Wrong Dependency