Принципи за развој савремених апликација из НГИНКС-а. Део 1

Здраво пријатељи. У ишчекивању покретања курса „Позадински програмер у ПХП-у“, традиционално са вама делимо превод корисног материјала.

Софтвер решава све више свакодневних проблема, а истовремено постаје све сложенији. Као што је Марк Андреесен једном рекао, прождире свет.

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

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

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

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

Применом ових принципа, открићете да користите предности најновијих трендова у развоју софтвера, укључујући и ДевОпс за развој и испоруку апликација, коришћење контејнера (нпр. лучки радник) и оквири оркестрације контејнера (нпр. Кубернетес), коришћење микросервиса (укључујући микросервисну архитектуру НГИНКС и архитектура мрежне комуникације за микросервисне апликације.

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

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

Већина програмера има само основно разумевање од чега се састоји модерна апликација, тако да је неопходно јасно дефинисати овај концепт.

Модерна апликација подржава више клијената, било да се ради о корисничком интерфејсу који користи Реацт ЈаваСцрипт библиотеку, мобилној апликацији за Андроид или иОС или апликацији која се повезује са другом преко АПИ-ја. Савремена апликација подразумева неограничен број клијената за које пружа податке или услуге.

Модерна апликација пружа АПИ за приступ траженим подацима и услугама. АПИ треба да буде непроменљив и константан, а не написан посебно за одређени захтев одређеног клијента. АПИ је доступан преко ХТТП(С) и пружа приступ свим функцијама које се налазе у ГУИ или ЦЛИ.

Подаци морају бити доступни у уобичајеном, интероперабилном формату као што је ЈСОН. АПИ излаже објекте и услуге у јасном, организованом облику; на пример, РЕСТфул АПИ или ГрапхКЛ пружају пристојан интерфејс.

Модерне апликације су изграђене на модерном стеку, а модеран стек је стек који подржава такве апликације. Овај стек омогућава програмеру да лако креира апликацију са ХТТП интерфејсом и чистим АПИ крајњим тачкама. Приступ који одаберете омогућиће вашој апликацији да лако прихвати и пошаље податке у ЈСОН формату. Другим речима, савремени стек одговара елементима апликације дванаест фактора за микросервис.

Популарне верзије ове врсте стека засноване су на Јава, Питон, Чвор, рубин, PHP и Go. Микросервисна архитектура НГИНКС представља пример модерног стека имплементираног на сваком од наведених језика.

Имајте на уму да ми не заговарамо приступ чисто микросервисима. Многи од вас раде са монолитима који треба да се развијају, док се други баве СОА апликацијама које се шире и еволуирају да би постале микросервисне апликације. Други се крећу ка апликацијама без сервера, а неки примењују комбинације горенаведеног. Принципи наведени у овом чланку се примењују на сваки од ових система уз само неколико мањих модификација.

Принципи

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

Један од принципа је „израда малих апликација“, назовимо то принцип малености. Постоје невероватно сложене апликације које имају много покретних делова. Заузврат, изградња апликације од малих, дискретних компоненти олакшава дизајн, одржавање и коришћење у целини. (Имајте на уму да смо рекли „чини га једноставним“, а не „чини га једноставним“).

Други принцип је да можемо повећати продуктивност програмера помажући им да се усредсреде на функције које развијају, док их ослобађамо бриге о инфраструктури и ЦИ/ЦД-у током имплементације. Дакле, укратко, наш приступ оријентисан на програмере.

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

Ако имате ове принципе на уму када дизајнирате и имплементирате апликацију, имаћете изразиту предност у развоју и испоруци вашег производа.

Погледајмо ова три принципа детаљније.

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

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

Апликације се разлажу из следећих разлога:

• Смањење когнитивног оптерећења програмера;
• Убрзање и поједностављење тестирања;
• Брза испорука измена у апликацији.

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

Дакле, три начина да се смањи когнитивно оптерећење:

1. Смањите временски оквир који морају узети у обзир приликом развоја нове функције – што је краћи временски оквир, то је ниже когнитивно оптерећење.
2. Смањите количину кода на којем се истовремено ради - мање кода - мање оптерећења.
3. Поједноставите процес уношења инкременталних измена у вашу апликацију.

Смањени временски оквири развоја

Вратимо се у времена када је методологија waterfall је био стандард за процес развоја, а временски оквири од шест месеци до две године за развој или ажурирање апликације били су уобичајена пракса. Обично би инжењери прво прочитали релевантне документе као што су захтеви за производ (ПРД), референтни документ система (СРД), план архитектуре и почели да интегришу све ове ствари заједно у један когнитивни модел према којем су писали код. Како су се захтеви, а самим тим и архитектура, променили, морали су се уложити значајни напори да се цео тим информише о ажурирањима когнитивног модела. У најгорем случају, овај приступ би једноставно могао парализовати рад.

Највећа промена у процесу развоја апликација било је увођење агилне методологије. Једна од главних карактеристика методологије agile - Ово је итеративни развој. Заузврат, то доводи до смањења когнитивног оптерећења инжењера. Уместо да захтева од развојног тима да имплементира апликацију у једном дугом циклусу, agile Приступ вам омогућава да се усредсредите на мале количине кода који се могу брзо тестирати и применити, а истовремено добијате повратне информације. Когнитивно оптерећење апликације се померило са временског оквира од шест месеци на две године, са огромном количином спецификација, на двонедељно додавање или промену функције, циљајући на шире разумевање велике апликације.

Пребацивање фокуса са велике апликације на специфичне мале функције које се могу завршити у двонедељном спринту, гледајући унапред на не више од једне функције из следећег спринта на уму је значајна промена. Ово је омогућило повећање продуктивности развоја уз смањење когнитивног оптерећења које је стално флуктуирало.

У методологији agile Очекује се да ће коначна апликација бити мало модификована верзија оригиналног концепта, тако да је коначна тачка развоја нужно двосмислена. Само резултати сваког конкретног спринта могу бити јасни и прецизни.

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

Следећи корак у смањењу когнитивног оптерећења је смањење базе кода. Типично, модерне апликације су огромне — робусна, пословна апликација може се састојати од хиљада датотека и стотина хиљада линија кода. У зависности од организације датотека, везе и зависности између кода и датотека могу, али не морају бити очигледне. Чак и отклањање грешака у самом извршавању кода може бити проблематично, у зависности од библиотека које се користе и колико добро алати за отклањање грешака разликују библиотеке/пакете/модуле и кориснички код.

Изградња радног менталног модела кода апликације може да потраје значајно време, поново стављајући велико когнитивно оптерећење на програмера. Ово посебно важи за монолитне базе кода где постоји велика количина кода, интеракције између функционалних компоненти нису јасно дефинисане, а подела фокуса је често замагљена јер се функционалне границе не поштују.

Један ефикасан начин да се смањи когнитивно оптерећење инжењера је прелазак на архитектуру микросервиса. У приступу микросервиса, свака услуга се фокусира на један скуп функција; значење услуге је обично дефинисано и разумљиво. Границе услуге су такође јасне – запамтите да се комуникација са услугом обавља помоћу АПИ-ја, тако да се подаци које генерише једна услуга могу лако пренети на другу.

Интеракција са другим услугама је обично ограничена на неколико корисничких услуга и неколико услуга провајдера који користе једноставне и чисте АПИ позиве, као што је РЕСТ. То значи да је когнитивно оптерећење инжењера озбиљно смањено. Највећи изазов остаје разумевање модела интеракције услуге и начина на који се ствари попут трансакција дешавају у више услуга. На крају, коришћење микросервиса смањује когнитивно оптерећење смањењем количине кода, дефинисањем јасних граница услуге и пружањем увида у однос корисника и добављача.

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

Последњи елемент принципа мало је управљање променама. За програмере је посебно примамљиво да погледају базу кода (чак можда и свој, старији код) и кажу: „Ово је срање, морамо да препишемо целу ову ствар“. Понекад је то исправна одлука, а понекад није. То ставља терет промена глобалног модела на развојни тим, што заузврат доводи до великог когнитивног оптерећења. Боље је да се инжењери усредсреде на промене које могу да изврше током спринта, како би потом могли благовремено, мада постепено, да уведу неопходну функционалност. Финални производ треба да личи на унапред планирани, али са неким модификацијама и тестирањем како би одговарао потребама клијента.

Приликом поновног писања великих делова кода, понекад је немогуће брзо извршити промену јер друге системске зависности долазе у игру. Да бисте контролисали ток промена, можете користити сакривање функција. У основи, то значи да је функционалност присутна у продукцији, али није доступна кроз подешавања променљиве окружења (енв-вар) или било који други механизам конфигурације. Ако је код прошао све процесе контроле квалитета, може завршити у производњи у скривеном стању. Међутим, ова стратегија функционише само ако је функција на крају омогућена. У супротном, само ће затрпати код и додати когнитивно оптерећење са којим ће програмер морати да се носи да би био продуктиван. Управљање променама и саме инкременталне промене помажу да се когнитивно оптерећење програмера одржи на приступачном нивоу.

Инжењери морају да превазиђу многе потешкоће чак и када једноставно имплементирају додатну функционалност. Било би мудро да менаџмент смањи непотребно оптерећење тима како би се могао фокусирати на кључне елементе функционалности. Постоје три ствари које можете учинити да помогнете свом развојном тиму:

1. Користите методологију agile, да би се ограничио временски оквир у коме се тим мора фокусирати на кључне карактеристике.
2. Имплементирајте своју апликацију као неколико микросервиса. Ово ће ограничити број уведених функција и ојачати границе које садрже когнитивно оптерећење током рада.
3. Преферирајте инкременталне промене у односу на велике, гломазне, мењајте мале делове кода. Користите скривање функција да примените промене чак и ако неће бити видљиве одмах након што су додате.

Ако примените принцип мале величине у свом раду, ваш тим ће бити много срећнији, боље фокусиран на испоруку потребних функција и већа је вероватноћа да ће брже увести промене квалитета. Али то не значи да посао не може постати сложенији; понекад, напротив, увођење нове функционалности захтева модификацију неколико сервиса и овај процес може бити сложенији од сличног у монолитној архитектури. У сваком случају, предности коришћења приступа су мало вредне тога.

Крај првог дела.

Ускоро ћемо објавити други део превода, али сада чекамо ваше коментаре и позивамо вас на то Отворен дан, који ће се одржати данас у 20.00 часова.

Извор: ввв.хабр.цом