Jak radzić sobie ze strachem przed uzależnieniem

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ść.

... 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.

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ę.

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”?

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.

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ę.

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.