Прывітанне, сябры. Напярэдадні запуску курса , традыцыйна дзелімся з вамі перакладам карыснага матэрыялу.
Праграмнае забеспячэнне вырашае ўсё больш і больш паўсядзённых задач, пры гэтым становячыся ўсё складаней і складаней. Як аднойчы сказаў Марк Андрэс, яно паглынае свет.
У выніку на працягу апошніх некалькіх гадоў падыходы да распрацоўкі і пастаўкі дадаткаў сур'ёзна змяніліся. Гэта былі зрухі тэктанічнага маштабу, якія ў выніку прывялі да з'яўлення набора прынцыпаў. Гэтыя прынцыпы аказаліся карыснымі ў фарміраванні каманды, праектаванні, распрацоўцы і дастаўцы вашага прыкладання канчатковым карыстальнікам.
Прынцыпы могуць быць абагульнены ў наступным выглядзе: прыкладанне павінна быць маленькім, сеткавым і мець архітэктуру, арыентаваную на распрацоўніка. Абапіраючыся на гэтыя тры прынцыпы вы можаце стварыць надзейнае, комплекснае прыкладанне, якое можа быць хутка і бяспечна дастаўлена канчатковаму карыстачу, а таксама лёгка маштабуецца і пашыраецца.
Кожны з прапанаваных прынцыпаў мае шэраг аспектаў, якія мы абмяркуем, каб паказаць, як кожны прынцып спрыяе дасягненню канчатковай мэты, якая заключаецца ў хуткай дастаўцы надзейных прыкладанняў простых у абслугоўванні і выкарыстанні. Мы будзем разглядаць прынцыпы ў параўнанні з іх супрацьлегласцямі, каб растлумачыць, што значыць, дапусцім, «Пераканайцеся, што вы карыстаецеся прынцып няшмат.
Мы спадзяемся, што гэты артыкул заахвоціць вас выкарыстоўваць прапанаваныя прынцыпы пабудовы сучасных прыкладанняў, якія забяспечаць адзіны падыход да праектавання ў кантэксце бесперапынна расце стэка тэхналогій.
Ужыўшы гэтыя прынцыпы, вы выявіце, што карыстаецеся апошнімі тэндэнцыямі ў распрацоўцы праграмнага забеспячэння, у тым ліку падыход да распрацоўкі і дастаўкі прыкладанняў, выкарыстанне кантэйнераў (напрыклад, ) і фрэймворкаў для аркестрацыі кантэйнераў (напрыклад, ), выкарыстанне мікрасэрвісаў (уключаючы Мікрасэрвісную Архітэктуру и для мікрасэрвісных прыкладанняў.
Што такое сучаснае дадатак?
Сучасныя прыкладанні? Сучасны стэк? Што менавіта азначае "сучасны"?
Большасць распрацоўшчыкаў маюць толькі агульнае ўяўленне аб тым, з чаго складаецца сучаснае прыкладанне, таму неабходна даць дакладнае вызначэнне гэтаму паняццю.
Сучаснае прыкладанне падтрымлівае некалькі кліентаў, няхай гэта будзе карыстацкі інтэрфейс на бібліятэцы JavaScript React, мабільнае прыкладанне пад Android або iOS, або дадатак, якое злучаецца з іншым па API. Сучаснае прыкладанне мае на ўвазе наяўнасць нявызначанай колькасці кліентаў, для якіх яно падае дадзеныя ці сэрвісы.
Сучаснае прыкладанне дае API для доступу да запытаных дадзеных і сэрвісаў. API павінна быць нязменным і пастаянным, а не напісаным канкрэтна пад спецыфічны запыт з нейкага канкрэтнага кліента. API даступны па HTTP(S) і забяспечвае доступ да ўсяго функцыяналу, які ёсць у GUI ці CLI.
Дадзеныя павінны быць даступныя ў агульнапрынятым, сумяшчальным фармаце, такім як JSON. API падае аб'екты і службы ў зразумелай, арганізаванай форме, да прыкладу, RESTful API ці GraphQL забяспечваюць годны інтэрфейс.
Сучасныя прыкладанні будуюцца на сучасным стэку, а сучасны стэк - гэта той стэк, які падтрымлівае такія прыкладанні, адпаведна. Такі стэк дазваляе распрацоўніку з лёгкасцю ствараць дадатак з HTTP інтэрфейсам і выразнымі канчатковымі кропкамі API. Абраны падыход дазволіць вашаму з дадаткам лёгка прымаць і адпраўляць дадзеныя ў фармаце JSON. Іншымі словамі, сучасны стэк адпавядае элементам Дванаццаці-Фактарнага прыкладання для .
Папулярныя версіі гэтага тыпу стэка заснаваныя на , , , , и . Мікрасэрвісная Архітэктура увасабляе прыклад сучаснага стэка, рэалізаванага на кожнай са згаданых моў.
Звярніце ўвагу, што мы не прапагандуем выключна мікрасэрвісны падыход. Многія з вас працуюць з маналітамі, якія павінны развівацца, у той час як іншыя маюць справу з SOA прыкладаннямі, якія пашыраюцца і развіваюцца, каб стаць мікрасэрвіснымі праграмамі. Трэція рухаюцца ў напрамку прымянення бессерверных (serverless) прыкладанняў, а некаторыя ўкараняюць камбінацыі з вышэйпералічанага. Прынцыпы, выкладзеныя ў артыкуле дастасавальныя да кожнай з гэтых сістэм толькі з некаторымі малаважнымі зменамі.
Прынцыпы
Цяпер, калі мы дабіліся агульнага разумення аб тым, што ж такое сучаснае прыкладання і сучасны стэк, настаў час пагрузіцца ў прынцыпы архітэктуры і распрацоўкі, якія саслужаць вам нядрэнную службу ў распрацоўцы, рэалізацыі і падтрымцы сучаснага прыкладання.
Адзін з прынцыпаў гучыць як "стварайце маленькія прыкладанні", давайце проста назавем яго прынцыпам драбніцы. Існуюць неверагодна складаныя прыкладанні, якія складаюцца з вялікай колькасці рухомых кампанентаў. У сваю чаргу пабудова дадатку з маленькіх дыскрэтных кампанентаў спрашчае яго праектаванне, абслугоўванне і працу з ім у цэлым. (Заўважце, мы сказалі "спрашчае", а не "робіць простым").
Другі прынцып заключаецца ў тым, што мы можам павялічыць прадуктыўнасць распрацоўшчыкаў, дапамагаючы ім засяродзіцца на тых функцыях, якія яны распрацоўваюць, пры гэтым вызваляючы іх ад клопатаў аб інфраструктуры і CI/CD падчас рэалізацыі. Такім чынам, у двух словах, наш падыход арыентаваны на распрацоўшчыкаў.
Нарэшце, усё, што тычыцца вашага дадатку, павінна быць падключана да сеткі. За апошнія 20 гадоў мы моцна рушылі да сеткавай будучыні, паколькі сеткі сталі хутчэй, а прыкладанні складаней. Як мы ўжо высветлілі, сучаснае прыкладанне павінна выкарыстоўвацца па сетцы мноствам розных кліентаў. Ужыванне сеткавага мыслення ў архітэктуры мае значныя перавагі, якія добра спалучаюцца з прынцыпам драбніцы і канцэпцыяй падыходу, арыентаванага на распрацоўшчыкаў.
Калі пры распрацоўцы і ўкараненні прыкладання вы будзеце памятаць аб названых прынцыпах, у вас будзе бясспрэчная перавага ў развіцці і пастаўцы свайго прадукта.
Давайце разгледзім гэтыя тры прынцыпы больш дэталёва.
Прынцып драбніцы
Чалавечаму мозгу складана ўспрымаць адначасова вялікую колькасць інфармацыі. У псіхалогіі тэрмін кагнітыўная нагрузка азначае агульную колькасць разумовых намаганняў, неабходных для захавання інфармацыі ў памяці. Зніжэнне кагнітыўнай нагрузкі на распрацоўшчыкаў з'яўляецца прыярытэтным, паколькі ў такім выпадку яны могуць засяродзіцца на вырашэнні праблемы, замест таго, каб утрымліваць у галаве бягучую комплексную мадэль ўсяго прыкладання і якія распрацоўваюцца функцыі.
Прыкладанні дэкампазуюцца па наступных прычынах:
- Паніжэнне кагнітыўнай нагрузкі на распрацоўшчыкаў;
- Паскарэнне і спрашчэнне тэсціравання;
- Хуткая дастаўка змен у дадатку.
Ёсць некалькі спосабаў зменшыць кагнітыўную нагрузку на распрацоўнікаў, і менавіта тут уступае ў гульню прынцып трохі.
Такім чынам, тры спосабу панізіць кагнітыўнай нагрузку:
- Паменшыць часавыя рамкі, якія яны павінны ўлічваць пры распрацоўцы новай функцыі - чым карацей таймфрэйм, тым ніжэй кагнітыўная нагрузка.
- Паменшыць колькасць кода над якім вядзецца аднаразовая праца - менш кода - менш нагрузка.
- Спрасціць працэс унясення інкрыментальных змен у дадатак.
Памяншэнне часавых рамак распрацоўкі
Вернемся ў тыя часы, калі метадалогія waterfall быў стандартам для працэсу распрацоўкі, і часовыя рамкі ад шасці месяцаў да двух гадоў для распрацоўкі або абнаўлення дадатку былі агульнай практыкай. Як правіла, спачатку інжынеры чыталі адпаведныя дакументы, такія як патрабаванні да прадукта (PRD), даведачны дакумент сістэмы (SRD), план архітэктуры і пачыналі аб'ядноўваць усе гэтыя рэчы разам у адну кагнітыўнай мадэль, у адпаведнасці з якой яны пісалі код. Па меры таго, як патрабаванні і, адпаведна, архітэктура мяняліся, даводзілася прыкладаць сур'ёзныя намаганні для інфармавання ўсёй каманды аб абнаўленнях кагнітыўнай мадэлі. Такі падыход у горшым выпадку мог проста паралізаваць працу.
Самай вялікай зменай у працэсе распрацоўцы прыкладанняў стала ўкараненне метадалогіі agile. Адна з асноўных асаблівасцяў метадалогіі agile - гэта ітэратыўная распрацоўка. У сваю чаргу, гэта прыводзіць да зніжэння кагнітыўнай нагрузкі на інжынераў. Замест таго, каб патрабаваць ад каманды распрацоўшчыкаў рэалізацыі прыкладання за адзін доўгі цыкл, agile падыход дазваляе засяродзіцца на маленькіх аб'ёмах кода, якія можна хутка пратэставаць і разгарнуць, пры гэтым атрымаўшы яшчэ і зваротную сувязь. Кагнітыўная нагрузка прыкладання зрушылася з таймфрэйма ад шасці месяцаў да двух гадоў з улікам велізарнай колькасці спецыфікацый на двухтыднёвае даданне або змяненняў функцыі, арыентаванае на больш размытае разуменне аб буйным дадатку.
Зрушэнне фокусу з масіўнага прыкладання на канкрэтныя маленькія функцыі, якія могуць быць завершаны за двухтыднёвы спрынт, з зазіраннем наперад не больш чым на адну функцыю з наступнага спрынту ў галаве, з'яўляецца значнай зменай. Гэта дазволіла павысіць прадуктыўнасць распрацоўкі пры гэтым паменшыўшы кагнітыўную нагрузку, якая ўвесь час вагалася.
У метадалогіі agile мяркуецца, што канчатковае прыкладанне будзе некалькі змененай версіяй першапачатковай канцэпцыі, таму канчатковая кропка распрацоўкі абавязкова з'яўляецца неадназначнай. Яснымі і выразнымі могуць быць толькі вынікі кожнага канкрэтнага спрынту.
Невялікія кодавыя базы
Наступны крок у памяншэнні кагнітыўнай нагрузкі - гэта памяншэнне кодавай базы. Як правіла, сучасныя прыкладанні масіўныя - надзейнае, карпаратыўнае прыкладанне можа складацца з тысяч файлаў і сотняў тысяч радкоў кода. У залежнасці ад арганізацыі файлаў сувязі і залежнасці кода і файлаў могуць быць відавочнымі ці наадварот. Нават адладка самога выканання кода можа выклікаць праблемы, у залежнасці ад выкарыстоўваных бібліятэк і таго, наколькі добра сродкі адладкі размяжоўваюць бібліятэкі/пакеты/модулі і карыстацкі код.
Пабудова працоўнай ментальнай мадэлі кода прыкладання можа заняць вялікую колькасць часу, і ізноў ускласці на распрацоўніка вялікую кагнітыўнай нагрузку. Гэта асабліва характэрна для маналітных баз кода, дзе маецца вялікая колькасць кода, узаемадзеянне паміж функцыянальнымі кампанентамі якога выразна не вызначана, а падзел аб'ектаў увагі часта размыта, паколькі не выконваюцца функцыянальныя межы.
Адным з эфектыўных спосабаў зніжэння кагнітыўнай нагрузкі на інжынераў з'яўляецца пераход да мікрасэрвіснай архітэктуры. У мікрасэрвісным падыходзе кожны сэрвіс факусуецца на адным наборы функцый; пры гэтым сэнс сэрвісу звычайна вызначаны і зразумелы. Межы сэрвісу таксама ясныя - памятаеце, аб тым, што камунікацыя з сэрвісам ажыццяўляецца з дапамогай API, таму дадзеныя згенераваныя адным сэрвісам могуць лёгка быць перададзены ў іншы.
Узаемадзеянне з іншымі сэрвісамі звычайна абмежавана некалькімі карыстацкімі сэрвісамі і некалькімі сэрвісамі правайдэра, якія выкарыстоўваюць простыя і чыстыя API выклікі, напрыклад пры дапамозе REST. Значыць, кагнітыўная нагрузка на інжынера сур'ёзна змяншаецца. Самай складанай задачай застаецца разуменне мадэлі ўзаемадзеяння сэрвісаў і таго, як такія рэчы, як транзакцыі, адбываюцца ў некалькіх сэрвісах. Па выніку, выкарыстанне мікрасэрвісаў зніжае кагнітыўную нагрузку, памяншаючы колькасць кода, пазначаючы выразныя межы сэрвісу і забяспечваючы разуменне адносін карыстальнікаў і правайдэраў.
Маленькія інкрыментальныя змены
Апошні элемент прынцыпу драбніцы - гэта кіраванне зменамі. Адмысловай спакусай для распрацоўнікаў лічыцца паглядзець на базу кода (нават, магчыма, на свой уласны, больш стары код) і заявіць: "Гэта дзярмо, нам трэба гэта ўсё перапісаць." Часам гэта правільнае рашэнне, а часам не. Яно ўскладае на каманду распрацоўнікаў цяжар глабальнай змены мадэлі, што, у сваю чаргу, прыводзіць да маштабнай кагнітыўнай нагрузкі. Лепш, каб інжынеры засяроджваліся на зменах, якія яны могуць унесці на працягу спрынту, каб потым своечасова выкаціць неабходны функцыянал, няхай і паступова. Канчатковы прадукт павінен нагадваць папярэдне запланаваны, але з некаторымі зменамі і тэсціраваннем, каб адпавядаць патрэбам кліента.
Пры перапісванні вялікіх частак кода часам хутка ажыццявіць дастаўку змены аказваецца немагчымым, паколькі тут уступаюць у гульню іншыя залежнасці сістэмы. Для таго, каб кантраляваць струмень змен, можна выкарыстоўваць адключэнне функцыяналу (feature hiding). У прынцыпе, гэта значыць функцыянал ёсць на прадакшне, але ён недаступны пры дапамозе налад зменных асяроддзя (env-var) ці які-небудзь іншага механізму канфігурацыі. Калі код прайшоў усе працэсы праверкі якасці, то ён можа апынуцца ў прадакшэне ва ўтоеным стане. Аднак, гэтая стратэгія працуе, толькі калі функцыя ў канчатковым выніку будзе ўключана. У адваротным выпадку яна будзе толькі захламляць код і дадасць кагнітыўнай нагрузкі, з якой прыйдзецца зладзіцца распрацоўніку для прадуктыўнай працы. Кіраванне зменамі і інкрыментальныя змены самі па сабе дапамагаюць падтрымліваць кагнітыўную нагрузку распрацоўшчыкаў на даступным узроўні.
Інжынерам даводзіцца пераадольваць шмат цяжкасцей нават пры простым укараненні дадатковага функцыяналу. З боку кіраўніцтва разумным будзе зменшыць лішнюю нагрузку на каманду, каб яна магла засяродзіцца на ключавых элементах функцыяналу. Ёсць тры рэчы, якія вы можаце зрабіць, каб дапамагчы сваёй камандзе распрацоўшчыкаў:
- Выкарыстоўваць метадалогію
agile, Каб абмежаваць часавыя рамкі, у якія каманда павінна засяродзіцца на ключавых функцыях. - Рэалізаваць сваё прыкладанне ў якасці некалькіх мікрасэрвісаў. Гэта абмяжуе колькасць укараняемых функцый і ўмацуе межы, якія ўтрымліваюць кагнітыўнай нагрузкі падчас працы.
- Аддайце перавагу інкрыментальныя змены буйным і грувасткім, змяняйце невялікія кавалачкі кода. Ужывайце ўтойванне функцый, каб рэалізоўваць змены, нават калі яны не будуць бачныя адразу пасля дадання.
Калі вы ў сваёй працы ўжывяце прынцып трохі, ваша каманда стане куды шчаслівей, лепш сфакусуецца на рэалізацыі неабходных функцый і з большай верагоднасцю будзе хутчэй выкочваць якасныя змены. Але гэта не гаворыць аб тым, што праца не можа ўскладніцца, часам наадварот, укараненне новага функцыяналу патрабуе мадыфікацыі некалькіх сэрвісаў і гэты працэс можа быць складаней, чым аналагічны ў маналітнай архітэктуры. У любым выпадку, перавагі ад ужывання падыходу трохі таго каштуюць.
Канец першай часткі.
У хуткім часе апублікуем другую частку перакладу, а зараз чакаем вашыя каментары і запрашаем на , які пройдзе ўжо сёння а 20.00.
Крыніца: habr.com