Cześć przyjaciele. W oczekiwaniu na uruchomienie kursu , tradycyjnie podzielę się z Wami tłumaczeniem przydatnych materiałów.
Oprogramowanie rozwiązuje coraz więcej codziennych zadań, jednocześnie stając się coraz bardziej złożone. Jak powiedział kiedyś Marc Andressen, pochłania świat.
W rezultacie sposób tworzenia i dostarczania aplikacji zmienił się radykalnie w ciągu ostatnich kilku lat. Były to przesunięcia skali tektonicznej, które zaowocowały zestawem zasad. Zasady te okazały się pomocne w budowaniu zespołu, projektowaniu, rozwijaniu i dostarczaniu aplikacji użytkownikom końcowym.
Zasady można podsumować w następujący sposób: aplikacja powinna być mała, oparta na sieci Web i mieć architekturę zorientowaną na programistów. Pamiętając o tych trzech zasadach, możesz stworzyć solidną, kompleksową aplikację, którą można szybko i bezpiecznie dostarczyć użytkownikowi końcowemu, a także jest łatwo skalowalna i rozszerzalna.
Każda z proponowanych zasad ma szereg aspektów, które omówimy, aby pokazać, w jaki sposób każda zasada przyczynia się do osiągnięcia ostatecznego celu, jakim jest szybkie dostarczanie niezawodnych aplikacji, które są łatwe w utrzymaniu i użytkowaniu. Przyjrzymy się zasadom w odniesieniu do ich przeciwieństw, aby wyjaśnić, co to znaczy, powiedzmy: „Upewnij się, że używasz zasada małości".
Mamy nadzieję, że ten artykuł zachęci Państwa do skorzystania z proponowanych zasad budowania nowoczesnych aplikacji, które zapewnią ujednolicone podejście do projektowania w kontekście stale rosnącego stacku technologicznego.
Stosując te zasady, skorzystasz z najnowszych trendów w tworzeniu oprogramowania, w tym do tworzenia i dostarczania aplikacji, korzystania z kontenerów (np. ) i struktury orkiestracji kontenerów (np. ), wykorzystanie mikroserwisów (w tym Microservice Architecture и dla aplikacji mikroserwisowych.
Czym jest nowoczesna aplikacja?
Nowoczesne aplikacje? Nowoczesny stos? Co dokładnie oznacza „nowoczesny”?
Większość programistów ma tylko ogólne pojęcie o tym, z czego składa się nowoczesna aplikacja, dlatego konieczne jest jasne zdefiniowanie tego pojęcia.
Nowoczesna aplikacja obsługuje wielu klientów, niezależnie od tego, czy jest to interfejs użytkownika biblioteki React JavaScript, aplikacja mobilna na Androida lub iOS, czy aplikacja, która łączy się z innym interfejsem API. Nowoczesna aplikacja implikuje nieskończoną liczbę klientów, dla których udostępnia dane lub usługi.
Nowoczesna aplikacja udostępnia interfejs API umożliwiający dostęp do żądanych danych i usług. Interfejs API powinien być niezmienny i stały, a nie napisany specjalnie dla konkretnego żądania od konkretnego klienta. Interfejs API jest dostępny przez HTTP(S) i zapewnia dostęp do wszystkich funkcji dostępnych w GUI lub CLI.
Dane muszą być dostępne w powszechnie akceptowanym, interoperacyjnym formacie, takim jak JSON. Interfejs API eksponuje obiekty i usługi w przejrzysty, zorganizowany sposób, na przykład RESTful API lub GraphQL zapewniają przyzwoity interfejs.
Nowoczesne aplikacje są zbudowane na nowoczesnym stosie, a nowoczesny stos to odpowiednio stos obsługujący takie aplikacje. Ten stos umożliwia programistom łatwe tworzenie aplikacji z interfejsem HTTP i czystymi punktami końcowymi API. Wybrane podejście pozwoli Twojej aplikacji na łatwe odbieranie i wysyłanie danych w formacie JSON. Innymi słowy, współczesny stos odpowiada elementom Aplikacji Dwunastoczynnikowej .
Popularne wersje tego typu stosu oparte są na , , , , и . Architektura mikroserwisów reprezentuje przykład nowoczesnego stosu zaimplementowanego w każdym z wymienionych języków.
Należy pamiętać, że nie zalecamy podejścia opartego wyłącznie na mikrousługach. Wielu z was pracuje z monolitami, które muszą ewoluować, podczas gdy inni mają do czynienia z aplikacjami SOA, które rozwijają się i ewoluują, stając się aplikacjami mikrousługowymi. Jeszcze inni zmierzają w kierunku aplikacji bezserwerowych, a niektórzy wdrażają kombinacje powyższych. Zasady przedstawione w artykule mają zastosowanie do każdego z tych systemów z kilkoma niewielkimi modyfikacjami.
Zasady
Teraz, gdy mamy wspólne zrozumienie, czym jest nowoczesna aplikacja i nowoczesny stos, nadszedł czas, aby zagłębić się w architekturę i zasady programowania, które będą dobrze służyć podczas opracowywania, wdrażania i utrzymywania nowoczesnej aplikacji.
Jedna z zasad brzmi jak „rób małe aplikacje”, nazwijmy to po prostu zasada małości. Istnieją niezwykle złożone aplikacje, które składają się z wielu ruchomych części. Z kolei budowanie aplikacji z małych, dyskretnych komponentów ułatwia projektowanie, konserwację i pracę z nią jako całością. (Zauważ, że powiedzieliśmy „upraszcza”, a nie „ułatwia”).
Druga zasada polega na tym, że możemy zwiększyć produktywność programistów, pomagając im skupić się na rozwijanych funkcjach, jednocześnie uwalniając ich od infrastruktury i problemów związanych z CI/CD podczas wdrażania. A więc w skrócie nasze podejście koncentruje się na programistach.
Wreszcie, wszystko w Twojej aplikacji musi być podłączone do sieci. W ciągu ostatnich 20 lat poczyniliśmy ogromne postępy w kierunku sieciowej przyszłości, ponieważ sieci stają się szybsze, a aplikacje bardziej złożone. Jak widzieliśmy, nowoczesna aplikacja musi być używana w sieci przez wielu różnych klientów. Zastosowanie myślenia sieciowego w architekturze przynosi znaczące korzyści, z którymi dobrze się łączy zasada małości i koncepcja podejścia, zorientowany na dewelopera.
Jeśli będziesz pamiętał o tych zasadach podczas projektowania i wdrażania aplikacji, będziesz miał niezaprzeczalną przewagę w rozwoju i dostarczaniu swojego produktu.
Przyjrzyjmy się tym trzem zasadom bardziej szczegółowo.
zasada małości
Ludzkiemu mózgowi trudno jest odbierać dużą ilość informacji w tym samym czasie. W psychologii termin obciążenie poznawcze odnosi się do całkowitej ilości wysiłku umysłowego wymaganego do zachowania informacji w pamięci. Zmniejszenie obciążenia poznawczego programistów jest priorytetem, ponieważ pozwala im skupić się na rozwiązaniu problemu zamiast utrzymywania w głowie obecnego złożonego modelu całej aplikacji i rozwijanych funkcji.
Aplikacje rozkładają się z następujących powodów:
- Zmniejszone obciążenie poznawcze programistów;
- Przyspieszenie i uproszczenie testów;
- Szybkie dostarczanie zmian w aplikacji.
Istnieje kilka sposobów na zmniejszenie obciążenia poznawczego programistów i tutaj pojawia się zasada małości.
Oto trzy sposoby na zmniejszenie obciążenia poznawczego:
- Skróć ramy czasowe, które muszą wziąć pod uwagę przy opracowywaniu nowej funkcji – im krótsze ramy czasowe, tym mniejsze obciążenie poznawcze.
- Zmniejsz ilość kodu, na którym wykonywana jest jednorazowa praca - mniej kodu - mniejsze obciążenie.
- Uprość proces wprowadzania stopniowych zmian w aplikacji.
Skrócenie ram czasowych rozwoju
Wróćmy do czasów, kiedy metodologia waterfall był standardem procesu rozwoju, a ramy czasowe od sześciu miesięcy do dwóch lat na opracowanie lub aktualizację aplikacji były powszechną praktyką. Zazwyczaj inżynierowie najpierw czytają odpowiednie dokumenty, takie jak wymagania produktowe (PRD), dokument referencyjny systemu (SRD), schemat architektury i zaczynają łączyć wszystkie te rzeczy w jeden model poznawczy, zgodnie z którym kodowali. Wraz ze zmianą wymagań, a co za tym idzie architektury, trzeba było podjąć poważny wysiłek, aby informować cały zespół o aktualizacjach modelu kognitywnego. Takie podejście w najgorszym przypadku mogłoby po prostu sparaliżować pracę.
Największą zmianą w procesie tworzenia aplikacji było wprowadzenie metodyki zwinnej. Jedna z głównych cech metodologii agile jest rozwojem iteracyjnym. To z kolei prowadzi do zmniejszenia obciążenia poznawczego inżynierów. Zamiast wymagać od zespołu deweloperskiego wdrożenia aplikacji w jednym długim cyklu, agile podejście pozwala skupić się na niewielkich ilościach kodu, który można szybko przetestować i wdrożyć, jednocześnie otrzymując informacje zwrotne. Obciążenie poznawcze aplikacji przesunęło się z okresu od sześciu miesięcy do dwóch lat z ogromną liczbą specyfikacji dotyczących dwutygodniowego dodania lub zmiany funkcji, której celem jest bardziej niewyraźne zrozumienie dużej aplikacji.
Zmiana punktu ciężkości z ogromnej aplikacji na konkretne małe funkcje, które można ukończyć w dwutygodniowym sprincie, mając na uwadze nie więcej niż jedną funkcję przed następnym sprintem, to znacząca zmiana. Pozwoliło nam to zwiększyć produktywność rozwoju przy jednoczesnym zmniejszeniu obciążenia poznawczego, które stale się wahało.
W metodologii agile oczekuje się, że ostateczna aplikacja będzie nieco zmodyfikowaną wersją oryginalnej koncepcji, więc końcowy punkt rozwoju jest z konieczności niejednoznaczny. Tylko wyniki każdego konkretnego sprintu mogą być jasne i precyzyjne.
Małe bazy kodu
Następnym krokiem w zmniejszaniu obciążenia poznawczego jest zmniejszenie bazy kodu. Z reguły nowoczesne aplikacje są ogromne - solidna aplikacja korporacyjna może składać się z tysięcy plików i setek tysięcy linii kodu. W zależności od tego, jak pliki są zorganizowane, powiązania i zależności między kodem a plikami mogą być oczywiste lub odwrotnie. Nawet samo wykonanie kodu debugowania może być problematyczne, w zależności od używanych bibliotek i tego, jak dobrze narzędzia do debugowania rozróżniają biblioteki/pakiety/moduły i kod niestandardowy.
Zbudowanie działającego mentalnego modelu kodu aplikacji może zająć imponującą ilość czasu i po raz kolejny nałożyć duże obciążenie poznawcze na programistę. Jest to szczególnie prawdziwe w przypadku monolitycznych baz kodu, w których istnieje duża ilość kodu, którego interakcja między komponentami funkcjonalnymi nie jest jasno zdefiniowana, a oddzielenie obiektów uwagi jest często rozmyte, ponieważ granice funkcjonalne nie są przestrzegane.
Jednym ze skutecznych sposobów zmniejszenia obciążenia poznawczego inżynierów jest przejście na architekturę mikrousług. W podejściu opartym na mikrousługach każda usługa koncentruje się na jednym zestawie funkcji; natomiast znaczenie usługi jest zwykle określone i zrozumiałe. Granice usługi też są jasne – pamiętaj, że komunikacja z usługą odbywa się poprzez API, więc dane generowane przez jedną usługę można łatwo przekazać do innej.
Interakcja z innymi usługami jest zwykle ograniczona do kilku usług użytkownika i kilku usług dostawcy, które korzystają z prostych i czystych wywołań API, takich jak REST. Oznacza to, że obciążenie poznawcze inżyniera jest znacznie zmniejszone. Największym wyzwaniem pozostaje zrozumienie modelu interakcji usługi i sposobu, w jaki rzeczy takie jak transakcje odbywają się w wielu usługach. W rezultacie korzystanie z mikrousług zmniejsza obciążenie poznawcze, zmniejszając ilość kodu, definiując jasne granice usług i zapewniając zrozumienie relacji między użytkownikami a dostawcami.
Małe, stopniowe zmiany
Ostatni element zasady małostkowość jest zarządzanie zmianą. Szczególną pokusą dla programistów jest spojrzenie na bazę kodu (nawet być może ich własny, starszy kod) i stwierdzenie: „To bzdura, musimy to wszystko napisać od nowa”. Czasami jest to właściwa decyzja, a czasami nie. Nakłada ciężar globalnej zmiany modelu na zespół programistów, co z kolei prowadzi do ogromnego obciążenia poznawczego. Lepiej jest, aby inżynierowie skupili się na zmianach, które mogą wprowadzić podczas sprintu, aby mogli wdrażać niezbędne funkcje w odpowiednim czasie, choć stopniowo. Produkt końcowy powinien przypominać wcześniej zaplanowany, ale z pewnymi modyfikacjami i testami dostosowanymi do potrzeb klienta.
Podczas przepisywania dużych fragmentów kodu czasami nie jest możliwe szybkie wprowadzenie zmiany, ponieważ w grę wchodzą inne zależności systemowe. Aby kontrolować przebieg zmian, możesz użyć ukrywania cech. Zasadniczo oznacza to, że funkcjonalność jest w fazie produkcji, ale nie jest dostępna przy użyciu ustawień zmiennej środowiskowej (env-var) lub innego mechanizmu konfiguracyjnego. Jeśli kod przeszedł wszystkie procesy kontroli jakości, może trafić do produkcji w stanie utajonym. Jednak ta strategia działa tylko wtedy, gdy funkcja jest ostatecznie włączona. W przeciwnym razie zaśmieci to tylko kod i doda obciążenie poznawcze, z którym programista będzie musiał sobie poradzić, aby być produktywnym. Zarządzanie zmianami i same zmiany przyrostowe pomagają utrzymać obciążenie poznawcze programistów na przystępnym poziomie.
Inżynierowie muszą pokonać wiele trudności nawet przy prostym wprowadzeniu dodatkowej funkcjonalności. Ze strony kierownictwa rozsądne byłoby zmniejszenie niepotrzebnego obciążenia zespołu, aby mógł on skupić się na kluczowych elementach funkcjonalnych. Istnieją trzy rzeczy, które możesz zrobić, aby pomóc swojemu zespołowi programistów:
- Użyj metodologii
agileaby ograniczyć ramy czasowe, w których zespół musi skupić się na kluczowych funkcjach. - Zaimplementuj swoją aplikację jako wiele mikrousług. Ograniczy to liczbę funkcji, które można zaimplementować, i wzmocni granice, które utrzymują obciążenie poznawcze w pracy.
- Preferuj zmiany przyrostowe zamiast dużych i nieporęcznych, zmieniaj małe fragmenty kodu. Użyj ukrywania funkcji, aby zaimplementować zmiany, nawet jeśli nie będą one widoczne natychmiast po dodaniu.
Jeśli zastosujesz zasadę małości w swojej pracy, Twój zespół będzie znacznie szczęśliwszy, lepiej skupiony na wdrażaniu niezbędnych funkcji i bardziej skłonny do szybszego wdrażania zmian jakościowych. Nie oznacza to jednak, że praca nie może się bardziej skomplikować, wręcz przeciwnie, wprowadzenie nowej funkcjonalności wymaga modyfikacji kilku usług, a proces ten może być trudniejszy niż podobny w architekturze monolitycznej. W każdym razie korzyści płynące z przyjęcia podejścia małości są tego warte.
Koniec pierwszej części.
Wkrótce opublikujemy drugą część tłumaczenia, a teraz czekamy na Wasze komentarze i zapraszamy , która odbędzie się dzisiaj o godzinie 20.00.
Źródło: www.habr.com