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

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

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

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

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

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

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

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

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

Модерни приложения? Модерен стек? Какво точно означава "модерен"?

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

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

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

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

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

Популярните версии на този тип стекове се основават на Ява, Питон, Възел, Рубин, PHP и Go. Архитектура на микросервизи Nginx представлява пример за модерен стек, реализиран на всеки от споменатите езици.

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

Принципи

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

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

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

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

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

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

Принцип на дребността

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скоро ще публикуваме втората част на превода, а сега очакваме вашите коментари и ви каним Отворен ден, което ще се състои днес от 20.00ч.

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