Habari marafiki. Kwa kutarajia uzinduzi wa kozi hiyo , sisi jadi kushiriki na wewe tafsiri ya nyenzo muhimu.
Programu hutatua matatizo zaidi na zaidi ya kila siku, wakati inakuwa ngumu zaidi na zaidi. Kama Marc Andreessen alivyosema mara moja, inateketeza ulimwengu.
Kwa hivyo, jinsi maombi yanavyotengenezwa na kuwasilishwa imebadilika sana katika miaka michache iliyopita. Hizi zilikuwa zamu kwa kiwango cha tectonic ambacho kilisababisha seti ya kanuni. Kanuni hizi zimethibitishwa kusaidia katika kujenga timu, kubuni, kuendeleza na kuwasilisha maombi yako kwa watumiaji wa hatima.
Kanuni zinaweza kufupishwa kama ifuatavyo: programu lazima iwe ndogo, kulingana na wavuti, na iwe na usanifu wa msingi wa msanidi. Kwa kuzingatia kanuni hizi tatu, unaweza kuunda programu thabiti, ya mwisho hadi mwisho ambayo inaweza kuwasilishwa kwa haraka na kwa usalama kwa mtumiaji wa mwisho, na inaweza kupanuka na kupanuka kwa urahisi.
Kila moja ya kanuni zilizopendekezwa ina idadi ya vipengele ambavyo tutajadili ili kuonyesha jinsi kila kanuni inachangia lengo la mwisho la kutoa haraka maombi ya kuaminika ambayo ni rahisi kutunza na kutumia. Tutaangalia kanuni kwa kulinganisha na kinyume chake ili kufafanua maana ya kusema, βHakikisha unatumia kanuni ya udogo'.
Tunatumahi kuwa makala haya yanakuhimiza kutumia kanuni zinazopendekezwa kwa ajili ya kujenga programu za kisasa ambazo zitatoa mbinu ya kubuni iliyounganishwa katika muktadha wa msururu wa teknolojia unaoendelea kukua.
Kwa kutumia kanuni hizi, utajipata ukichukua fursa ya mitindo ya hivi punde katika ukuzaji wa programu, ikijumuisha kwa maendeleo ya maombi na utoaji, matumizi ya vyombo (kwa mfano, ) na mifumo ya uandaaji wa kontena (kwa mfano, ), matumizi ya microservices (ikiwa ni pamoja na Usanifu wa Microservice ΠΈ kwa maombi ya microservice.
Programu ya kisasa ni nini?
Maombi ya kisasa? Mkusanyiko wa kisasa? "kisasa" maana yake nini hasa?
Waendelezaji wengi wana ufahamu wa msingi tu wa kile maombi ya kisasa yanajumuisha, kwa hiyo ni muhimu kufafanua wazi dhana hii.
Programu ya kisasa inaweza kutumia wateja wengi, iwe kiolesura kinachotumia maktaba ya React JavaScript, programu ya simu ya mkononi ya Android au iOS, au programu inayounganishwa na nyingine kupitia API. Programu ya kisasa inamaanisha idadi isiyojulikana ya wateja ambayo hutoa data au huduma.
Programu ya kisasa hutoa API kufikia data na huduma zilizoombwa. API inapaswa kuwa isiyobadilika na isiyobadilika, na isiandikwe mahsusi kwa ombi maalum kutoka kwa mteja mahususi. API inapatikana kupitia HTTP(S) na hutoa ufikiaji wa utendakazi wote unaopatikana kwenye GUI au CLI.
Data lazima ipatikane katika umbizo la kawaida, linaloweza kushirikiana kama vile JSON. API hufichua vitu na huduma kwa uwazi, umbo lililopangwa; kwa mfano, RESTful API au GraphQL hutoa kiolesura kizuri.
Maombi ya kisasa yanajengwa kwenye stack ya kisasa, na stack ya kisasa ni stack ambayo inasaidia maombi hayo, kwa mtiririko huo. Rafu hii huruhusu msanidi programu kuunda programu kwa urahisi na kiolesura cha HTTP na kuondoa ncha za API. Mbinu utakayochagua itaruhusu programu yako kukubali na kutuma data kwa urahisi katika umbizo la JSON. Kwa maneno mengine, stack ya kisasa inalingana na vipengele vya Maombi ya Kumi na Mbili kwa .
Matoleo maarufu ya aina hii ya stack yanategemea , , , , ΠΈ . Usanifu wa Microservice inawakilisha mfano wa safu ya kisasa inayotekelezwa katika kila lugha iliyotajwa.
Tafadhali kumbuka kuwa hatutetei mbinu ya huduma ndogo. Wengi wenu mnafanya kazi na monoliths ambazo zinahitaji kubadilika, wakati wengine wanashughulikia programu za SOA ambazo zinapanuka na kubadilika na kuwa programu ndogo za huduma. Bado wengine wanaelekea kwenye programu zisizo na seva, na wengine wanatekeleza michanganyiko ya hapo juu. Kanuni zilizoainishwa katika makala haya zinatumika kwa kila moja ya mifumo hii yenye marekebisho machache tu.
Kanuni
Sasa kwa kuwa tuna ufahamu wa kimsingi wa matumizi ya kisasa na rundo la kisasa ni nini, ni wakati wa kuzama katika kanuni za usanifu na usanifu ambazo zitakusaidia vyema katika kubuni, kutekeleza na kudumisha utumizi wa kisasa.
Moja ya kanuni ni "kujenga programu ndogo", hebu tuite tu kanuni ya udogo. Kuna programu ngumu sana ambazo zina sehemu nyingi za kusonga. Kwa upande mwingine, kuunda programu kutoka kwa vipengee vidogo, vilivyo tofauti hurahisisha kubuni, kudumisha na kutumia kwa ujumla. (Kumbuka kwamba tulisema "inafanya iwe rahisi" na sio "inafanya iwe rahisi").
Kanuni ya pili ni kwamba tunaweza kuongeza tija ya wasanidi programu kwa kuwasaidia kuzingatia vipengele wanavyounda, huku tukiwaweka huru kutokana na wasiwasi kuhusu miundombinu na CI/CD wakati wa utekelezaji. Kwa hiyo, kwa kifupi, mbinu yetu yenye mwelekeo wa msanidi programu.
Hatimaye, kila kitu kuhusu programu yako lazima kiunganishwe kwenye mtandao. Katika kipindi cha miaka 20 iliyopita, tumesonga mbele sana kuelekea mustakabali wa mtandao kwani mitandao imekuwa haraka na programu zimekuwa ngumu zaidi. Kama tulivyoona, ni lazima programu ya kisasa itumike kwenye mtandao na wateja wengi tofauti. Utumiaji wa fikra za mtandao kwenye usanifu una manufaa makubwa ambayo yanalingana nayo kanuni ya udogo na dhana ya mbinu, yenye mwelekeo wa msanidi programu.
Ukizingatia kanuni hizi wakati wa kubuni na kutekeleza programu, utakuwa na faida tofauti katika uundaji na utoaji wa bidhaa yako.
Hebu tuangalie kanuni hizi tatu kwa undani zaidi.
Kanuni ya udogo
Ni vigumu kwa ubongo wa mwanadamu kutambua kiasi kikubwa cha habari mara moja. Katika saikolojia, neno mzigo wa utambuzi hurejelea jumla ya juhudi za kiakili zinazohitajika ili kuhifadhi habari kwenye kumbukumbu. Kupunguza mzigo wa utambuzi kwa wasanidi programu ni kipaumbele kwa sababu wanaweza kulenga kutatua tatizo badala ya kushikilia muundo changamano wa sasa wa programu nzima na vipengele vinavyotengenezwa vichwani mwao.
Maombi yanatatuliwa kwa sababu zifuatazo:
- Kupunguza mzigo wa utambuzi kwa watengenezaji;
- Kuongeza kasi na kurahisisha upimaji;
- Uwasilishaji wa haraka wa mabadiliko kwenye programu.
Kuna njia kadhaa za kupunguza mzigo wa utambuzi kwa watengenezaji, na hapa ndipo kanuni ya udogo inakuja.
Kwa hivyo, njia tatu za kupunguza mzigo wa utambuzi:
- Punguza muda ambao wanapaswa kuzingatia wakati wa kuunda kipengele kipya - jinsi muda unavyopungua, ndivyo mzigo wa utambuzi unavyopungua.
- Punguza kiasi cha msimbo unaofanyiwa kazi kwa wakati mmoja - msimbo mdogo - upakiaji kidogo.
- Rahisisha mchakato wa kufanya mabadiliko ya nyongeza kwenye programu yako.
Muda wa muda wa maendeleo uliopunguzwa
Hebu turudi kwenye nyakati ambazo mbinu waterfall kilikuwa kiwango cha mchakato wa uendelezaji, na muda uliowekwa wa miezi sita hadi miaka miwili kwa ajili ya kuendeleza au kusasisha ombi ulikuwa utaratibu wa kawaida. Kwa kawaida, wahandisi wangesoma kwanza hati husika kama vile mahitaji ya bidhaa (PRD), hati ya marejeleo ya mfumo (SRD), mpango wa usanifu, na kuanza kuunganisha vitu hivi vyote pamoja katika modeli moja ya utambuzi kulingana na ambayo waliandika msimbo. Kadiri mahitaji, na kwa hivyo usanifu, ulivyobadilika, juhudi kubwa zilibidi kufanywa ili kuweka timu nzima habari kuhusu sasisho za muundo wa utambuzi. Katika hali mbaya zaidi, mbinu hii inaweza tu kupooza kazi.
Mabadiliko makubwa zaidi katika mchakato wa ukuzaji wa maombi yalikuwa kuanzishwa kwa mbinu agile. Moja ya sifa kuu za mbinu agile - Hii ni maendeleo ya mara kwa mara. Kwa upande mwingine, hii inasababisha kupunguzwa kwa mzigo wa utambuzi kwa wahandisi. Badala ya kuhitaji timu ya maendeleo kutekeleza maombi katika mzunguko mmoja mrefu, agile Mbinu hiyo hukuruhusu kuzingatia viwango vidogo vya msimbo ambavyo vinaweza kujaribiwa haraka na kutumwa, huku pia ukipokea maoni. Mzigo wa utambuzi wa programu umehama kutoka kipindi cha miezi sita hadi miaka miwili, na idadi kubwa ya vipimo, hadi nyongeza ya kipengele cha wiki mbili au mabadiliko, ikilenga uelewaji zaidi wa programu kubwa.
Kuhamisha mwelekeo kutoka kwa programu kubwa hadi vipengele maalum vidogo vinavyoweza kukamilika katika mbio za wiki mbili, kuangalia mbele kwa si zaidi ya kipengele kimoja kutoka kwa mbio inayofuata ni mabadiliko makubwa. Hii ilifanya iwezekane kuongeza tija ya maendeleo huku ikipunguza mzigo wa utambuzi, ambao ulikuwa ukibadilika kila mara.
Katika methodolojia agile matumizi ya mwisho yanatarajiwa kuwa toleo lililorekebishwa kidogo la dhana asilia, kwa hivyo hatua ya mwisho ya ukuzaji lazima iwe na utata. Tu matokeo ya kila sprint maalum inaweza kuwa wazi na sahihi.
Codebases ndogo
Hatua inayofuata katika kupunguza mzigo wa utambuzi ni kupunguza msingi wa msimbo. Kwa kawaida, matumizi ya kisasa ni makubwaβprogramu thabiti, ya biashara inaweza kuwa na maelfu ya faili na mamia ya maelfu ya mistari ya msimbo. Kulingana na shirika la faili, viunganisho na utegemezi kati ya kanuni na faili zinaweza kuwa wazi au zisiwe wazi. Hata kutatua utekelezaji wa nambari yenyewe kunaweza kuwa shida, kulingana na maktaba zinazotumiwa na jinsi zana za utatuzi zinavyotofautisha kati ya maktaba/vifurushi/moduli na msimbo wa mtumiaji.
Kuunda muundo wa kiakili wa msimbo wa programu inaweza kuchukua muda mwingi, tena kuweka mzigo mkubwa wa utambuzi kwa msanidi programu. Hii ni kweli hasa kwa kanuni za kanuni za monolithic, ambapo kuna kiasi kikubwa cha kanuni, mwingiliano kati ya vipengele vya kazi haujafafanuliwa wazi, na mgawanyiko wa vitu vya tahadhari mara nyingi hupigwa kwa sababu mipaka ya kazi haizingatiwi.
Njia moja bora ya kupunguza mzigo wa utambuzi kwa wahandisi ni kuhamia usanifu wa huduma ndogo. Katika mbinu ya microservice, kila huduma inazingatia seti moja ya kazi; maana ya huduma kwa kawaida hufafanuliwa na kueleweka. Mipaka ya huduma pia ni wazi - kumbuka kuwa mawasiliano na huduma hufanywa kwa kutumia API, kwa hivyo data inayotokana na huduma moja inaweza kuhamishiwa kwa mwingine kwa urahisi.
Mwingiliano na huduma zingine kwa kawaida hupunguzwa kwa huduma chache za watumiaji na huduma chache za watoa huduma zinazotumia simu rahisi na safi za API, kama vile REST. Hii inamaanisha kuwa mzigo wa utambuzi kwenye mhandisi umepunguzwa sana. Changamoto kubwa inasalia kuelewa muundo wa mwingiliano wa huduma na jinsi mambo kama vile miamala hufanyika kwenye huduma nyingi. Hatimaye, kutumia huduma ndogo hupunguza mzigo wa utambuzi kwa kupunguza kiasi cha msimbo, kufafanua mipaka ya huduma iliyo wazi, na kutoa maarifa kuhusu uhusiano wa mtoaji huduma.
Mabadiliko madogo ya nyongeza
Kipengele cha mwisho cha kanuni kidogo ni usimamizi wa mabadiliko. Inavutia sana wasanidi programu kuangalia msingi wa msimbo (hata labda wao wenyewe, msimbo wa zamani) na kusema, "Huu ni ujinga, tunahitaji kuandika upya jambo hili lote." Wakati mwingine ni uamuzi sahihi, na wakati mwingine sivyo. Inaweka mzigo wa mabadiliko ya muundo wa kimataifa kwenye timu ya maendeleo, ambayo matokeo yake husababisha mzigo mkubwa wa utambuzi. Ni bora kwa wahandisi kuzingatia mabadiliko ambayo wanaweza kufanya wakati wa sprint, ili waweze kutekeleza utendaji muhimu kwa wakati unaofaa, ingawa hatua kwa hatua. Bidhaa ya mwisho inapaswa kufanana na ile iliyopangwa awali, lakini pamoja na marekebisho na majaribio ili kukidhi mahitaji ya mteja.
Wakati wa kuandika upya sehemu kubwa za msimbo, wakati mwingine haiwezekani kutoa mabadiliko kwa haraka kwa sababu utegemezi mwingine wa mfumo hutumika. Ili kudhibiti mtiririko wa mabadiliko, unaweza kutumia kipengele cha kuficha. Kimsingi, hii inamaanisha utendakazi upo katika uzalishaji, lakini haupatikani kupitia mipangilio ya kutofautisha ya mazingira (env-var) au utaratibu mwingine wowote wa usanidi. Ikiwa msimbo umepitisha michakato yote ya udhibiti wa ubora, inaweza kuishia katika uzalishaji katika hali fiche. Hata hivyo, mkakati huu hufanya kazi tu ikiwa kipengele hatimaye kitawezeshwa. Vinginevyo, itakusanya tu msimbo na kuongeza mzigo wa utambuzi ambao msanidi atalazimika kukabiliana nao ili kuleta tija. Usimamizi wa mabadiliko na mabadiliko ya nyongeza yenyewe husaidia kuweka mzigo wa utambuzi wa wasanidi programu katika kiwango kinachoweza kufikiwa.
Wahandisi wanapaswa kushinda matatizo mengi hata wakati wa kutekeleza tu utendaji wa ziada. Itakuwa jambo la busara kwa usimamizi kupunguza mzigo wa kazi usio wa lazima kwenye timu ili iweze kuzingatia vipengele muhimu vya utendakazi. Kuna mambo matatu unayoweza kufanya ili kusaidia timu yako ya maendeleo:
- Tumia mbinu
agile, ili kupunguza muda ambao timu lazima izingatie vipengele muhimu. - Tekeleza programu yako kama huduma ndogo ndogo kadhaa. Hii itapunguza idadi ya vipengele vilivyoletwa na kuimarisha mipaka iliyo na mzigo wa utambuzi wakati wa kufanya kazi.
- Pendelea mabadiliko ya nyongeza kwa makubwa, magumu, badilisha vipande vidogo vya msimbo. Tumia kipengele cha kuficha ili kutekeleza mabadiliko hata kama hayataonekana mara tu baada ya kuongezwa.
Ikiwa utatumia kanuni ya udogo katika kazi yako, timu yako itakuwa na furaha zaidi, itazingatia vyema kutoa vipengele muhimu, na uwezekano mkubwa wa kufanya mabadiliko ya ubora kwa haraka zaidi. Lakini hii haimaanishi kuwa kazi haiwezi kuwa ngumu zaidi, wakati mwingine, kinyume chake, kuanzishwa kwa utendakazi mpya kunahitaji marekebisho ya huduma kadhaa na mchakato huu unaweza kuwa mgumu zaidi kuliko ule unaofanana katika usanifu wa monolithic. Kwa hali yoyote, faida za kutumia mbinu ni za thamani kidogo.
Mwisho wa sehemu ya kwanza.
Hivi karibuni tutachapisha sehemu ya pili ya tafsiri, lakini sasa tunasubiri maoni yako na kukualika , ambayo itafanyika leo saa 20.00.
Chanzo: mapenzi.com