Làm thế nào để đối phó với nỗi sợ mất phụ thuộc

54

Nhóm tôi đang tạo các thành phần có thể được sử dụng bởi các đối tác của công ty để tích hợp với nền tảng của chúng tôi.

Vì vậy, tôi đồng ý chúng ta nên hết sức cẩn thận khi giới thiệu các phụ thuộc (bên thứ ba). Hiện tại chúng tôi không có sự phụ thuộc của bên thứ ba và chúng tôi phải ở mức API thấp nhất của khung.

Vài ví dụ:

Chúng tôi buộc phải ở mức API thấp nhất của khung (.NET Standard). Lý do đằng sau điều này là một nền tảng mới có thể đến một ngày chỉ hỗ trợ mức API rất thấp đó.
Chúng tôi đã triển khai các thành phần của riêng mình để (de) tuần tự hóa JSON và đang trong quá trình thực hiện tương tự cho JWT. Điều này có sẵn ở cấp độ cao hơn của API khung.
Chúng tôi đã triển khai một trình bao bọc xung quanh khung HTTP của thư viện chuẩn, vì chúng tôi không muốn phụ thuộc vào việc triển khai HTTP của thư viện chuẩn.
Tất cả các mã để ánh xạ tới / từ XML được viết "bằng tay", một lần nữa vì lý do tương tự.

Tôi cảm thấy chúng ta đang đưa nó đi quá xa. Tôi đang tự hỏi làm thế nào để đối phó với điều này vì điều này tôi nghĩ rằng điều này ảnh hưởng lớn đến vận tốc của chúng ta.

— Bertus
nguồn

20

Có một sự biện minh cho điều này (ví dụ, yêu cầu bên ngoài) hoặc nó được thực hiện do sự thiếu hiểu biết?

— Blrfl

6

Thực hiện một thử nghiệm với một phần nhỏ của codebase, tạo một lớp cô lập không cố gắng trở thành một thư viện chung, nhưng xác định một giao diện trừu tượng mô hình hóa nhu cầu của bạn; sau đó đặt cả triển khai của riêng bạn và phụ thuộc của bên thứ 3 vào đằng sau và so sánh cách hai phiên bản hoạt động / thực hiện. Cân nhắc những ưu và nhược điểm, đánh giá mức độ dễ dàng (hoặc khó) của việc hoán đổi việc thực hiện, sau đó đưa ra quyết định. Nói tóm lại, hãy thử nghiệm mọi thứ theo cách tương đối thấp, xem điều gì xảy ra, sau đó quyết định.

— Filip Milovanović

73

"Hiện tại chúng tôi không có sự phụ thuộc của bên thứ ba" Điều này luôn khiến tôi bật cười khi mọi người tuyên bố điều này. Tất nhiên rồi. Bạn chưa viết trình biên dịch, IDE, triển khai bất kỳ thư viện chuẩn nào. Bạn đã không viết bất kỳ đối tượng shard libs nào mà bạn sử dụng gián tiếp (hoặc trực tiếp). Khi bạn nhận ra phần mềm và thư viện của bên thứ 3 mà bạn phụ thuộc vào bao nhiêu, bạn có thể bỏ ý tưởng "phụ thuộc là xấu" và chỉ cần tận hưởng việc không phát minh lại bánh xe. Tôi sẽ chỉ gắn cờ các phụ thuộc mà bạn có, và sau đó hỏi tại sao chúng có thể chấp nhận được, nhưng phân tích json thì không.

— UKMonkey

8

Điều đó nói rằng có những mặt trái thay thế, giống như không bao giờ hoàn thành các dự án. Nhưng nó thúc đẩy việc làm phần mềm và việc làm :)

— soái ca thủ công

5

Bạn đúng rằng bạn đang lãng phí nỗ lực bằng cách phát minh lại phần mềm hàng hóa. Bạn đã sai ở chỗ điều này thậm chí không gần với "tránh tất cả các phụ thuộc". Nhóm Excel tại Microsoft đã từng viết trình biên dịch C của riêng họ để tránh phụ thuộc vào nhóm C tại Microsoft . Bạn đang phụ thuộc rất lớn vào hệ điều hành, khung công tác cấp cao, v.v.

— Eric Lippert

94

... Chúng tôi buộc phải ở mức API thấp nhất của khung (.NET Standard)

Điều này với tôi nhấn mạnh một thực tế rằng, không chỉ bạn có khả năng hạn chế bản thân quá nhiều, mà bạn còn có thể hướng đến một cú ngã khó chịu với cách tiếp cận của bạn.

.NET Standard thì không, và sẽ không bao giờ là " mức API thấp nhất của khung ". Bộ API hạn chế nhất cho .NET đạt được bằng cách tạo thư viện lớp di động nhắm mục tiêu Windows Phone và Silverlight.

Tùy thuộc vào phiên bản .NET Standard nào bạn đang nhắm mục tiêu, bạn có thể kết thúc với một bộ API rất phong phú tương thích với .NET Framework, .NET Core , Mono và Xamarin . Và có nhiều thư viện của bên thứ ba tương thích với .NET Standard, do đó sẽ hoạt động trên tất cả các nền tảng này.

Sau đó, có .NET Standard 2.1, có khả năng sẽ được phát hành vào mùa thu năm 2019. Nó sẽ được hỗ trợ bởi .NET Core, Mono và Xamarin. Nó sẽ không được hỗ trợ bởi bất kỳ phiên bản nào của .NET Framework , ít nhất là trong tương lai gần, và rất có thể luôn luôn như vậy. Vì vậy, trong tương lai gần, không phải là " mức API thấp nhất của khung ", .NET Standard sẽ thay thế khung và có các API không được hỗ trợ bởi cái sau.

Vì vậy, hãy cẩn thận với " Lý do đằng sau điều này là một nền tảng mới có thể đến một ngày chỉ hỗ trợ mức API rất thấp đó " vì thực tế rất có thể các nền tảng mới sẽ hỗ trợ API cấp cao hơn so với khung cũ.

Sau đó là vấn đề của các thư viện bên thứ ba. Ví dụ JSON.NET tương thích với .NET Standard. Bất kỳ thư viện nào tương thích với .NET Standard đều được đảm bảo - API-khôn ngoan - để hoạt động với tất cả các triển khai .NET tương thích với phiên bản .NET Standard đó. Vì vậy, bạn không đạt được khả năng tương thích bổ sung bằng cách không sử dụng nó và tạo thư viện JSON của bạn. Bạn chỉ cần tạo ra nhiều công việc hơn cho bản thân và chịu chi phí không cần thiết cho công ty của bạn.

Vì vậy, có, bạn chắc chắn đang đưa điều này quá xa trong quan điểm của tôi.

— David Arno
nguồn

16

"Bạn chỉ cần tạo ra nhiều công việc hơn cho bản thân và chịu chi phí không cần thiết cho công ty của bạn." - và các khoản nợ bảo mật. Có phải bộ mã hóa JSON của bạn gặp sự cố với tràn ngăn xếp nếu bạn cung cấp cho nó một đối tượng đệ quy? Trình phân tích cú pháp của bạn xử lý các ký tự thoát chính xác? Liệu nó có từ chối các nhân vật không được giải thoát mà nó nên? Làm thế nào về các nhân vật thay thế không ghép đôi? Nó có tràn ra khi JSON mã hóa một số lớn hơn 2 ^ 64 không? Hay nó chỉ là một cái evalbọc nhỏ xíu với một số kiểm tra độ tỉnh táo dễ bị bỏ qua?

— John Dvorak

4

"Bộ API hạn chế nhất cho .NET đạt được bằng cách tạo thư viện lớp di động nhắm mục tiêu Windows Phone và Silverlight." Tôi sẽ đi ra ngoài và nói rằng có ít nhất một số API trong tập hợp con đó không được hỗ trợ bởi tất cả các triển khai có thể tồn tại (và không ai quan tâm đến WinPhone hay Silvernight nữa, thậm chí không phải là microsoft). Sử dụng .NetSt Chuẩn 2.0 làm mục tiêu cho khung hiện đại có vẻ rất thận trọng và không đặc biệt hạn chế. Cập nhật lên 2.1 là một câu chuyện khác nhau nhưng không có dấu hiệu nào cho thấy họ sẽ làm như vậy.

— Voo

Ngoài các nền tảng trong tương lai có thể hỗ trợ nhiều hơn là ít hơn, phát triển cho tất cả những điều có thể xảy ra là vô cùng tốn kém (và dù sao bạn cũng có thể bỏ lỡ điều gì đó). Thay vào đó, phát triển mà không phát minh lại bánh xe sẽ tiết kiệm nhiều thời gian hơn là thích nghi với một số tình huống mới khi điều đó là cần thiết sẽ tốn kém.

— Jasper

51

Chúng tôi buộc phải ở mức API thấp nhất của khung (tiêu chuẩn .net). Lý do đằng sau điều này là một nền tảng mới có thể đến một ngày chỉ hỗ trợ mức API rất thấp đó.

Lý do ở đây là khá ngược. Các mức API cũ hơn, thấp hơn có nhiều khả năng trở nên lỗi thời và không được hỗ trợ so với các mức mới hơn. Mặc dù tôi đồng ý rằng việc giữ một cách thoải mái đằng sau "đỉnh cao" là điều hợp lý để đảm bảo mức độ tương thích hợp lý trong kịch bản mà bạn đề cập, không bao giờ tiến về phía trước là vượt quá.

Chúng tôi đã triển khai các thành phần của riêng mình để (de) tuần tự hóa JSON và đang trong quá trình thực hiện tương tự cho JWT. Điều này có sẵn ở cấp độ cao hơn của API khung. Chúng tôi đã triển khai một trình bao bọc xung quanh khung HTTP của thư viện chuẩn vì chúng tôi không muốn phụ thuộc vào sự thay đổi HTTP của thư viện chuẩn. Tất cả các mã để ánh xạ tới / từ XML được viết "bằng tay", một lần nữa vì lý do tương tự.

Đây là sự điên rồ . Ngay cả khi bạn không muốn sử dụng các chức năng thư viện tiêu chuẩn vì bất kỳ lý do gì, các thư viện nguồn mở vẫn tồn tại với các giấy phép tương thích thương mại thực hiện tất cả các điều trên. Chúng đã được viết, thử nghiệm rộng rãi từ quan điểm thiết kế API, bảo mật và chức năng và được sử dụng rộng rãi trong nhiều dự án khác.

Nếu điều tồi tệ nhất xảy ra và dự án đó biến mất hoặc ngừng duy trì, thì dù sao bạn cũng đã có mã để xây dựng thư viện và bạn chỉ định ai đó duy trì nó. Và bạn có thể vẫn ở một vị trí tốt hơn nhiều so với việc bạn tự lăn, vì trong thực tế, bạn sẽ có nhiều mã được kiểm tra, sạch hơn, dễ bảo trì hơn để chăm sóc.

Trong trường hợp nhiều khả năng là dự án được duy trì và các lỗi hoặc khai thác được tìm thấy trong các thư viện đó, bạn sẽ biết về chúng để có thể làm gì đó về nó - chẳng hạn như nâng cấp lên phiên bản mới hơn hoặc vá phiên bản của bạn với bản sửa lỗi nếu bạn đã lấy một bản sao.

— berry120
nguồn

3

Và ngay cả khi bạn không thể, chuyển sang thư viện khác vẫn dễ dàng và tốt hơn so với việc tự lăn.

— Cuộc đua nhẹ nhàng với Monica

5

Điểm tuyệt vời mà công cụ cấp thấp hơn chết nhanh hơn. Đó là toàn bộ quan điểm của việc thiết lập trừu tượng.

— Cuộc đua nhẹ nhàng với Monica

"Các mức API cũ hơn, thấp hơn có nhiều khả năng trở nên lỗi thời và không được hỗ trợ so với các mức mới hơn". Huh? Các tiêu chuẩn NetST được xây dựng chồng chéo lên nhau theo như tôi biết (có nghĩa là 2.0 là 1.3 + X). Ngoài ra các Tiêu chuẩn chỉ đơn giản là .. tiêu chuẩn, không triển khai. Thật vô nghĩa khi nói về một tiêu chuẩn trở nên không được hỗ trợ, tại hầu hết các triển khai cụ thể của tiêu chuẩn đó có thể là trong tương lai (nhưng hãy xem điểm trước đó tại sao điều đó cũng không phải là một mối quan tâm). Nếu thư viện của bạn không cần bất cứ thứ gì ngoài NetSt Chuẩn 1.3, hoàn toàn không có lý do gì để thay đổi nó thành 2.0

— Voo

11

Trên tất cả những điều này là tốt cho khách hàng của bạn. Ngay cả một thư viện mã nguồn mở phổ biến cũng có thể không sử dụng được cho họ vì một số lý do.

Ví dụ, họ có thể đã ký hợp đồng với khách hàng của họ hứa sẽ không sử dụng các sản phẩm nguồn mở.

Tuy nhiên, như bạn chỉ ra, các tính năng này không phải là không có chi phí.

Đến giờ đi chợ
Kích thước của gói
Hiệu suất

Tôi sẽ nêu ra những nhược điểm này và nói chuyện với khách hàng để tìm hiểu xem họ có thực sự cần mức độ tương thích uber mà bạn đang cung cấp hay không.

Nếu tất cả các khách hàng đã sử dụng Json.NET chẳng hạn, sau đó sử dụng nó trong sản phẩm của bạn chứ không phải mã khử lưu huỳnh của riêng bạn, giảm kích thước của nó và cải thiện nó.

Nếu bạn giới thiệu phiên bản thứ hai của sản phẩm, một phiên bản sử dụng thư viện của bên thứ ba cũng như phiên bản tương thích, bạn có thể đánh giá mức độ hấp thụ trên cả hai. Khách hàng sẽ sử dụng các bên thứ ba để có được các tính năng mới nhất sớm hơn một chút hay gắn bó với phiên bản 'tương thích'?

— Ewan
nguồn

11

Có, tôi rõ ràng đồng ý và tôi sẽ thêm "bảo mật" vào danh sách của bạn. Có một số tiềm năng mà bạn có thể giới thiệu một lỗ hổng trong mã của mình, đặc biệt là với những thứ như JSON / JWT, so với các khung được kiểm tra tốt và chắc chắn là thư viện chuẩn.

— Bertus

Vâng, thật khó để lập danh sách vì rõ ràng những thứ như bảo mật và hiệu suất có thể đi cả hai chiều. Nhưng có một sự xung đột lợi ích rõ ràng giữa các tính năng hoàn thiện và các thành phần bên trong được bảo đảm đầy đủ / được hiểu

— Ewan

12

"Họ có thể đã ký hợp đồng với khách hàng của họ hứa sẽ không sử dụng các sản phẩm nguồn mở" - họ đang sử dụng .NET Standard, đây là nguồn mở. Sẽ là một ý tưởng tồi khi ký hợp đồng đó khi bạn dựa trên toàn bộ sản phẩm của mình trên khung công tác nguồn mở.

— Stephen

Và mọi người vẫn làm điều đó

— Ewan

7

Câu trả lời ngắn gọn là bạn nên bắt đầu giới thiệu các phụ thuộc của bên thứ ba. Trong cuộc họp độc lập tiếp theo của bạn, hãy nói với mọi người rằng tuần tới tại nơi làm việc sẽ là niềm vui nhất họ có được trong nhiều năm - họ sẽ thay thế các thành phần JSON và XML bằng các giải pháp thư viện chuẩn, nguồn mở. Nói với mọi người rằng họ có ba ngày để thay thế thành phần JSON. Kỷ niệm sau khi nó được thực hiện. Có một bữa tiệc. Đây là giá trị kỷ niệm.

— Tầm nhìn đôi mập mập
nguồn

2

Đây có thể là lưỡi trong má nhưng nó không thực tế. Tôi gia nhập một công ty nơi một nhà phát triển "cấp cao" (chỉ có bằng giáo dục) đã giao nhiệm vụ cho một nhà phát triển cơ sở với việc viết một thư viện máy nhà nước. Nó đã có năm tháng phát triển trong đó và nó vẫn còn lỗi, vì vậy tôi đã tách nó ra và thay thế nó bằng một giải pháp chìa khóa trao tay trong vài ngày.

— Không có U

0

Về cơ bản tất cả là do nỗ lực so với rủi ro.

Bằng cách thêm một phụ thuộc bổ sung hoặc cập nhật khung của bạn hoặc sử dụng API cấp cao hơn, bạn giảm nỗ lực của mình nhưng bạn chấp nhận rủi ro. Vì vậy, tôi sẽ đề nghị làm một phân tích SWOT .

Điểm mạnh: Ít nỗ lực hơn, vì bạn không phải tự viết mã.
Điểm yếu: Nó không được thiết kế tùy chỉnh cho các nhu cầu đặc biệt của bạn như một giải pháp thủ công.
Cơ hội: Thời gian để thị trường nhỏ hơn. Bạn có thể thu lợi từ sự phát triển bên ngoài.
Đe dọa: Bạn có thể làm phiền khách hàng với sự phụ thuộc bổ sung.

Như bạn có thể thấy nỗ lực bổ sung để phát triển một giải pháp thủ công là một khoản đầu tư để giảm bớt các mối đe dọa của bạn. Bây giờ bạn có thể đưa ra một quyết định chiến lược.

— Đaminh
nguồn

-2

Tách các thư viện thành phần của bạn thành một bộ "Lõi", không có phụ thuộc (về cơ bản là những gì bạn đang làm hiện tại) và một bộ "Chung", có các phụ thuộc vào thư viện "Lõi" và bên thứ ba của bạn.

Theo cách đó, nếu ai đó chỉ muốn chức năng "Lõi", họ có thể có nó.

Nếu ai đó muốn chức năng "Chung", họ có thể có nó.

Và bạn có thể quản lý "Lõi" so với "Chung". Bạn có thể thêm chức năng nhanh hơn vào "Chung" và chuyển nó sang triển khai "Lõi" của riêng bạn nếu / khi nó có ý nghĩa để cung cấp triển khai của riêng bạn.

— Rùa1363
nguồn