Jak radzić sobie ze strachem przed uzależnieniem

54

Zespół, w którym pracuję, tworzy komponenty, które mogą być wykorzystywane przez partnerów firmy do integracji z naszą platformą.

W związku z tym zgadzam się, że powinniśmy zachować szczególną ostrożność przy wprowadzaniu zależności (stron trzecich). Obecnie nie mamy żadnych zależności od stron trzecich i musimy pozostać na najniższym poziomie API frameworka.

Kilka przykładów:

  • Jesteśmy zmuszeni pozostać na najniższym poziomie API frameworka (.NET Standard). Powodem tego jest to, że pewnego dnia może pojawić się nowa platforma, która obsługuje tylko bardzo niski poziom API.
  • Wdrożyliśmy własne komponenty do (de) serializacji JSON i właśnie robimy to samo dla JWT. Jest to dostępne na wyższym poziomie interfejsu API środowiska.
  • Wdrożyliśmy opakowanie wokół struktury HTTP standardowej biblioteki, ponieważ nie chcemy polegać na implementacji standardowej biblioteki HTTP.
  • Cały kod do mapowania do / z XML jest zapisywany „ręcznie”, znowu z tego samego powodu.

Wydaje mi się, że posuwamy się za daleko. Zastanawiam się, jak sobie z tym poradzić, ponieważ myślę, że to ma duży wpływ na naszą prędkość.

Bertus
źródło
20
Czy jest to uzasadnione (np. Wymóg zewnętrzny), czy też dzieje się to z niewiedzy?
Blrfl
6
Wykonaj eksperyment z małą częścią bazy kodu, utwórz warstwę izolacyjną, która nie próbuje być biblioteką ogólną, ale definiuje abstrakcyjny interfejs modelujący twoje potrzeby; następnie postaw za sobą zarówno własną implementację, jak i zależność innej firmy i porównaj, jak działają dwie wersje. Zważ zalety i wady, oceń, jak łatwo (lub jak ciężko) byłoby zamienić implementacje, a następnie podjąć decyzję. Krótko mówiąc, przetestuj to w sposób stosunkowo niewielki, zobacz, co się stanie, a następnie zdecyduj.
Filip Milovanović
73
„Obecnie nie mamy żadnych zależności od stron trzecich” To zawsze mnie rozśmiesza, gdy ludzie to twierdzą. Oczywiście, że tak. Nie napisałeś własnego kompilatora, IDE, implementacji żadnych standardowych bibliotek. Nie napisałeś żadnej biblioteki niezależnych obiektów, której używasz pośrednio (lub bezpośrednio). Kiedy zdasz sobie sprawę z tego, na ile oprogramowanie i biblioteki innych firm, na których polegasz, możesz porzucić ideę „zależności są złe” i po prostu czerpać przyjemność z nieinstruowania koła. Chciałbym po prostu oznaczyć zależności, które masz, a następnie zapytać, dlaczego są one dopuszczalne, ale analiza json nie jest.
UKMonkey
8
To powiedziawszy, istnieją alternatywne wady, takie jak nigdy nie kończenie projektów. Ale to promuje pracę oprogramowania i zatrudnienie :)
marszałek
5
Masz rację, że marnujesz wysiłek, odkrywając na nowo oprogramowanie towarowe. Mylisz się, ponieważ nie jest to nawet bliskie „unikania wszystkich zależności”. Zespół programu Excel w firmie Microsoft napisał kiedyś własny kompilator języka C, aby uniknąć uzależnienia od zespołu języka C w firmie Microsoft . Bierzesz ogromne zależności od systemów operacyjnych, frameworków wysokiego poziomu i tak dalej.
Eric Lippert,

Odpowiedzi:

94

... Jesteśmy zmuszeni pozostać na najniższym poziomie interfejsu API (standard .NET)…

To dla mnie podkreśla fakt, że nie tylko potencjalnie zbytnio się ograniczacie, ale również może podążać w kierunku paskudnego upadku.

.NET Standard nie jest i nigdy nie będzie „ najniższym poziomem API frameworka ”. Najbardziej restrykcyjny zestaw interfejsów API dla platformy .NET można osiągnąć, tworząc przenośną bibliotekę klas przeznaczoną dla systemów Windows Phone i Silverlight.

W zależności od wersji docelowej wersji .NET Standard możesz uzyskać bardzo bogaty zestaw interfejsów API zgodnych z .NET Framework, .NET Core , Mono i Xamarin . Istnieje wiele bibliotek innych firm, które są zgodne z .NET Standard, które będą działać na wszystkich tych platformach.

Potem jest .NET Standard 2.1, który prawdopodobnie zostanie wydany jesienią 2019 roku. Będzie obsługiwany przez .NET Core, Mono i Xamarin. Nie będzie obsługiwany przez żadną wersję .NET Framework , przynajmniej w dającej się przewidzieć przyszłości, i całkiem prawdopodobne, że zawsze. W najbliższej przyszłości, nie będąc „ najniższym poziomem API frameworka ”, .NET Standard zastąpi frameworki i będzie posiadał interfejsy API, które nie są obsługiwane przez ten ostatni.

Bądź więc bardzo ostrożny z „ Powodem tego jest to, że pewnego dnia może nadejść nowa platforma, która obsługuje tylko ten bardzo niski poziom API ”, ponieważ jest całkiem prawdopodobne, że nowe platformy będą w rzeczywistości obsługiwały API wyższego poziomu niż stare ramy.

Potem jest kwestia bibliotek stron trzecich. Na przykład JSON.NET jest zgodny ze standardem .NET. Każda biblioteka zgodna z .NET Standard jest gwarantowana - pod względem API - do pracy ze wszystkimi implementacjami .NET, które są kompatybilne z tą wersją .NET Standard. Dzięki temu nie osiągasz żadnej dodatkowej kompatybilności, nieużywając go i tworząc bibliotekę JSON. Po prostu stwarzasz sobie więcej pracy i ponosisz niepotrzebne koszty dla swojej firmy.

Tak, moim zdaniem zdecydowanie posuwasz się za daleko.

David Arno
źródło
16
„Po prostu stwarzasz sobie więcej pracy i ponosisz niepotrzebne koszty dla swojej firmy”. - i zobowiązania z tytułu zabezpieczeń. Czy koder JSON ulega awarii z przepełnieniem stosu, jeśli zostanie mu nadany obiekt rekurencyjny? Czy Twój parser poprawnie obsługuje znaki specjalne? Czy odrzuca nieskalowane postacie, które powinien? Co powiesz na niesparowane postacie zastępcze? Czy przepełnia się, gdy JSON koduje liczbę większą niż 2 ^ 64? A może to tylko małe evalopakowanie z kilkoma kontrolami poczytalności, które można łatwo ominąć?
John Dvorak
4
„Najbardziej restrykcyjny zestaw interfejsów API dla platformy .NET można osiągnąć, tworząc przenośną bibliotekę klas przeznaczoną dla systemów Windows Phone i Silverlight”. Wychodzę na całość i twierdzę, że w tym podzbiorze są co najmniej niektóre interfejsy API, które nie są obsługiwane przez wszystkie możliwe implementacje, które kiedykolwiek istniały (i nikt już nie dba o WinPhone lub Silvernight, nawet Microsoft). Używanie .NetStandard 2.0 jako celu dla nowoczesnego frameworka wydaje się bardzo ostrożne i nie jest szczególnie ograniczające. Aktualizacja do wersji 2.1 to inna historia, ale nic nie wskazuje na to, by to zrobili.
Voo
Oprócz przyszłych platform, które prawdopodobnie obsługują więcej niż mniej, opracowywanie wszystkich rzeczy, które mogą się zdarzyć, jest niezwykle kosztowne (i i tak prawdopodobnie coś przegapisz). Zamiast tego opracowywanie bez wymyślania na nowo koła pozwoli zaoszczędzić więcej czasu niż dostosowanie się do nowej sytuacji, gdy będzie to potrzebne, będzie kosztować.
Jasper
51

Jesteśmy zmuszeni pozostać na najniższym poziomie interfejsu API (standard .net). Powodem tego jest to, że pewnego dnia może pojawić się nowa platforma, która obsługuje tylko bardzo niski poziom API.

Rozumowanie tutaj jest raczej wsteczne. Starsze, niższe poziomy API częściej stają się przestarzałe i nieobsługiwane niż nowsze. Chociaż zgadzam się, że pozostawanie w tyle za „najnowocześniejszym” rozwiązaniem jest rozsądne, aby zapewnić rozsądny poziom kompatybilności w wspomnianym scenariuszu, nigdy nie posuwać się naprzód.

Wdrożyliśmy własne komponenty do (de) serializacji JSON i właśnie robimy to samo dla JWT. Jest to dostępne na wyższym poziomie interfejsu API środowiska. Wdrożyliśmy opakowanie wokół struktury HTTP standardowej biblioteki, ponieważ nie chcemy polegać na impelemnacji HTTP standardowej biblioteki. Cały kod do mapowania do / z XML jest zapisywany „ręcznie”, znowu z tego samego powodu.

To jest szaleństwo . Nawet jeśli nie chcesz używać standardowych funkcji bibliotecznych z jakiegokolwiek powodu, istnieją biblioteki open source z licencjami zgodnymi ze standardami handlowymi, które wykonują wszystkie powyższe czynności. Zostały już napisane, gruntownie przetestowane pod kątem funkcjonalności, bezpieczeństwa i projektowania interfejsu API, a także szeroko stosowane w wielu innych projektach.

Jeśli zdarzy się najgorsze i ten projekt zniknie lub przestanie być utrzymywany, to i tak masz kod do zbudowania biblioteki i przypisujesz kogoś do jej obsługi. Prawdopodobnie nadal znajdujesz się w znacznie lepszej sytuacji, niż gdybyś sam sobie wyrzucił, ponieważ w rzeczywistości masz więcej sprawdzonego, czystszego i łatwiejszego w utrzymaniu kodu do opieki.

W znacznie bardziej prawdopodobnym scenariuszu, w którym projekt jest utrzymywany, a w bibliotekach znajdują się błędy lub exploity, będziesz o nich wiedział, więc możesz coś z tym zrobić - na przykład bezpłatne uaktualnienie do nowszej wersji lub łatanie wersji z poprawką, jeśli wykonałeś kopię.

berry120
źródło
3
Nawet jeśli nie możesz, przejście do innej biblioteki jest wciąż łatwiejsze i lepsze niż tworzenie własnej biblioteki.
Lekkość ściga się z Moniką
5
Doskonały punkt, że rzeczy na niższym poziomie giną szybciej. Taki jest cel tworzenia abstrakcji.
Lekkość ściga się z Moniką
„Starsze, niższe poziomy API częściej stają się przestarzałe i nieobsługiwane niż nowsze”. Co? NetStandardy są zbudowane jeden na drugim, o ile mi wiadomo (co oznacza, że ​​2.0 to 1.3 + X). Standardy to po prostu ... standardy, a nie implementacje. Nie ma sensu mówić o tym, że standard nie jest obsługiwany, co najwyżej jego konkretne implementacje mogą być w przyszłości (ale zobacz wcześniej, dlaczego to również nie stanowi problemu). Jeśli twoja biblioteka nie potrzebuje niczego poza NetStandard 1.3, nie ma absolutnie żadnego powodu, aby zmieniać ją na 2.0
Voo
11

Ogólnie rzecz biorąc, te rzeczy są dobre dla Twoich klientów. Z jakiegoś powodu nawet popularna biblioteka typu open source może być dla nich niemożliwa.

Na przykład mogli podpisać umowę ze swoimi klientami, obiecując, że nie będą używać produktów open source.

Jednak, jak zauważyłeś, funkcje te nie są bezpłatne.

  • Czas na rynek
  • Rozmiar paczki
  • Występ

Chciałbym poruszyć te wady i porozmawiać z klientami, aby dowiedzieć się, czy naprawdę potrzebują uber poziomów kompatybilności, które oferujesz.

Jeśli wszyscy klienci już korzystają na przykład z Json.NET, to użycie go w produkcie zamiast własnego kodu deserializacji powoduje zmniejszenie jego rozmiaru i ulepszenie.

Jeśli wprowadzisz drugą wersję swojego produktu, która korzysta z bibliotek stron trzecich, a także kompatybilną, możesz ocenić wykorzystanie obu. Czy klienci skorzystają z usług stron trzecich, aby uzyskać najnowsze funkcje nieco wcześniej, czy pozostaną w wersji „kompatybilnej”?

Ewan
źródło
11
Tak, oczywiście się zgadzam i dodałbym „bezpieczeństwo” do twojej listy. Istnieje pewien potencjał, że możesz wprowadzić lukę w kodzie, szczególnie w przypadku JSON / JWT, w porównaniu do dobrze przetestowanych frameworków i zdecydowanie standardowej biblioteki.
Bertus
Tak, trudno jest sporządzić listę, ponieważ rzeczy takie jak bezpieczeństwo i wydajność mogą iść w obie strony. Istnieje jednak oczywisty konflikt interesów między funkcjami wykończeniowymi a zapewnieniem pełnej funkcjonalności / zrozumienia komponentów wewnętrznych
Ewan
12
„mogli podpisać umowę ze swoimi klientami, obiecując, że nie będą używać produktów open source” - używają .NET Standard, który jest open source. Podpisanie tej umowy jest kiepskim pomysłem, gdy cały produkt opiera się na platformie open source.
Stephen
I nadal to robią ludzie
Ewan
7

Krótka odpowiedź brzmi: powinieneś zacząć wprowadzać zależności innych firm. Podczas następnego spotkania stand-up powiedz wszystkim, że następny tydzień w pracy będzie dla nich największą zabawą od lat - zastąpią komponenty JSON i XML standardowymi rozwiązaniami bibliotek typu open source. Powiedz wszystkim, że mają trzy dni na wymianę komponentu JSON. Świętuj po zakończeniu. Mieć imprezę. To jest warte świętowania.

Grubowarstwowy gruby Double Vision
źródło
2
To może być język w policzek, ale nie jest to nierealne. Dołączyłem do firmy, w której „starszy” deweloper (starszy tylko z wykształcenia) zlecił młodszemu twórcy napisanie biblioteki maszyn państwowych. Miał pięć miesięcy deweloperskich i wciąż był wadliwy, więc wyrwałem go i zastąpiłem go gotowym rozwiązaniem w ciągu kilku dni.
Nie U
0

Zasadniczo wszystko sprowadza się do wysiłku vs. ryzyka.

Dodając dodatkową zależność lub aktualizując platformę lub używając interfejsu API wyższego poziomu, zmniejszasz wysiłek, ale podejmujesz ryzyko. Sugerowałbym więc wykonanie analizy SWOT .

  • Mocne strony: Mniej wysiłku, ponieważ nie musisz sam go kodować.
  • Słabe strony: Nie jest tak specjalnie zaprojektowany dla twoich specjalnych potrzeb jak ręcznie wykonane rozwiązanie.
  • Możliwości: czas na wprowadzenie na rynek jest krótszy. Możesz skorzystać z zewnętrznych rozwiązań.
  • Zagrożenia: Możesz denerwować klientów dodatkowymi zależnościami.

Jak widać, dodatkowym wysiłkiem w celu opracowania ręcznie opracowanego rozwiązania jest inwestycja w obniżanie zagrożeń. Teraz możesz podjąć strategiczną decyzję.

Dominic Hofer
źródło
-2

Podziel biblioteki komponentów na zestaw „Core”, który nie ma zależności (zasadniczo to, co teraz robisz), i zestaw „Common”, które są zależne od bibliotek „Core” i bibliotek stron trzecich.

W ten sposób, jeśli ktoś chce tylko funkcji „Core”, może ją mieć.

Jeśli ktoś chce mieć „wspólną” funkcjonalność, może ją mieć.

I możesz zarządzać tym, co jest „Core” kontra „Common”. Możesz szybciej dodać funkcjonalność do „Wspólnej” i przenieść ją do własnej implementacji „Core”, jeśli / kiedy sensowne jest zapewnienie własnej implementacji.

Żółw1363
źródło