Салам достор. Курстун ачылышына карата , салттуу түрдө сиз менен пайдалуу материалдын котормосун бөлүшөт.
Программалык камсыздоо барган сайын татаалдашып, күнүмдүк милдеттерди чечет. Марк Андрессен айткандай, ал дүйнөнү жейт.
Натыйжада, тиркемелерди иштеп чыгуу жана жеткирүү жолу акыркы бир нече жылда кескин өзгөрдү. Бул бир катар принциптерди пайда кылган тектоникалык масштабдагы жылыштар болгон. Бул принциптер команда курууда, долбоорлоодо, иштеп чыгууда жана колдонмоңузду акыркы колдонуучуларга жеткирүүдө пайдалуу экени далилденген.
Принциптерди төмөнкүчө чагылдырууга болот: колдонмо кичинекей, интернетке негизделген жана иштеп чыгуучуларга багытталган архитектурага ээ болушу керек. Ушул үч принципти эске алуу менен, сиз акыркы колдонуучуга тез жана коопсуз жеткирилүүчү жана оңой масштабдалуучу жана кеңейтилүүчү бекем, аягына чейин тиркемени түзө аласыз.
Сунушталган принциптердин ар биринин бир катар аспектилери бар, аларды биз ар бир принцип акыркы максатка, башкача айтканда, сактоого жана колдонууга оңой ишенимдүү тиркемелерди тез жеткирүүгө кандайча салым кошоорун көрсөтүү үчүн талкуулайбыз. Бул эмнени билдирерин тактоо үчүн принциптерди алардын карама-каршы жактарына карата карап чыгабыз: "Колдонуу кичинекейлик принциби«.
Бул макала сизди заманбап тиркемелерди түзүү үчүн сунушталган принциптерди колдонууга үндөйт деп үмүттөнөбүз, бул дайыма өсүп жаткан технология стекинин контекстинде дизайнга бирдиктүү мамилени камсыз кылат.
Бул принциптерди колдонуу менен сиз программалык камсыздоону иштеп чыгуудагы акыркы тенденциялардан, анын ичинде тиркемелерди иштеп чыгууга жана жеткирүүгө, контейнерлерди колдонууга (мисалы, ) жана контейнердик оркестрлөө алкактары (мисалы, ), микросервистерди колдонуу (анын ичинде Микросервис архитектурасы и микросервис колдонмолору үчүн.
Заманбап колдонмо деген эмне?
Заманбап колдонмолор? Заманбап стек? "Заманбап" деген эмнени билдирет?
Көпчүлүк иштеп чыгуучулар заманбап тиркеме эмнеден турганы жөнүндө жалпы түшүнүккө ээ, ошондуктан бул түшүнүктү так аныктоо керек.
Заманбап колдонмо бир нече кардарларды колдойт, мейли ал React JavaScript китепканасынын колдонуучу интерфейси, Android же iOS мобилдик колдонмосу же башка API менен туташкан колдонмо. Заманбап тиркеме маалымат же кызматтарды камсыз кылган кардарлардын чексиз санын билдирет.
Заманбап колдонмо суралган маалыматтарга жана кызматтарга жетүү үчүн API менен камсыз кылат. API өзгөрүлгүс жана туруктуу болушу керек жана конкреттүү кардардан келген белгилүү бир суроо үчүн атайын жазылбашы керек. API HTTP(S) аркылуу жеткиликтүү жана GUI же CLIде жеткиликтүү болгон бардык функцияларга мүмкүнчүлүк берет.
Маалыматтар JSON сыяктуу жалпы кабыл алынган, өз ара аракеттенүүчү форматта болушу керек. API RESTful API же GraphQL сыяктуу таза, уюшкан түрдө объекттерди жана кызматтарды көрсөтөт.
Заманбап тиркемелер заманбап стекке курулган, ал эми заманбап стек тиешелүү түрдө мындай тиркемелерди колдогон стек болуп саналат. Бул стек иштеп чыгуучуга HTTP интерфейси жана так API акыркы чекиттери бар тиркемени оңой түзүүгө мүмкүндүк берет. Тандалган ыкма сиздин колдонмоңузга маалыматтарды JSON форматында оңой кабыл алууга жана жөнөтүүгө мүмкүндүк берет. Башкача айтканда, заманбап стек Он эки фактордук Колдонмонун элементтерине туура келет .
Бул типтеги стектин популярдуу версиялары негизделген , , , , и . Микросервис архитектурасы аталган тилдердин ар биринде ишке ашырылган заманбап стектин мисалын көрсөтөт.
Биз бир гана микросервис ыкмасын жактабай турганыбызды эске алыңыз. Көпчүлүгүңүздөр өзгөрүшү керек болгон монолиттер менен иштеп жатасыздар, ал эми башкалар микросервис тиркемелери болуу үчүн кеңейип, өнүгүп жаткан SOA тиркемелери менен иштешүүдө. Дагы башкалары серверсиз тиркемелерди көздөй жылып жатышат, ал эми кээ бирлери жогорудагылардын комбинацияларын ишке ашырууда. Макалада баяндалган принциптер бул системалардын ар бирине бир аз гана өзгөртүүлөр менен колдонулат.
негиздери
Заманбап тиркеме жана заманбап стек деген эмне экенин жалпы түшүнгөнүбүздөн кийин, заманбап тиркемени иштеп чыгууда, ишке ашырууда жана тейлөөдө сизге жакшы кызмат кыла турган архитектура жана өнүктүрүү принциптерине сүңгүүгө убакыт келди.
Принциптердин бири "кичинекей тиркемелерди жасоо" сыяктуу угулат, аны жөн эле атайлы кичинекейлик принциби. Көптөгөн кыймылдуу бөлүктөрдөн турган укмуштуудай татаал тиркемелер бар. Өз кезегинде, кичинекей, дискреттик компоненттерден тиркемени түзүү аны бүтүндөй долбоорлоону, тейлөөнү жана аны менен иштөөнү жеңилдетет. (Көңүл буруңуз, биз "жөнөкөйлөтөт" эмес, "жөнөкөй кылат" дедик).
Экинчи принцип - биз иштеп чыгуучулардын өндүрүмдүүлүгүн алар иштеп жаткан өзгөчөлүктөргө көңүл бурууга жардам берүү менен жогорулата алабыз, ошол эле учурда аларды ишке ашыруу учурунда инфраструктура жана CI/CD көйгөйлөрүнөн бошотуп алабыз. Ошентип, кыскача айтканда, биздин мамилебиз иштеп чыгуучуларга багытталган.
Акыр-аягы, колдонмоңуздун бардыгы тармакка туташкан болушу керек. Акыркы 20 жылдын ичинде биз тармактык келечекке карай чоң кадамдарды жасадык, анткени тармактар тезирээк болуп, тиркемелер татаалдашат. Көрүнүп тургандай, заманбап тиркемени көп түрдүү кардарлар бир тармак аркылуу колдонушу керек. Архитектурага тармактык ой жүгүртүүнү колдонуунун олуттуу артыкчылыктары бар, алар жакшы кичинекейлик принциби жана мамиле түшүнүгү, иштеп чыгуучуга багытталган.
Эгерде сиз тиркемени иштеп чыгууда жана ишке ашырууда ушул принциптерди эстен чыгарбасаңыз, сиз өзүңүздүн продуктуңузду иштеп чыгууда жана жеткирүүдө талашсыз артыкчылыкка ээ болосуз.
Бул үч принципти кененирээк карап көрөлү.
кичинекейлик принциби
Адамдын мээсинин бир эле учурда чоң көлөмдөгү маалыматты кабыл алуусу кыйын. Психологияда когнитивдик жүк деген термин маалыматты эс тутумда сактоо үчүн талап кылынган психикалык күчтүн жалпы көлөмүн билдирет. Иштеп чыгуучуларга когнитивдик жүктөмдү азайтуу артыкчылыктуу болуп саналат, анткени бул аларга бүт колдонмонун учурдагы татаал моделин жана алардын башында иштелип жаткан функцияларды сактоонун ордуна маселени чечүүгө көңүл бурууга мүмкүндүк берет.
Тиркемелер төмөнкү себептерден улам бузулат:
- Иштеп чыгуучуларга когнитивдик жүктөмдүн азайышы;
- тестирлөөнү тездетүү жана жөнөкөйлөтүү;
- Колдонмодогу өзгөртүүлөрдү тез жеткирүү.
Иштеп чыгуучуларга когнитивдик жүктү азайтуунун бир нече жолдору бар жана бул жерде кичинекейлик принциби ишке кирет.
Ошентип, бул жерде когнитивдик жүктү азайтуу үчүн үч жолу бар:
- Жаңы функцияны иштеп чыгууда алар эске алышы керек болгон убакыт алкагын кыскартыңыз - убакыт алкагы канчалык кыска болсо, когнитивдик жүк ошончолук төмөн болот.
- Бир жолку иш аткарылган коддун көлөмүн азайтыңыз - аз код - аз жүк.
- Колдонмого кошумча өзгөртүүлөрдү киргизүү процессин жөнөкөйлөтүү.
Иштеп чыгуу мөөнөтүн кыскартуу
Методика болгон күндөргө кайрылалы waterfall иштеп чыгуу процессинин стандарты болгон, ал эми тиркемени иштеп чыгуу же жаңыртуу үчүн алты айдан эки жылга чейинки мөөнөттөр кеңири таралган практика болгон. Адатта, инженерлер адегенде продукт талаптары (PRD), тутумдук маалымдама документи (SRD), архитектуралык схема сыяктуу тиешелүү документтерди окуп, булардын бардыгын коддогон бир когнитивдик моделге бириктире башташат. Талаптар жана, демек, архитектура өзгөргөндүктөн, когнитивдик моделдин жаңыртуулары жөнүндө бүт команданы маалымдоо үчүн олуттуу аракеттерди көрүү керек болчу. Мындай мамиле, эң жаманы, ишти жөн эле шал кылып коюшу мүмкүн.
Тиркемени иштеп чыгуу процессиндеги эң чоң өзгөрүү, ийкемдүү методологияны киргизүү болду. Методологиянын негизги өзгөчөлүктөрүнүн бири agile кайталануучу өнүгүү болуп саналат. Бул өз кезегинде инженерлердин когнитивдик жүктөмүнүн азайышына алып келет. Өнүктүрүү тобунан тиркемени бир узак циклде ишке ашырууну талап кылуунун ордуна, agile мамиле тез сыналып, жайылтыла турган аз өлчөмдөгү коддорго көңүл бурууга мүмкүндүк берет, ошол эле учурда пикирди кабыл алат. Колдонмонун когнитивдик жүгү алты айлык мөөнөттөн эки жылдык убакыт алкагына жылды, чоң колдонмону бүдөмүк түшүнүүгө багытталган эки жумалык кошуу же функцияларды өзгөртүү үчүн чоң көлөмдөгү мүнөздөмөлөр бар.
Фокусту массалык тиркемеден эки жумалык спринтте бүтүрө турган, кийинки спринттен бирден ашык эмес функцияны эске алуу менен бүтүрө турган конкреттүү кичинекей функцияларга которуу олуттуу өзгөрүү болуп саналат. Бул дайыма өзгөрүп турган когнитивдик жүктү азайтып, өнүгүүнүн өндүрүмдүүлүгүн жогорулатууга мүмкүндүк берди.
Методологияда agile акыркы колдонмо баштапкы концепциянын бир аз өзгөртүлгөн версиясы болушу күтүлөт, ошондуктан өнүгүүнүн акыркы чекити сөзсүз түрдө бүдөмүк. Ар бир конкреттүү спринттин жыйынтыгы гана так жана так болушу мүмкүн.
Чакан код базалары
Когнитивдик жүктү азайтуунун кийинки кадамы код базасын кыскартуу болуп саналат. Эреже катары, заманбап тиркемелер массивдүү болуп саналат - бекем, ишкана тиркеме миңдеген файлдардан жана жүз миңдеген код саптарынан турушу мүмкүн. Файлдар кантип уюштурулганына жараша, код менен файлдардын ортосундагы байланыштар жана көз карандылыктар айкын же тескерисинче болушу мүмкүн. Колдонулган китепканаларга жана мүчүлүштүктөрдү оңдоо куралдары китепканаларды/пакеттерди/модулдарды жана ыңгайлаштырылган кодду канчалык жакшы айырмалай тургандыгына жараша мүчүлүштүктөрдү оңдоо кодун аткаруунун өзү да көйгөйлүү болушу мүмкүн.
Тиркеменин кодунун жумушчу психикалык моделин түзүү таасирдүү убакытты талап кылат жана дагы бир жолу иштеп чыгуучуга чоң когнитивдик жүктү жүктөйт. Бул өзгөчө монолиттик коддук базаларга тиешелүү, мында көп сандагы код бар, анын функционалдык компоненттеринин ортосундагы өз ара аракеттенүү так аныкталбаган жана көңүл буруу объекттеринин бөлүнүшү көбүнчө функционалдык чектер сакталбагандыктан бүдөмүк.
Инженерлердеги когнитивдик жүктү азайтуунун натыйжалуу жолдорунун бири микросервис архитектурасына өтүү болуп саналат. Микросервис мамилесинде ар бир кызмат өзгөчөлүктөрдүн бир топтомуна багытталган; ал эми кызматтын мааниси адатта аныкталган жана түшүнүктүү. Кызматтын чек аралары да айкын - кызмат менен байланыш API аркылуу ишке ашарын унутпаңыз, андыктан бир кызмат тарабынан түзүлгөн маалыматтар оңой эле башкасына өтүшү мүмкүн.
Башка кызматтар менен өз ара аракеттенүү, адатта, REST колдонуу сыяктуу жөнөкөй жана таза API чалууларын колдонгон бир нече колдонуучу кызматтары жана бир нече провайдер кызматтары менен чектелет. Бул инженерге когнитивдик жүк олуттуу төмөндөйт дегенди билдирет. Эң чоң көйгөй кызматтын өз ара аракеттешүүсүнүн моделин жана транзакциялар сыяктуу нерселер бир нече кызматтарда кандай болуп жатканын түшүнүү бойдон калууда. Натыйжада, микросервистерди колдонуу когнитивдик жүктөмдү азайтып, коддун көлөмүн азайтып, кызматтын так чектерин аныктап, колдонуучулар менен провайдерлердин ортосундагы мамилени түшүнүүнү камсыздайт.
Кичинекей кошумча өзгөрүүлөр
Принциптин акыркы элементи кичинекейлик өзгөртүү башкаруу болуп саналат. Бул иштеп чыгуучулар үчүн код базасын (ал тургай өздөрүнүн, эски кодун да) карап, "Бул куру сөз, биз мунун баарын кайра жазышыбыз керек" деп айтуу өзгөчө азгырык. Кээде бул туура чечим болсо, кээде туура эмес. Бул глобалдык моделди өзгөртүү жүгүн иштеп чыгуу тобуна жүктөйт, бул өз кезегинде массалык когнитивдик жүктөмгө алып келет. Инженерлер спринт учурунда жасай ала турган өзгөрүүлөргө көңүл бурушу жакшы, алар акырындык менен болсо да керектүү функцияларды өз убагында жайылта алышат. Акыркы продукт алдын ала пландаштырылган окшош болушу керек, бирок кээ бир өзгөртүүлөр жана кардардын муктаждыктарына ылайык тестирлөө менен.
Коддун чоң бөлүктөрүн кайра жазып жатканда, кээде өзгөртүүнү тез жеткирүү мүмкүн эмес, анткени системанын башка көз карандылыгы ишке кирет. Өзгөртүүлөрдүн агымын көзөмөлдөө үчүн, сиз өзгөчөлүктү жашырууну колдоно аласыз. Негизи, бул функция өндүрүштө экенин билдирет, бирок ал чөйрө өзгөрмө орнотууларын (env-var) же башка конфигурация механизмин колдонуу менен жеткиликтүү эмес. Эгерде код бардык сапатты көзөмөлдөө процесстеринен өткөн болсо, анда ал өндүрүштө жашыруун абалда калышы мүмкүн. Бирок, бул стратегия өзгөчөлүк акыры иштетилгенде гана иштейт. Болбосо, ал кодду гана бузуп, иштеп чыгуучу жемиштүү болушу үчүн чече турган когнитивдик жүктү кошот. Өзгөртүүлөрдү башкаруу жана кошумча өзгөрүүлөрдүн өзү иштеп чыгуучулардын когнитивдик жүгүн жеткиликтүү деңгээлде кармап турууга жардам берет.
Инженерлер кошумча функцияларды жөнөкөй киргизүү менен да көптөгөн кыйынчылыктарды жеңүүгө туура келет. Жетекчилик тарабынан команданын негизги функционалдык элементтерине көңүл буруусу үчүн ашыкча жүктү кыскартуу акылдуулукка жатат. Өнүктүрүү тобуңузга жардам берүү үчүн үч нерсе кыла аласыз:
- Методологияны колдонуңуз
agileкоманда негизги өзгөчөлүктөргө бурууга тийиш болгон убакыт алкагын чектөө үчүн. - Колдонмоңузду бир нече микросервис катары ишке ашырыңыз. Бул ишке ашырыла турган функциялардын санын чектейт жана иштеги когнитивдик жүктү кармап турган чектерди бекемдейт.
- Чоң жана ыңгайсыздыкка караганда кошумча өзгөрүүлөргө артыкчылык бериңиз, коддун кичинекей бөлүктөрүн өзгөртүңүз. Өзгөртүүлөр кошулгандан кийин дароо көрүнбөсө дагы, аларды ишке ашыруу үчүн өзгөчөлүктү жашырууну колдонуңуз.
Эгерде сиз өзүңүздүн ишиңизде кичинекейлик принцибин колдонсоңуз, анда сиздин командаңыз алда канча бактылуу болот, керектүү функцияларды ишке ашырууга көбүрөөк көңүл бурат жана сапаттык өзгөрүүлөрдү тезирээк ишке ашырат. Бирок бул иш татаалдашып кетиши мүмкүн эмес дегенди билдирбейт, кээде, тескерисинче, жаңы функцияларды киргизүү бир нече кызматтарды өзгөртүүнү талап кылат жана бул процесс монолиттүү архитектурадагы окшоштуктарга караганда татаалыраак болушу мүмкүн. Кандай болгон күндө да, кичинекей мамилени колдонуунун пайдасы татыктуу.
Биринчи бөлүктүн аягы.
Жакында котормонун экинчи бөлүгүн чыгарабыз, эми сиздердин комментарийлериңиздерди күтөбүз жана сиздерди , ал бүгүн саат 20.00дө болот.
Source: www.habr.com