Принципи за развој на модерни апликации од NGINX. Дел 1

Здраво пријатели. Во пресрет на започнувањето на курсот „Бекнд развивач во PHP“, традиционално го споделуваме со вас преводот на корисен материјал.

Софтверот решава сè повеќе секојдневни проблеми, а истовремено станува сè покомплексен. Како што еднаш рече Марк Андресен, тоа го троши светот.

Како резултат на тоа, начинот на кој се развиваат и испорачуваат апликациите драматично се промени во текот на изминатите неколку години. Тоа беа поместувања на тектонски размери што резултираа со збир на принципи. Овие принципи се покажаа како корисни за градење тим, дизајнирање, развивање и доставување на вашата апликација до крајните корисници.

Принципите може да се сумираат на следниов начин: апликацијата мора да биде мала, базирана на веб и да има архитектура насочена кон развивачите. Со градење на овие три принципи, можете да создадете робусна, од крај до крај апликација која може брзо и безбедно да се достави до крајниот корисник и е лесно скалабилна и проширлива.

Секој од предложените принципи има голем број на аспекти за кои ќе разговараме за да покажеме како секој принцип придонесува за крајната цел за брзо испорака на сигурни апликации кои се лесни за одржување и употреба. Ќе ги разгледаме принципите во споредба со нивните спротивности за да разјасниме што значи да се каже: „Погрижете се да користите принцип на малечок".

Се надеваме дека оваа статија ќе ве охрабри да ги користите предложените принципи за градење модерни апликации кои ќе обезбедат унифициран дизајн пристап во контекст на постојано растечки технолошки оџак.

Со примена на овие принципи, ќе откриете дека ги искористите најновите трендови во развојот на софтвер, вклучувајќи го и DevOps за развој и испорака на апликации, употреба на контејнери (на пример, пристанишен работник) и рамки за оркестрација на контејнери (на пример, Кубернети), употреба на микроуслуги (вклучувајќи и Microservice Architecture nginx и мрежна комуникациска архитектура за микросервис апликации.

Што е модерна апликација?

Модерни апликации? Модерен оџак? Што точно значи „модерно“?

Повеќето програмери имаат само основно разбирање за тоа од што се состои модерната апликација, па затоа е неопходно јасно да се дефинира овој концепт.

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

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

Податоците мора да бидат достапни во заеднички, интероперабилен формат како што е JSON. API ги изложува објектите и услугите во јасна, организирана форма; на пример, RESTful API или GraphQL обезбедуваат пристоен интерфејс.

Современите апликации се изградени на модерен оџак, а модерен стек е стекот што поддржува такви апликации, соодветно. Овој оџак му овозможува на развивачот лесно да креира апликација со HTTP интерфејс и да ги исчисти крајните точки на API. Пристапот што ќе го изберете ќе и овозможи на вашата апликација лесно да прифаќа и испраќа податоци во JSON формат. Со други зборови, модерниот оџак одговара на елементите на апликацијата за дванаесет фактори микроуслуги.

Популарните верзии на овој тип на стек се засноваат на Јава, Пајтон, Јазол, Руби, 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