Принципи на разработка на съвременни приложения от NGINX. Част 1

Здравейте, приятели. В навечерието на старта на курса «Backend разработчик на PHP», традиционно споделяме с вас превод на полезен материал.

Софтверът решава все по-голям брой ежедневни задачи, ставайки все по-сложен. Както веднъж каза Марк Андресен, той поглъща света.

В резултат на това през последните години подходите към разработването и доставката на приложения сериозно се промениха. Това бяха тектонични промени, които доведоха до появата на набор от принципи. Тези принципи се оказаха полезни при формирането на екипи, проектирането, разработването и доставката на вашето приложение до крайния потребител.

Принципите могат да бъдат обобщени по следния начин: приложението трябва да бъде малко, мрежово и с архитектура, ориентирана към разработчика.Чрез тези три принципа можете да създадете надеждно, комплексно приложение, което може да бъде бързо и безопасно доставено на крайния потребител, а също така е лесно за мащабиране и разширяване.

Всеки от предложените принципи има редица аспекти, които ще обсъдим, за да покажем как всеки принцип спомага за постигане на крайната цел, която е бързата доставка на надеждни приложения, лесни за поддръжка и използване. Ще разглеждаме принципите в сравнение с техните противоположности, за да изясним какво означава, да речем, «Убедете се, че използвате принципа на малкостта.».

Надяваме се, че тази статия ще ви насърчи да използвате предложените принципи за изграждане на съвременни приложения, които осигуряват единен подход към проектирането в контекста на постоянно нарастващ стек технологии.

Прилагането на тези принципи ще покаже, че следвате последните тенденции в разработването на софтуер, включително подхода DevOps към разработка и доставка на приложения, използването на контейнери (например, Docker) и фреймворци за оркестрация на контейнери (например, Kubernetes), използването на микросервизи (включително Микросервисна Архитектура NGINX и архитектура за мрежова свързаност за микросервисни приложения.

Какво е съвременно приложение?

Съвременни приложения? Съвременен стек? Какво точно означава «съвременен»?

Повечето разработчици имат само обща представа за това какво представлява съвременната апликация, затова е необходимо да се даде ясно определение на това понятие.

Съвременната апликация поддържа множество клиенти, било то потребителски интерфейс на библиотеката JavaScript React, мобилно приложение за Android или iOS, или приложение, което се свързва с друго по API. Съвременната апликация предполага наличие на неопределен брой клиенти, за които осигурява данни или услуги.

Съвременната апликация предоставя API за достъп до исканите данни и услуги. API-то трябва да бъде непроменливо и постоянно, а не написано конкретно за специфично запитване от конкретен клиент. API-то е достъпно по HTTP(S) и осигурява достъп до всичките функционалности, налични в GUI или CLI.

Данните трябва да бъдат достъпни в общоприет, съвместим формат, като JSON. API-то предоставя обекти и услуги в разбираема, организирана форма; например, RESTful API или GraphQL осигуряват адекватен интерфейс.

Съвременните приложения се изграждат на съвременен стек, а съвременният стек е този, който поддържа такива приложения. Такъв стек позволява на разработчика лесно да създаде приложение с HTTP интерфейс и ясни крайни точки на API. Избраният подход ще позволи на вашето приложение лесно да приема и изпраща данни в JSON формат. С други думи, съвременният стек отговаря на елементите на Дванадесетфакторното приложение за микросервизи.

Популярни версии на този тип стек са базирани на Java, Python, Node, Ruby, PHP и Go. Микросервисната архитектура NGINX воплъщава пример за съвременен стек, реализиран на всеки от споменатите езици.

Обърнете внимание, че не пропагандираме изключително микросервисен подход. Много от вас работят с монолити, които трябва да се развиват, докато други се занимават с SOA приложения, които се разширяват и развиват, за да станат микросервисни приложения. Трети преминават към безсървърни приложения, а някои внедряват комбинации от горепосоченото. Принципите, изложени в статията, са приложими за всяка от тези системи с някои незначителни изменения.

Принципи

Сега, когато имаме общо разбиране за това какво представляват съвременните приложения и съвременният стек, е време да се запознаем с принципите на архитектурата и разработката, които ще ви бъдат от полза при създаването, внедряването и поддръжката на съвременно приложение.

Един от принципите гласи "създавайте малки приложения", да го наречем принцип на малкостта. Има невероятно сложни приложения, които се състоят от много активни компоненти. От своя страна, изграждането на приложение от малки дискретни компоненти улеснява проектирането, поддръжката и работата с него като цяло. (Обърнете внимание, че казахме "улеснява", а не "прави прост".)

Вторият принцип е, че можем да увеличим продуктивността на разработчиците, като им помогнем да се съсредоточат върху функциите, които разработват, освобождавайки ги от притеснения за инфраструктурата и CI/CD по време на внедряването. Така че, накратко, нашият подход е ориентиран към разработчиците.

Накрая, всичко свързано с вашето приложение трябва да бъде свързано с мрежата. През последните 20 години напреднахме значително към мрежовото бъдеще, тъй като мрежите станаха по-бързи, а приложенията по-сложни. Както вече изяснихме, съвременното приложение трябва да бъде използвано чрез мрежата от много различни клиенти. Прилагането на мрежово мислене в архитектурата предлага значителни предимства, които се съчетават добре с принцип на малкостта и концепцията за подхода, ориентиран към разработчиците.

Ако по време на разработването и внедряването на приложението имате предвид горепосочените принципи, ще имате неоспоримо предимство в развитието и предоставянето на продукта си.

Нека разгледаме тези три принципа по-подробно.

Принцип на малкостта

Човешкият мозък трудно възприема едновременно голямо количество информация. В психологията терминът когнитивна натовареност означава общото количество умствени усилия, необходими за запазването на информация в паметта. Намаляването на когнитивната натовареност на разработчиците е приоритетно, тъй като в такъв случай те могат да се съсредоточат върху решаването на проблема, вместо да държат в ума си текущата сложна модел на цялото приложение и разработваните функции.

Приложения се декомпозираят по следните причини:

• Намаляване на когнитивното натоварване на разработчиците;
• Ускоряване и опростяване на тестването;
• Бърза доставка на промени в приложението.

Има няколко начина за намаляване на когнитивното натоварване на разработчиците, и точно тук влиза в игра принципът на малкото.

И така, три начина за намаляване на когнитивното натоварване:

1. Намаляване на времевия интервал, който те трябва да обмислят при разработването на нова функция – колкото по-кратък е интервалът, толкова по-ниско е когнитивното натоварване.
2. Намаляване на количеството код, с който се работи едновременно – по-малко код – по-малко натоварване.
3. Опростяване на процеса по въвеждане на инкрементални промени в приложението.

Намаляване на времевите рамки за разработка

Нека се върнем към времето, когато методологията waterfall беше стандарт за разработка, и времевите рамки от шест месеца до две години за разработка или обновяване на приложение бяха обща практика. Обикновено първо инженерите прочитаха съответните документи, като спецификациите за продукта (PRD), справочния документ на системата (SRD), плана за архитектура и започнаха да обединяват всичките тези неща в една когнитивна модел, според която пишеха код. Когато изискванията и, съответно, архитектурата се променяха, беше необходимо да се положат сериозни усилия, за да се информира целият екип за актуализациите на когнитивния модел. Такива подходи в най-лошия случай можеха просто да парализират работата.

Най-голямата промяна в процеса на разработка на приложения беше внедряването на методологията agile. Една от основните характеристики на методологията agile е итеративната разработка. Това, от своя страна, води до намаляване на когнитивното натоварване на инженерите. Вместо да изисква от разработчиците да реализират приложението в един дълъг цикъл, agile този подход позволява фокусиране върху малки обеми код, които могат да бъдат бързо тествани и внедрявани, като в същото време получавате и обратна връзка. Когнитивното натоварване на приложението се е преместило от времевия интервал от шест месеца до две години, като се вземат предвид огромно количество спецификации, върху двуседмично добавяне или промени във функцията, насочени към по-размито разбиране за голямо приложение.

Преминаването от огромно приложение към конкретни малки функции, които могат да се завършат за две седмици, с поглед напред само към една функция от следващия спринт, е значителна промяна. Това повиши продуктивността на разработката, като същевременно намали когнитивното натоварване, което постоянно варира.

В методологията agile се предполага, че крайното приложение ще бъде донякъде променена версия на първоначалната концепция, заради което финалната точка на разработката непременно е неясна. Ясни и конкретни могат да бъдат само резултатите от всеки конкретен спринт.

Малки кодови бази

Следващата стъпка в намаляването на когнитивното натоварване е намаляването на кодовата база. Обикновено съвременните приложения са огромни – надеждно корпоративно приложение може да се състои от хиляди файлове и стотици хиляди редове код. В зависимост от организацията на файловете, връзките и зависимостите на кода и файловете могат да бъдат очевидни или обратното. Дори отстраняването на самото изпълнение на кода може да предизвика проблеми, в зависимост от използваните библиотеки и от това колко добре инструментите за отстраняване на грешки разграничават библиотеките/пакетите/модулите и потребителския код.

Създаването на работна ментална модел на кода на приложението може да отнеме значително време и отново да наложи голямо когнитивно натоварване върху разработчика. Това е особено характерно за монолитните кодови бази, където има много код, взаимодействието между функционалните компоненти на който не е ясно дефинирано, а разделението на обектите на внимание често е размито, защото не се спазват функционалните граници.

Един от ефективните начини за намаляване на когнитивното натоварване на инженерите е преминаването към микросервизна архитектура. В микросервизния подход всеки сервис се фокусира върху един набор от функции; при това смисълът на сервиза обикновено е ясен и разбираем. Границите на сервиза също са ясни – помнете, че комуникацията със сервиза става чрез API, така че данните, генерирани от един сервис, могат лесно да бъдат предадени на друг.

Взаимодействието с други услуги обикновено е ограничено до няколко потребителски услуги и няколко услуги на доставчика, които използват прости и ясни API повиквания, например чрез REST. Това означава, че когнитивната тежест за инженерите значително намалява. Най-трудната задача остава разбирането на модела на взаимодействие между услугите и начина, по който неща като транзакции се извършват в различни услуги. В крайна сметка, употребата на микросервизи намалява когнитивната тежест, като намалява обема на кода, обозначава ясни граници на услугите и осигурява разбиране на отношенията между потребители и доставчици.

Малки инкрементални промени

Последният елемент на принципа малки – е управлението на промените. Особено изкушение за разработчиците е да погледнат на кода (дори, възможно, на своя собствен, по-стар код) и да заявят: „Това е боклук, трябва да го пренапишем.“ Понякога това е правилното решение, а понякога не. То поставя на екипа разработчици бремето на глобална промяна на модела, което от своя страна води до значителна когнитивна тежест. По-добре е инженерите да се фокусират върху промените, които могат да направят в течение на спринта, за да могат своевременно да внедрят необходимата функционалност, макар и постепенно. Крайният продукт трябва да прилича на предварителния план, но с някои промени и тестове, за да отговаря на нуждите на клиента.

При писането на големи части от кода, понякога е невъзможно бързо да се доставят изменения, тъй като в игра влизат и други зависимости на системата. За да контролите потока на измененията, можете да използвате скриване на функционалността (feature hiding). Това всъщност означава, че функционалността е налична в продукцията, но не е достъпна чрез настройки на променливи от средата (env-var) или чрез друг механизъм за конфигурация. Ако кодът премине през всичките проверки за качество, той може да попадне в продукцията в скрито състояние. Въпреки това, тази стратегия работи само ако функциите в крайна сметка бъдат включени. В противен случай, те просто ще натрупат код и ще добавят когнитивно натоварване, с което разработчикът ще трябва да се справи, за да работи продуктивно. Управлението на промените и инкременталните изменения сами по себе си помагат за поддържане на когнитивното натоварване на разработчиците на приемливо ниво.

Инженерите трябва да преодолеят много трудности дори при просто внедряване на допълнителна функционалност. От страна на ръководството, разумно е да се намали излишното натоварване на екипа, за да може той да се концентрира върху основните елементи на функционалността. Има три неща, които можете да предприемете, за да помогнете на своя екип от разработчици:

1. Да използвате методология agile, за да ограничите времевите рамки, в които екипът трябва да се съсредоточи върху основните функции.
2. Да реализирате приложението си като няколко микросервиза. Това ще ограничи броя на внедряваните функции и ще укрепи границите, които задържат когнитивното натоварване по време на работа.
3. Предпочитайте инкрементални изменения пред големи и обемисти, променяйте малки парчета код. Използвайте скриване на функции, за да реализирате изменения, дори ако те не са видими веднага след добавянето.

Ако приложите принцип малости в работата си, екипът ви ще бъде много по-щастлив, по-добре ще се фокусира върху реализирането на необходимите функции и с по-голяма вероятност ще извършва качествени промени по-бързо. Но това не означава, че работата не може да стане сложна; понякога, напротив, внедряването на нов функционалност изисква модификация на няколко услуги, а този процес може да бъде по-сложен отколкото аналогичният в монолитна архитектура. Във всеки случай, предимствата от прилагането на подхода малост си заслужават.

Край на първа част.

Скоро ще публикуваме втора част от превода, а за сега очакваме вашите коментари и ви каним на ден на отворените врати, който ще се проведе днес в 20:00.

Източник: habr.com