„zmiana jest jedyną stałą …” – Heraclit (filozof)
narzędzia, biblioteki i frameworki, których używamy do budowania naszych aplikacji internetowych, różnią się drastycznie od tych, z których korzystaliśmy zaledwie kilka lat temu.
za kilka lat większość tych technologii ponownie ulegnie radykalnej zmianie. Jednak wielu z nas sprawia, że są one centralną, nierozerwalną częścią naszych aplikacji.
importujemy, używamy i dziedziczymy po frameworkach flavor-of-the-month tak, jakby wszystkie były wokół i niezmienione na zawsze. Cóż … nie są. I to jest problem.
po ponad 20 latach tworzenia, projektowania i tworzenia aplikacji internetowych, doceniłem dwie ważne prawdy:
- zewnętrzne zależności stanowią ogromne zagrożenie dla długoterminowej stabilności i rentowności każdej aplikacji.
- coraz trudniej — jeśli nie niemożliwie — zbudować jakąkolwiek nietrywialną aplikację bez wykorzystania zewnętrznych zależności.
ten artykuł jest o pogodzeniu tych dwóch prawd, aby nasze aplikacje miały największą szansę na długoterminowe przetrwanie.
królicza Nora jest naprawdę bardzo głęboka.
jeśli zaczniemy myśleć o wszystkich rzeczach, od których zależą nasze aplikacje internetowe, łatwo będzie pomyśleć o kilkunastu lub więcej, zanim przejdziemy do kodu:
- Zasilanie
- łączność
- zapora ogniowa
- DNS
- sprzęt serwerowy (CPU, Dysk, Pamięć Ram, …)
- chłodzenie
- platforma wirtualizacji
- Platforma kontenerowa
- system operacyjny
- Platforma serwera www
- Platforma serwera aplikacji
- przeglądarka internetowa
jako Programiści dobrze jest mieć świadomość tych rzeczy, ale często niewiele możemy z nimi zrobić. Zignorujmy je na razie i porozmawiajmy tylko o kodzie.
w kodzie istnieją trzy rodzaje zależności:
1. Zależności, które kontrolujemy
jest to kod napisany i należący do nas lub naszej organizacji.
2. Zależności, których nie kontrolujemy
jest to kod napisany przez zewnętrznego dostawcę lub społeczność oprogramowania open-source.
3. Zależności po usunięciu
są to zależności kodu, od których zależą nasze zależności kodu innych firm. (Powiedz to trzy razy szybko!)
będziemy mówić głównie o zależnościach, których nie kontrolujemy.
zależności, które kontrolujemy i zależności po usunięciu mogą nadal powodować bóle głowy, ale w przypadku zależności, które kontrolujemy, powinniśmy być w stanie bezpośrednio interweniować i łagodzić wszelkie problemy.
w przypadku zależności po usunięciu, zwykle możemy polegać na osobie trzeciej, która zajmie się tym za nas, ponieważ są one również zależne od nich.
dlaczego zależności kodu innych firm są dobre
duża część twojej aplikacji internetowej istnieje, aby rozwiązać typowe problemy: uwierzytelnianie, Autoryzacja, dostęp do danych, obsługa błędów, nawigacja, logowanie, szyfrowanie, Wyświetlanie listy elementów, walidacja danych wejściowych formularza i tak dalej…
niezależnie od tego, z jakiego stosu technologii korzystasz, istnieje duża szansa, że wspólne rozwiązania tych problemów istnieją i są dostępne jako biblioteki, które możesz łatwo nabyć i podłączyć do swojej bazy kodu. Pisanie tych rzeczy całkowicie od zera jest na ogół stratą czasu.
chcesz skoncentrować się na kodzie, który albo rozwiązuje rzadki problem, albo rozwiązuje powszechny problem w Rzadki sposób. To właśnie sprawia, że Twoja aplikacja jest cenna: kod, który implementuje reguły biznesowe, które są unikalne dla Twojej aplikacji – ” secret sauce.”
algorytm wyszukiwania i rankingu stron Google, filtrowanie osi czasu Facebooka, sekcja „polecane dla Ciebie” Netflixa i algorytmy kompresji danych-Kod za wszystkimi tymi funkcjami to ” secret sauce.”
kod strony trzeciej-w postaci bibliotek — pozwala szybko zaimplementować te funkcje aplikacji, dzięki czemu możesz skupić się na swoim „tajnym sosie.”
dlaczego zależności kodu innych firm są złe
spójrz na dowolną nietrywialną aplikację internetową zbudowaną w ciągu ostatnich kilku lat, a będziesz absolutnie zdumiony ilością kodu, który faktycznie pochodzi z biblioteki innych firm. Co się stanie, jeśli jedna lub więcej z tych bibliotek zewnętrznych ulegnie drastycznej zmianie, zniknie lub pęknie?
jeśli to open-source, może sam to naprawisz. Ale jak dobrze rozumiesz cały kod w bibliotece, której nie posiadasz? Głównym powodem, dla którego korzystasz z biblioteki, jest czerpanie korzyści z kodu bez martwienia się o wszystkie szczegóły. Ale teraz utknąłeś. Całkowicie przywiązałeś swoją fortunę do tych zależności, których nie posiadasz i nie kontrolujesz.
może uważasz, że przesadzam, albo mówię z czysto akademickiego punktu widzenia. Zapewniam cię-mam dziesiątki przykładów klientów, którzy całkowicie węszyli, zbyt mocno osadzając kod innej firmy w swojej aplikacji. Oto tylko jeden ostatni przykład …
były klient mojego zbudowany swoją aplikację za pomocą Backend-as-a-service provider posiadanych przez Facebook, zwany Parse. Używali Biblioteki klienckiej JavaScript dostarczanej przez Parse do korzystania z usługi Parse. W tym procesie ściśle powiązali cały swój kod-w tym kod” secret sauce ” — z tą biblioteką.
trzy miesiące po pierwszym uruchomieniu produktu mojego klienta-tak jak zaczęli mieć dobrą trakcję z prawdziwymi, płacącymi klientami – parse ogłosił, że się zamyka.
teraz zamiast skupiać się na iteracji na swoim produkcie i rozwijaniu bazy klientów, mój klient musiał dowiedzieć się, jak albo przenieść się do samodzielnie hostowanej, otwartej wersji Parse, lub zastąpić Parse całkowicie.
zamieszanie, które spowodowało to dla młodej, raczkującej aplikacji, było tak ogromne, że mój klient ostatecznie całkowicie porzucił aplikację.
balansowanie na dobre i na złe
kilka lat temu, moim rozwiązaniem, aby przezwyciężyć ryzyko przy jednoczesnym zachowaniu korzyści z bibliotek innych firm, było owinięcie ich za pomocą wzoru adaptera.
zasadniczo kod strony trzeciej zawija się w napisaną klasę lub moduł adaptera. Następnie działa to w celu ujawnienia funkcji bibliotek stron trzecich w sposób, który kontrolujesz.
korzystając z tego wzorca, jeśli Biblioteka lub framework innej firmy ulegną zmianie lub znikną, musisz tylko naprawić kawałek kodu adaptera. Reszta aplikacji pozostaje nienaruszona.
to brzmi dobrze na papierze. Jeśli masz niezależne zależności, które zapewniają tylko kilka funkcji, to załatwi sprawę. Ale szybko może być nieprzyjemnie.
czy możesz sobie wyobrazić, że musisz owinąć całą bibliotekę Reactową (w tym JSX) przed użyciem jej? Co powiesz na zawijanie jQuery, Angular lub Spring framework w Javie? To szybko staje się koszmarem.
w dzisiejszych czasach polecam bardziej niuansowe podejście …
dla każdej zależności, którą chcesz dodać do swojej bazy kodu, Oceń poziom ryzyka, które wprowadzi, mnożąc dwa czynniki:
- prawdopodobieństwo, że zależność zmieni się w sposób materialny.
- ilość uszkodzeń, które spowodowałaby istotna zmiana zależności w Twojej aplikacji.
Biblioteka lub framework innych firm jest mniej podatny na zmiany, gdy niektóre lub wszystkie z poniższych rzeczy są prawdziwe:
- istnieje od kilku lat i ma kilka głównych wydawnictw.
- jest szeroko stosowany w wielu zastosowaniach komercyjnych.
- ma aktywne wsparcie dużej organizacji-najlepiej firmy lub instytucji.
Biblioteka lub framework innych firm wyrządzi mniej szkód w Twojej aplikacji, gdy niektóre lub wszystkie z poniższych rzeczy są prawdziwe:
- jest używany tylko przez niewielką część aplikacji, a nie jest używany przez cały czas.
- kod, który od niego zależy, nie jest częścią tego „tajnego sosu”, o którym mówiłem wcześniej.
- usunięcie go wymaga minimalnych zmian w kodzie.
- cała aplikacja jest bardzo mała i można ją szybko przepisać. (Uważaj z tym-rzadko jest to prawdą przez bardzo długi czas.)
im bardziej ryzykowne jest coś, tym bardziej prawdopodobne jest, że powinieneś to owinąć lub całkowicie uniknąć.
jeśli chodzi o kod, który jest naprawdę kluczowy dla propozycji wartości Twojej aplikacji-twojego „tajnego sosu” – musisz być bardzo opiekuńczy. Uczyń ten kod tak niezależnym, jak to tylko możliwe. Jeśli bezwzględnie potrzebujesz użyć zależności, rozważ jej wstrzyknięcie, a nie bezpośrednie odwoływanie się do niej. Nawet wtedy, bądź ostrożny.
czasami oznacza to powiedzenie „nie” bibliotece innej firmy, którą uważasz za naprawdę fajną lub którą naprawdę chcesz użyć z tego czy innego powodu. Bądź silny. Zaufaj mi, to się opłaci. Wystarczy zapytać wszystkich tych ludzi, którzy zainwestowali dużo w pierwszym wydaniu Angular, lub mój były klient, który używał Parse wszędzie. To nie jest zabawne. Uwierz mi.
skoro mowa o zabawie, to spójrz na to…
powyższy obrazek przedstawia wykres zależności dla aplikacji o nazwie Tinytag Explorer.
generowanie wykresu zależności dla istniejących aplikacji to świetny sposób na zrozumienie poziomu ryzyka wprowadzanego przez zależności. Zebrałem listę darmowych narzędzi do generowania wykresów podobnych do powyższych w różnych językach, w tym JavaScript, C#, Java, PHP i Python. Możesz go dostać tutaj.
Pomóż mi pomóc innym
chcę pomóc jak największej liczbie programistów, dzieląc się z nimi swoją wiedzą i doświadczeniem. Proszę o pomoc klikając przycisk recommend Poleć (zielone serce) poniżej.
na koniec, nie zapomnij pobrać listy darmowych generatorów grafów zależności tutaj.