Сәлем достар. Курстың ашылу қарсаңында , біз сіздермен дәстүрлі түрде пайдалы материалдың аудармасымен бөлісеміз.
Бағдарламалық қамтамасыз ету барған сайын күрделірек бола отырып, күнделікті мәселелерді шешеді. Бір кездері Марк Андреессен айтқандай, ол әлемді жейді.
Нәтижесінде, соңғы бірнеше жылда қосымшаларды әзірлеу және жеткізу тәсілі күрт өзгерді. Бұл тектоникалық масштабтағы ығысулар болды, нәтижесінде бірқатар принциптер пайда болды. Бұл принциптер топ құруда, қолданбаңызды жобалауда, әзірлеуде және соңғы пайдаланушыларға жеткізуде пайдалы болды.
Принциптерді келесідей қорытындылауға болады: қолданба шағын, вебке негізделген және әзірлеушіге бағытталған архитектурасы болуы керек. Осы үш қағидаға сүйене отырып, сіз соңғы пайдаланушыға жылдам және қауіпсіз жеткізілетін және оңай масштабталатын және кеңейтілетін сенімді, түпкілікті қолданбаны жасай аласыз.
Ұсынылған қағидалардың әрқайсысында техникалық қызмет көрсету және пайдалану оңай сенімді қолданбаларды жылдам жеткізудің түпкі мақсатына қалай ықпал ететінін көрсету үшін біз талқылайтын бірқатар аспектілер бар. Біз принциптерді олардың қарама-қайшылықтарымен салыстырғанда қарастырамыз: «Қолданғаныңызға көз жеткізіңіз» деп айтудың нені білдіретінін түсіндіру. кішілік принципі«.
Бұл мақала үнемі өсіп келе жатқан технология стек контекстінде біртұтас дизайн тәсілін қамтамасыз ететін заманауи қолданбаларды құрудың ұсынылған принциптерін пайдалануға шақырады деп үміттенеміз.
Осы принциптерді қолдану арқылы сіз бағдарламалық жасақтаманы әзірлеудегі соңғы тенденцияларды, соның ішінде қолданбаларды әзірлеуге және жеткізуге, контейнерлерді пайдалануға (мысалы, ) және контейнерлік оркестрлік құрылымдар (мысалы, ), микросервистерді (соның ішінде Microservice Architecture) пайдалану и микросервис қолданбаларына арналған.
Қазіргі заманғы қолданба дегеніміз не?
Қазіргі қолданбалар? Қазіргі стек? «Заманауи» нақты нені білдіреді?
Көптеген әзірлеушілер заманауи қосымшаның неден тұратыны туралы негізгі түсінікке ие, сондықтан бұл ұғымды нақты анықтау қажет.
Заманауи қолданба бірнеше клиенттерді қолдайды, мейлі ол 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 Әдіс кері байланыс ала отырып, тез сыналатын және орналастырылатын кодтың шағын көлеміне назар аударуға мүмкіндік береді. Қолданбаның когнитивтік жүктемесі алты айдан екі жылға дейінгі уақыт аралығынан үлкен көлемдегі спецификациялармен екі апталық мүмкіндікті қосуға немесе өзгертуге ауысты, бұл үлкен қолданбаны кеңірек түсінуге бағытталған.
Фокусты ауқымды қолданбадан екі апталық спринтте аяқталатын нақты шағын мүмкіндіктерге ауыстыру, келесі спринттен бір ғана мүмкіндікті қарастыру маңызды өзгеріс болып табылады. Бұл үнемі құбылып тұратын когнитивті жүктемені азайта отырып, даму өнімділігін арттыруға мүмкіндік берді.
Әдістемеде agile түпкілікті қолданба бастапқы тұжырымдаманың сәл өзгертілген нұсқасы болады деп күтілуде, сондықтан әзірлеудің соңғы нүктесі міндетті түрде анық емес. Әрбір нақты спринттің нәтижелері ғана анық және нақты болуы мүмкін.
Шағын кодтық базалар
Когнитивтік жүктемені азайтудың келесі қадамы кодтық базаны азайту болып табылады. Әдетте, қазіргі заманғы қолданбалар ауқымды — сенімді, кәсіпорын қолданбасы мыңдаған файлдар мен жүздеген мың код жолдарынан тұруы мүмкін. Файлдардың ұйымдастырылуына байланысты код пен файлдар арасындағы байланыстар мен тәуелділіктер анық немесе анық болмауы мүмкін. Пайдаланылатын кітапханаларға және отладтау құралдарының кітапханалар/бумалар/модульдер мен пайдаланушы кодын қаншалықты жақсы ажырататынына байланысты кодты орындаудың өзі де проблемалы болуы мүмкін.
Қолданба кодының жұмыс істейтін психикалық моделін құру әзірлеушіге тағы да үлкен когнитивті жүктеме түсіре отырып, айтарлықтай уақытты алуы мүмкін. Бұл, әсіресе, монолитті кодтық базаларға қатысты, мұнда кодтың үлкен көлемі бар, функционалдық құрамдас бөліктер арасындағы өзара әрекеттесулер нақты анықталмаған, функционалдық шекаралар сақталмағандықтан назар аударатын объектілерді бөлу жиі бұлыңғыр болады.
Инженерлердегі когнитивті жүктемені азайтудың тиімді әдістерінің бірі микросервис архитектурасына көшу болып табылады. Микросервис тәсілінде әрбір қызмет функциялардың бір жинағына шоғырланады; қызметтің мәні әдетте анықталған және түсінікті. Қызметтің шекаралары да анық - қызметпен байланыс API арқылы жүзеге асырылатынын есте сақтаңыз, сондықтан бір қызмет арқылы жасалған деректерді басқасына оңай ауыстыруға болады.
Басқа қызметтермен өзара әрекеттесу әдетте бірнеше пайдаланушы қызметтерімен және REST сияқты қарапайым және таза API қоңырауларын пайдаланатын бірнеше провайдер қызметтерімен шектеледі. Бұл инженерге танымдық жүктеме айтарлықтай төмендейді дегенді білдіреді. Ең үлкен мәселе қызметтің өзара әрекеттесу моделін және транзакциялар сияқты нәрселердің бірнеше қызметтерде қалай болатынын түсіну болып қала береді. Сайып келгенде, микросервистерді пайдалану код көлемін азайту, нақты қызмет шекараларын анықтау және пайдаланушы мен жеткізуші қарым-қатынасы туралы түсінік беру арқылы когнитивтік жүктемені азайтады.
Кішігірім қадамдық өзгерістер
Принциптің соңғы элементі азғана өзгерістерді басқару болып табылады. Әзірлеушілер үшін кодтық базаны (тіпті өздерінің, ескі кодтары да болуы мүмкін) қарап, «Бұл сұмдық, біз осының барлығын қайта жазуымыз керек» деп айтуы әсіресе қызықтырады. Кейде бұл дұрыс шешім, ал кейде олай емес. Ол жаһандық үлгі өзгерістерінің ауыртпалығын әзірлеу тобына жүктейді, бұл өз кезегінде үлкен когнитивті жүктемеге әкеледі. Инженерлер спринт кезінде жасай алатын өзгерістерге назар аударғаны жақсы, сонда олар қажетті функционалдылықты біртіндеп болса да дер кезінде шығара алады. Соңғы өнім алдын ала жоспарланғанға ұқсауы керек, бірақ клиенттің қажеттіліктерін қанағаттандыру үшін кейбір модификациялары мен сынақтары бар.
Кодтың үлкен бөліктерін қайта жазу кезінде өзгертуді жылдам жеткізу кейде мүмкін емес, себебі басқа жүйе тәуелділіктері іске қосылады. Өзгерістер ағынын басқару үшін мүмкіндікті жасыруды пайдалануға болады. Негізінде бұл функционалдылықтың өндірісте бар екенін білдіреді, бірақ ол орта айнымалы параметрлері (env-var) немесе кез келген басқа конфигурация механизмі арқылы қолжетімді емес. Егер код барлық сапаны бақылау процестерінен өткен болса, ол өндірісте жасырын күйде аяқталуы мүмкін. Дегенмен, бұл стратегия мүмкіндік ақырында қосылғанда ғана жұмыс істейді. Әйтпесе, ол тек кодты бұзады және әзірлеуші өнімді болу үшін жеңуге тура келетін когнитивтік жүктемені қосады. Өзгерістерді басқару және қосымша өзгерістердің өзі әзірлеушілердің когнитивті жүктемесін қол жетімді деңгейде сақтауға көмектеседі.
Инженерлер қосымша функционалдылықты жай ғана іске асырған кезде де көптеген қиындықтарды жеңуге тура келеді. Басшылық функционалдылықтың негізгі элементтеріне назар аударуы үшін командадағы қажетсіз жұмыс жүктемесін азайтуы орынды болар еді. Әзірлеу тобына көмектесу үшін сіз жасай алатын үш нәрсе бар:
- Әдістемені қолдану
agile, команда негізгі мүмкіндіктерге назар аударуы керек уақыт шеңберін шектеу үшін. - Қолданбаңызды бірнеше микросервис ретінде іске асырыңыз. Бұл енгізілген мүмкіндіктердің санын шектейді және жұмыс кезінде когнитивтік жүктемені қамтитын шекараларды күшейтеді.
- Үлкен, қолайсыз өзгерістерге қосымша өзгерістерді ұнатыңыз, кодтың шағын бөліктерін өзгертіңіз. Өзгерістер енгізілгеннен кейін бірден көрінбесе де, енгізу үшін мүмкіндікті жасыруды пайдаланыңыз.
Егер сіз жұмысыңызда кішігірім принципті қолдансаңыз, сіздің командаңыз әлдеқайда бақытты болады, қажетті мүмкіндіктерді жеткізуге жақсырақ назар аударады және сапалы өзгерістерді тезірек енгізу ықтималдығы жоғары болады. Бірақ бұл жұмыс күрделі бола алмайды дегенді білдірмейді, кейде, керісінше, жаңа функционалдылықты енгізу бірнеше қызметтерді өзгертуді талап етеді және бұл процесс монолитті архитектурадағы ұқсас процесске қарағанда күрделірек болуы мүмкін. Қалай болғанда да, әдісті қолданудың пайдасы аздап тұрарлық.
Бірінші бөлімнің соңы.
Жақында аударманың екінші бөлімін шығарамыз, бірақ енді сіздердің пікірлеріңізді күтеміз және шақырамыз , ол бүгін сағат 20.00-де өтеді.
Ақпарат көзі: www.habr.com