Kumusta Mga Kaibigan. Sa paghihintay ng paglulunsad ng kurso , tradisyonal naming ibinabahagi sa iyo ang pagsasalin ng kapaki-pakinabang na materyal.
Ang software ay lumulutas ng higit at higit pang mga pang-araw-araw na problema, habang nagiging mas kumplikado. Tulad ng sinabi minsan ni Marc Andreessen, nilalamon nito ang mundo.
Bilang resulta, ang paraan ng pagbuo at paghahatid ng mga application ay kapansin-pansing nagbago sa nakalipas na ilang taon. Ang mga ito ay mga pagbabago sa isang tectonic scale na nagresulta sa isang hanay ng mga prinsipyo. Ang mga prinsipyong ito ay napatunayang nakakatulong sa pagbuo ng isang team, pagdidisenyo, pagbuo, at paghahatid ng iyong application sa mga end user.
Ang mga prinsipyo ay maaaring ibuod tulad ng sumusunod: ang application ay dapat maliit, web-based, at may developer-centric na arkitektura. Sa pamamagitan ng pagbuo sa tatlong prinsipyong ito, maaari kang lumikha ng isang matatag, end-to-end na application na maaaring mabilis at ligtas na maihatid sa end user, at madaling masusukat at mapapalawak.
Ang bawat isa sa mga iminungkahing prinsipyo ay may ilang mga aspeto na tatalakayin natin upang ipakita kung paano nakakatulong ang bawat prinsipyo sa layunin ng mabilis na paghahatid ng mga mapagkakatiwalaang application na madaling mapanatili at gamitin. Titingnan natin ang mga prinsipyo kung ihahambing sa mga kabaligtaran ng mga ito upang linawin kung ano ang ibig sabihin ng sabihing, βSiguraduhin na ginagamit mo prinsipyo ng kaliitan'.
Umaasa kaming hinihikayat ka ng artikulong ito na gamitin ang mga iminungkahing prinsipyo para sa pagbuo ng mga modernong application na magbibigay ng pinag-isang diskarte sa disenyo sa konteksto ng patuloy na lumalagong stack ng teknolohiya.
Sa pamamagitan ng paglalapat ng mga prinsipyong ito, makikita mo ang iyong sarili na sinasamantala ang pinakabagong mga uso sa pagbuo ng software, kabilang ang sa pagbuo at paghahatid ng application, ang paggamit ng mga lalagyan (halimbawa, ) at mga balangkas ng orkestrasyon ng lalagyan (halimbawa, ), paggamit ng mga microservice (kabilang ang Microservice Architecture ΠΈ para sa mga aplikasyon ng microservice.
Ano ang isang modernong app?
Mga modernong aplikasyon? Modern stack? Ano nga ba ang ibig sabihin ng "moderno"?
Karamihan sa mga developer ay mayroon lamang pangunahing pag-unawa sa kung ano ang binubuo ng isang modernong aplikasyon, kaya kinakailangan na malinaw na tukuyin ang konseptong ito.
Sinusuportahan ng modernong application ang maraming kliyente, maging user interface man ito gamit ang React JavaScript library, isang mobile application para sa Android o iOS, o isang application na kumokonekta sa isa pa sa pamamagitan ng API. Ang isang modernong aplikasyon ay nagpapahiwatig ng isang hindi tiyak na bilang ng mga kliyente kung saan ito ay nagbibigay ng data o mga serbisyo.
Ang isang modernong application ay nagbibigay ng isang API upang ma-access ang hiniling na data at mga serbisyo. Ang API ay dapat na hindi nababago at pare-pareho, at hindi partikular na isinulat para sa isang partikular na kahilingan mula sa isang partikular na kliyente. Available ang API sa HTTP(S) at nagbibigay ng access sa lahat ng functionality na makikita sa GUI o CLI.
Dapat na available ang data sa isang karaniwang, interoperable na format gaya ng JSON. Ang isang API ay naglalantad ng mga bagay at serbisyo sa isang malinaw, organisadong anyo; halimbawa, ang isang RESTful API o GraphQL ay nagbibigay ng isang disenteng interface.
Ang mga modernong application ay binuo sa isang modernong stack, at ang isang modernong stack ay ang stack na sumusuporta sa mga naturang application, ayon sa pagkakabanggit. Ang stack na ito ay nagbibigay-daan sa developer na madaling lumikha ng isang application na may HTTP interface at malinaw na mga endpoint ng API. Ang diskarte na iyong pipiliin ay magbibigay-daan sa iyong aplikasyon na madaling tumanggap at magpadala ng data sa JSON na format. Sa madaling salita, ang modernong stack ay tumutugma sa mga elemento ng Twelve-Factor Application para sa .
Ang mga sikat na bersyon ng ganitong uri ng stack ay batay sa , , , , ΠΈ . Arkitektura ng Microservice ay kumakatawan sa isang halimbawa ng isang modernong stack na ipinatupad sa bawat isa sa mga wikang nabanggit.
Pakitandaan na hindi kami nagsusulong ng puro microservices na diskarte. Marami sa inyo ang nagtatrabaho sa mga monolith na kailangang mag-evolve, habang ang iba ay nakikipag-ugnayan sa mga SOA application na lumalawak at umuusbong upang maging mga microservice application. Ang iba pa ay lumilipat patungo sa mga application na walang server, at ang ilan ay nagpapatupad ng mga kumbinasyon ng nasa itaas. Ang mga prinsipyong nakabalangkas sa artikulong ito ay nalalapat sa bawat isa sa mga sistemang ito na may kaunting mga pagbabago lamang.
Prinsipyo
Ngayon na mayroon na kaming pangunahing pag-unawa sa kung ano ang isang modernong aplikasyon at isang modernong stack, oras na upang sumisid sa arkitektura at mga prinsipyo ng disenyo na magsisilbing mabuti sa iyo sa pagdidisenyo, pagpapatupad, at pagpapanatili ng modernong aplikasyon.
Isa sa mga prinsipyo ay βbumuo ng maliliit na appβ, tawagin na lang natin ang prinsipyo ng kaliitan. Mayroong hindi kapani-paniwalang kumplikadong mga application na mayroong maraming gumagalaw na bahagi. Sa turn, ang pagbuo ng isang application mula sa maliliit, discrete na mga bahagi ay nagpapadali sa disenyo, pagpapanatili, at paggamit sa pangkalahatan. (Tandaan na sinabi namin na "ginawang simple" at hindi "ginawang simple").
Ang pangalawang prinsipyo ay maaari nating pataasin ang produktibidad ng developer sa pamamagitan ng pagtulong sa kanila na tumuon sa mga feature na kanilang ginagawa, habang pinapalaya sila mula sa pag-aalala tungkol sa imprastraktura at CI/CD sa panahon ng pagpapatupad. Kaya, sa maikling salita, ang aming diskarte nakatuon sa developer.
Sa wakas, ang lahat ng tungkol sa iyong aplikasyon ay dapat na konektado sa network. Sa nakalipas na 20 taon, lubos kaming sumulong patungo sa isang naka-network na hinaharap dahil ang mga network ay naging mas mabilis at ang mga aplikasyon ay naging mas kumplikado. Tulad ng nakita na natin, ang isang modernong aplikasyon ay dapat gamitin sa isang network ng maraming iba't ibang mga kliyente. Ang paglalapat ng pag-iisip sa network sa arkitektura ay may mga makabuluhang benepisyo na akma nang maayos ang prinsipyo ng kaliitan at ang konsepto ng diskarte, nakatuon sa developer.
Kung isasaisip mo ang mga prinsipyong ito kapag nagdidisenyo at nagpapatupad ng isang aplikasyon, magkakaroon ka ng natatanging kalamangan sa pagbuo at paghahatid ng iyong produkto.
Tingnan natin ang tatlong prinsipyong ito nang mas detalyado.
Ang prinsipyo ng kaliitan
Mahirap para sa utak ng tao na malasahan ang malalaking halaga ng impormasyon nang sabay-sabay. Sa sikolohiya, ang terminong cognitive load ay tumutukoy sa kabuuang halaga ng mental na pagsisikap na kinakailangan upang mapanatili ang impormasyon sa memorya. Ang pagbabawas ng cognitive load sa mga developer ay isang priyoridad dahil maaari silang tumuon sa paglutas ng problema sa halip na hawakan ang kasalukuyang kumplikadong modelo ng buong application at ang mga tampok na binuo sa kanilang ulo.
Nabulok ang mga aplikasyon para sa mga sumusunod na dahilan:
- Pagbabawas ng cognitive load sa mga developer;
- Pagpapabilis at pagpapasimple ng pagsubok;
- Mabilis na paghahatid ng mga pagbabago sa application.
Mayroong ilang mga paraan upang bawasan ang cognitive load sa mga developer, at dito pumapasok ang prinsipyo ng kaliitan.
Kaya, tatlong paraan upang bawasan ang cognitive load:
- Bawasan ang time frame na dapat nilang isaalang-alang kapag gumagawa ng bagong feature β mas maikli ang time frame, mas mababa ang cognitive load.
- Bawasan ang dami ng code na ginagawa sa isang pagkakataon - mas kaunting code - mas kaunting load.
- Pasimplehin ang proseso ng paggawa ng mga incremental na pagbabago sa iyong aplikasyon.
Nabawasan ang mga frame ng oras ng pag-unlad
Balikan natin ang mga panahon kung kailan ang metodolohiya waterfall ay ang pamantayan para sa proseso ng pagbuo, at ang mga takdang panahon ng anim na buwan hanggang dalawang taon para sa pagbuo o pag-update ng isang aplikasyon ay karaniwang kasanayan. Karaniwan, babasahin muna ng mga inhinyero ang mga nauugnay na dokumento gaya ng mga kinakailangan sa produkto (PRD), dokumento ng sanggunian ng system (SRD), plano ng arkitektura, at magsisimulang pagsamahin ang lahat ng mga bagay na ito sa isang modelong nagbibigay-malay ayon sa kung saan sila sumulat ng code. Habang nagbago ang mga kinakailangan, at samakatuwid ang arkitektura, kailangang gumawa ng mga makabuluhang pagsisikap upang mapanatili ang kaalaman sa buong team tungkol sa mga update sa cognitive model. Sa pinakamasamang kaso, ang pamamaraang ito ay maaaring maparalisa lamang ang trabaho.
Ang pinakamalaking pagbabago sa proseso ng pagbuo ng aplikasyon ay ang pagpapakilala ng agile methodology. Isa sa mga pangunahing tampok ng pamamaraan agile - Ito ay umuulit na pag-unlad. Sa turn, humahantong ito sa isang pagbawas sa cognitive load sa mga inhinyero. Sa halip na hilingin sa development team na ipatupad ang application sa isang mahabang cycle, agile Binibigyang-daan ka ng diskarte na tumuon sa maliit na halaga ng code na maaaring mabilis na masuri at ma-deploy, habang tumatanggap din ng feedback. Ang cognitive load ng isang application ay lumipat mula sa isang time frame na anim na buwan hanggang dalawang taon, na may malaking halaga ng mga detalye, sa isang dalawang linggong pagdaragdag o pagbabago ng feature, na nagta-target ng mas malawak na pag-unawa sa isang malaking application.
Ang paglipat ng focus mula sa isang napakalaking application patungo sa mga partikular na maliliit na feature na maaaring kumpletuhin sa isang dalawang linggong sprint, ang pagtingin sa unahan sa hindi hihigit sa isang feature mula sa susunod na sprint sa isip ay isang makabuluhang pagbabago. Ginawa nitong posible na mapataas ang produktibidad ng pag-unlad habang binabawasan ang cognitive load, na patuloy na nagbabago.
Sa metodolohiya agile ang panghuling aplikasyon ay inaasahang maging isang bahagyang binagong bersyon ng orihinal na konsepto, kaya ang panghuling punto ng pag-unlad ay kinakailangang malabo. Tanging ang mga resulta ng bawat partikular na sprint ay maaaring maging malinaw at tumpak.
Mga maliliit na codebase
Ang susunod na hakbang sa pagbabawas ng cognitive load ay bawasan ang code base. Karaniwan, ang mga modernong application ay napakalakiβisang matatag, enterprise application ay maaaring binubuo ng libu-libong mga file at daan-daang libong linya ng code. Depende sa organisasyon ng mga file, ang mga koneksyon at dependency sa pagitan ng code at ng mga file ay maaaring halata o hindi. Kahit na ang pag-debug sa mismong pagpapatupad ng code ay maaaring maging problema, depende sa mga library na ginamit at kung gaano kahusay ang pagkakaiba ng mga tool sa pag-debug sa pagitan ng mga library/package/modules at user code.
Ang pagbuo ng gumaganang mental na modelo ng code ng isang application ay maaaring tumagal ng malaking tagal ng panahon, na muling naglalagay ng malaking cognitive load sa developer. Ito ay totoo lalo na para sa mga monolithic codebase, kung saan mayroong isang malaking halaga ng code, ang mga pakikipag-ugnayan sa pagitan ng mga functional na bahagi ay hindi malinaw na tinukoy, at ang paghihiwalay ng mga bagay na pinagtutuunan ng pansin ay madalas na malabo dahil ang mga hangganan ng pagganap ay hindi iginagalang.
Ang isang epektibong paraan upang bawasan ang cognitive load sa mga inhinyero ay ang paglipat sa isang arkitektura ng microservices. Sa isang microservice approach, ang bawat serbisyo ay nakatutok sa isang hanay ng mga function; ang kahulugan ng serbisyo ay karaniwang tinukoy at naiintindihan. Ang mga hangganan ng serbisyo ay malinaw din - tandaan na ang komunikasyon sa serbisyo ay isinasagawa gamit ang isang API, kaya ang data na nabuo ng isang serbisyo ay madaling mailipat sa isa pa.
Ang pakikipag-ugnayan sa iba pang mga serbisyo ay karaniwang limitado sa ilang mga serbisyo ng user at ilang mga serbisyo ng provider na gumagamit ng simple at malinis na mga tawag sa API, gaya ng REST. Nangangahulugan ito na ang cognitive load sa engineer ay seryosong nabawasan. Ang pinakamalaking hamon ay nananatiling pag-unawa sa modelo ng pakikipag-ugnayan ng serbisyo at kung paano nangyayari ang mga bagay tulad ng mga transaksyon sa maraming serbisyo. Sa huli, ang paggamit ng mga microservice ay nagpapababa ng cognitive load sa pamamagitan ng pagbabawas sa dami ng code, pagtukoy ng malinaw na mga hangganan ng serbisyo, at pagbibigay ng insight sa relasyon ng user-provider.
Maliit na incremental na pagbabago
Ang huling elemento ng prinsipyo kaunti ay change management. Lalo na nakatutukso para sa mga developer na tumingin sa isang base ng code (kahit na marahil sa kanilang sarili, mas lumang code) at sabihin, "Ito ay crap, kailangan nating muling isulat ang buong bagay na ito." Minsan tama ang desisyon, at minsan hindi. Inilalagay nito ang pasanin ng mga pagbabago sa pandaigdigang modelo sa development team, na nagreresulta naman sa napakalaking cognitive load. Mas mainam para sa mga inhinyero na tumuon sa mga pagbabagong magagawa nila sa panahon ng sprint, nang sa gayon ay mailunsad nila ang kinakailangang pag-andar sa isang napapanahong paraan, kahit na unti-unti. Ang panghuling produkto ay dapat na katulad ng paunang binalak, ngunit may ilang mga pagbabago at pagsubok upang umangkop sa mga pangangailangan ng kliyente.
Kapag nagsusulat muli ng malalaking bahagi ng code, minsan imposibleng mabilis na maghatid ng pagbabago dahil may ibang mga dependency ng system na pumapasok. Upang makontrol ang daloy ng mga pagbabago, maaari mong gamitin ang pagtatago ng tampok. Karaniwang, nangangahulugan ito na ang pag-andar ay naroroon sa produksyon, ngunit hindi ito magagamit sa pamamagitan ng mga setting ng variable ng kapaligiran (env-var) o anumang iba pang mekanismo ng pagsasaayos. Kung naipasa ng code ang lahat ng proseso ng pagkontrol sa kalidad, maaari itong mauwi sa produksyon sa isang nakatagong estado. Gayunpaman, gagana lang ang diskarteng ito kung pinagana ang feature. Kung hindi, kalat lang nito ang code at magdagdag ng cognitive load na kailangang harapin ng developer para maging produktibo. Ang pamamahala ng pagbabago at mga incremental na pagbabago mismo ay nakakatulong na panatilihin ang cognitive load ng mga developer sa isang naa-access na antas.
Kailangang malampasan ng mga inhinyero ang maraming paghihirap kahit na nagpapatupad lamang ng karagdagang pag-andar. Magiging masinop para sa pamamahala na bawasan ang hindi kinakailangang workload sa team para makapag-focus ito sa mga pangunahing elemento ng functionality. May tatlong bagay na maaari mong gawin upang matulungan ang iyong development team:
- Gumamit ng metodolohiya
agile, para limitahan ang time frame kung saan dapat tumuon ang team sa mga pangunahing feature. - Ipatupad ang iyong aplikasyon bilang ilang mga microservice. Nililimitahan nito ang bilang ng mga feature na ipinakilala at palalakasin ang mga hangganan na naglalaman ng cognitive load habang nagtatrabaho.
- Mas gusto ang mga incremental na pagbabago sa malaki, mahirap gamitin, baguhin ang maliliit na piraso ng code. Gumamit ng pagtatago ng tampok upang ipatupad ang mga pagbabago kahit na hindi agad makikita ang mga ito pagkatapos idagdag ang mga ito.
Kung ilalapat mo ang prinsipyo ng kaliitan sa iyong trabaho, magiging mas masaya ang iyong team, mas makakatuon sa paghahatid ng mga kinakailangang feature, at mas malamang na maglunsad ng mga pagbabago sa kalidad nang mas mabilis. Ngunit hindi ito nangangahulugan na ang gawain ay hindi maaaring maging mas kumplikado; kung minsan, sa kabaligtaran, ang pagpapakilala ng bagong pag-andar ay nangangailangan ng pagbabago ng ilang mga serbisyo at ang prosesong ito ay maaaring mas kumplikado kaysa sa isang katulad sa isang monolitikong arkitektura. Sa anumang kaso, ang mga benepisyo ng paggamit ng diskarte ay bahagyang katumbas ng halaga.
Katapusan ng unang bahagi.
Malapit na naming i-publish ang pangalawang bahagi ng pagsasalin, ngunit ngayon ay hinihintay namin ang iyong mga komento at iniimbitahan ka , na magaganap ngayon sa 20.00.
Pinagmulan: www.habr.com