Helo ffrindiau. Gan ragweld lansiad y cwrs , yn draddodiadol yn rhannu'r cyfieithiad o ddeunydd defnyddiol gyda chi.
Mae meddalwedd yn datrys mwy a mwy o dasgau bob dydd, wrth ddod yn fwy a mwy cymhleth. Fel y dywedodd Marc Andressen unwaith, mae'n bwyta'r byd.
O ganlyniad, mae'r ffordd y caiff cymwysiadau eu datblygu a'u cyflwyno wedi newid yn aruthrol dros yr ychydig flynyddoedd diwethaf. Roedd y rhain yn newidiadau ar raddfa tectonig a arweiniodd at set o egwyddorion. Mae'r egwyddorion hyn wedi bod yn ddefnyddiol wrth adeiladu tîm, dylunio, datblygu a chyflwyno'ch cais i ddefnyddwyr terfynol.
Gellir crynhoi’r egwyddorion fel a ganlyn: dylai'r cais fod yn fach, yn seiliedig ar y we, a dylai fod ganddo bensaernïaeth sy'n canolbwyntio ar y datblygwr. Gyda'r tair egwyddor hyn mewn golwg, gallwch greu cymhwysiad cadarn, o'r dechrau i'r diwedd y gellir ei gyflwyno'n gyflym ac yn ddiogel i'r defnyddiwr terfynol, ac sy'n hawdd ei raddio a'i ymestyn.
Mae gan bob un o'r egwyddorion arfaethedig nifer o agweddau y byddwn yn eu trafod i ddangos sut mae pob egwyddor yn cyfrannu at y nod eithaf, sef cyflwyno cymwysiadau dibynadwy sy'n hawdd eu cynnal a'u defnyddio yn gyflym. Byddwn yn edrych ar yr egwyddorion mewn perthynas â'u gwrthgyferbyniadau er mwyn egluro beth mae'n ei olygu, dywedwch, "Gwnewch yn siŵr eich bod yn defnyddio egwyddor bychander'.
Gobeithiwn y bydd yr erthygl hon yn eich annog i ddefnyddio'r egwyddorion arfaethedig ar gyfer adeiladu cymwysiadau modern, a fydd yn darparu ymagwedd unedig at ddylunio yng nghyd-destun pentwr technoleg sy'n tyfu'n barhaus.
Drwy gymhwyso'r egwyddorion hyn, byddwch yn cael eich hun yn manteisio ar y tueddiadau diweddaraf mewn datblygu meddalwedd, gan gynnwys y i ddatblygu a chyflwyno cymwysiadau, y defnydd o gynwysyddion (er enghraifft, ) a fframweithiau offeryniaeth cynwysyddion (er enghraifft, ), y defnydd o ficrowasanaethau (gan gynnwys y Pensaernïaeth Microservice и ar gyfer ceisiadau microwasanaeth.
Beth yw cymhwysiad modern?
Cymwysiadau modern? Stack modern? Beth yn union yw ystyr "modern"?
Dim ond syniad cyffredinol sydd gan y mwyafrif o ddatblygwyr o'r hyn y mae cais modern yn ei gynnwys, felly mae angen diffinio'r cysyniad hwn yn glir.
Mae ap modern yn cefnogi cleientiaid lluosog, boed yn ryngwyneb defnyddiwr llyfrgell React JavaScript, ap symudol Android neu iOS, neu ap sy'n cysylltu ag API arall. Mae cymhwysiad modern yn awgrymu nifer amhenodol o gleientiaid y mae'n darparu data neu wasanaethau ar eu cyfer.
Mae cymhwysiad modern yn darparu API i gael mynediad at y data a'r gwasanaethau y gofynnwyd amdanynt. Dylai'r API fod yn ddigyfnewid ac yn gyson, ac nid wedi'i ysgrifennu'n benodol ar gyfer cais penodol gan gleient penodol. Mae'r API ar gael dros HTTP(S) ac yn darparu mynediad i'r holl swyddogaethau sydd ar gael yn y GUI neu CLI.
Rhaid i'r data fod ar gael mewn fformat rhyngweithredol a dderbynnir yn gyffredin megis JSON. Mae API yn datgelu gwrthrychau a gwasanaethau mewn ffordd lân, drefnus, fel RESTful API neu GraphQL yn darparu rhyngwyneb gweddus.
Mae cymwysiadau modern yn cael eu hadeiladu ar y pentwr modern, a'r pentwr modern yw'r pentwr sy'n cefnogi cymwysiadau o'r fath, yn y drefn honno. Mae'r pentwr hwn yn caniatáu i ddatblygwr greu cymhwysiad yn hawdd gyda rhyngwyneb HTTP a phenawdau API clir. Bydd y dull a ddewiswyd yn caniatáu i'ch cais dderbyn ac anfon data yn hawdd ar fformat JSON. Mewn geiriau eraill, mae'r stac modern yn cyfateb i elfennau'r Cais Deuddeg Ffactor ar gyfer .
Mae fersiynau poblogaidd o'r math hwn o stac yn seiliedig ar , , , , и . Pensaernïaeth Microservice yn cynrychioli enghraifft o stac modern a weithredwyd ym mhob un o'r ieithoedd a grybwyllwyd.
Sylwch nad ydym yn argymell dull gweithredu microwasanaeth yn unig. Mae llawer ohonoch yn gweithio gyda monolithau y mae angen iddynt esblygu, tra bod eraill yn delio â chymwysiadau SOA sy'n ehangu ac yn esblygu i ddod yn gymwysiadau microwasanaeth. Mae eraill yn symud tuag at gymwysiadau di-weinydd, ac mae rhai yn gweithredu cyfuniadau o'r uchod. Mae'r egwyddorion a amlinellir yn yr erthygl yn berthnasol i bob un o'r systemau hyn gyda dim ond ychydig o fân addasiadau.
Egwyddorion
Nawr bod gennym ddealltwriaeth gyffredin o beth yw cymhwysiad modern a stac modern, mae'n bryd plymio i'r egwyddorion pensaernïaeth a datblygu a fydd yn eich gwasanaethu'n dda wrth ddatblygu, gweithredu a chynnal cymhwysiad modern.
Mae un o'r egwyddorion yn swnio fel "gwneud cymwysiadau bach", gadewch i ni ei alw egwyddor bychander. Mae yna gymwysiadau hynod gymhleth sy'n cynnwys llawer o rannau symudol. Yn ei dro, mae adeiladu cymhwysiad o gydrannau bach, arwahanol yn ei gwneud hi'n haws dylunio, cynnal a gweithio gydag ef yn ei gyfanrwydd. (Noder ein bod wedi dweud "symleiddio" nid "gwneud yn syml").
Yr ail egwyddor yw y gallwn gynyddu cynhyrchiant datblygwyr trwy eu helpu i ganolbwyntio ar y nodweddion y maent yn eu datblygu, tra'n eu rhyddhau rhag pryderon seilwaith a CI/CD wrth weithredu. Felly, yn gryno, ein hymagwedd canolbwyntio ar ddatblygwyr.
Yn olaf, rhaid cysylltu popeth am eich cais â'r rhwydwaith. Dros yr 20 mlynedd diwethaf, rydym wedi cymryd camau breision tuag at ddyfodol rhwydweithiol wrth i rwydweithiau ddod yn gyflymach a chymwysiadau yn fwy cymhleth. Fel y gwelsom eisoes, mae'n rhaid i lawer o wahanol gleientiaid ddefnyddio cymhwysiad modern dros rwydwaith. Mae cymhwyso meddylfryd rhwydwaith i bensaernïaeth â buddion sylweddol sy'n cyd-fynd yn dda â nhw egwyddor bychander a chysyniad y dull, yn canolbwyntio ar y datblygwr.
Os byddwch yn cadw'r egwyddorion hyn mewn cof wrth ddylunio a gweithredu cais, bydd gennych fantais ddiymwad yn natblygiad a chyflwyniad eich cynnyrch.
Edrychwn ar y tair egwyddor hyn yn fanylach.
Egwyddor bychander
Mae'n anodd i'r ymennydd dynol ganfod llawer iawn o wybodaeth ar yr un pryd. Mewn seicoleg, mae'r term llwyth gwybyddol yn cyfeirio at gyfanswm yr ymdrech feddyliol sydd ei angen i gadw gwybodaeth yn y cof. Mae lleihau'r llwyth gwybyddol ar ddatblygwyr yn flaenoriaeth oherwydd ei fod yn caniatáu iddynt ganolbwyntio ar ddatrys y broblem yn lle cadw'r model cymhleth presennol o'r cais cyfan a'r nodweddion sy'n cael eu datblygu yn eu pen.
Mae ceisiadau'n dadelfennu am y rhesymau canlynol:
- Llai o lwyth gwybyddol ar ddatblygwyr;
- Cyflymu a symleiddio'r profion;
- Cyflwyno newidiadau yn y cais yn gyflym.
Mae yna sawl ffordd o leihau'r llwyth gwybyddol ar ddatblygwyr, a dyma lle mae'r egwyddor o fod yn fach yn dod i rym.
Felly dyma dair ffordd i leihau llwyth gwybyddol:
- Lleihau'r ffrâm amser y mae'n rhaid iddynt ei hystyried wrth ddatblygu nodwedd newydd - y byrraf yw'r amserlen, yr isaf yw'r llwyth gwybyddol.
- Lleihau faint o god y mae gwaith un-amser yn cael ei wneud arno - llai o god - llai o lwyth.
- Symleiddio'r broses o wneud newidiadau cynyddol i gais.
Lleihau'r amserlen datblygu
Gadewch i ni fynd yn ôl at y dyddiau pan fydd y fethodoleg waterfall oedd y safon ar gyfer y broses ddatblygu, ac roedd amserlenni o chwe mis i ddwy flynedd ar gyfer datblygu neu ddiweddaru cais yn arfer cyffredin. Yn nodweddiadol, byddai peirianwyr yn gyntaf yn darllen dogfennau perthnasol fel y gofynion cynnyrch (PRD), dogfen gyfeirio system (SRD), glasbrint pensaernïaeth, ac yn dechrau cyfuno'r holl bethau hyn gyda'i gilydd yn un model gwybyddol, yn unol â pha un y gwnaethant godio. Wrth i'r gofynion ac, o ganlyniad, y bensaernïaeth newid, bu'n rhaid gwneud ymdrech ddifrifol i hysbysu'r tîm cyfan am ddiweddariadau i'r model gwybyddol. Gallai dull o’r fath, ar y gwaethaf, barlysu’r gwaith yn unig.
Y newid mwyaf yn y broses o ddatblygu ceisiadau oedd cyflwyno'r fethodoleg ystwyth. Un o brif nodweddion y fethodoleg agile yn ddatblygiad ailadroddol. Yn ei dro, mae hyn yn arwain at ostyngiad yn y llwyth gwybyddol ar beirianwyr. Yn lle ei gwneud yn ofynnol i'r tîm datblygu weithredu'r cais mewn un cylch hir, agile dull gweithredu yn caniatáu ichi ganolbwyntio ar symiau bach o god y gellir eu profi a'u defnyddio'n gyflym, tra hefyd yn derbyn adborth. Mae llwyth gwybyddol yr ap wedi symud o ffrâm amser chwe mis i ddwy flynedd gyda llawer iawn o fanylebau ar gyfer ychwanegiad pythefnos neu newid nodwedd yn targedu dealltwriaeth fwy aneglur o ap mawr.
Mae symud y ffocws o gymhwysiad enfawr i nodweddion bach penodol y gellir eu cwblhau mewn sbrint pythefnos, gyda dim mwy nag un nodwedd cyn y sbrint nesaf mewn golwg, yn newid sylweddol. Roedd hyn yn caniatáu inni gynyddu cynhyrchiant datblygu tra'n lleihau'r llwyth gwybyddol, a oedd yn amrywio'n gyson.
Mewn methodoleg agile disgwylir i'r cais terfynol fod yn fersiwn wedi'i addasu ychydig o'r cysyniad gwreiddiol, felly mae pwynt olaf y datblygiad o reidrwydd yn amwys. Dim ond canlyniadau pob sbrint penodol all fod yn glir ac yn fanwl gywir.
Cronfeydd cod bach
Y cam nesaf wrth leihau llwyth gwybyddol yw lleihau'r sylfaen cod. Fel rheol, mae cymwysiadau modern yn enfawr - gall cymhwysiad menter cadarn gynnwys miloedd o ffeiliau a channoedd o filoedd o linellau o god. Yn dibynnu ar sut mae'r ffeiliau wedi'u trefnu, gall cysylltiadau a dibyniaethau rhwng cod a ffeiliau fod yn amlwg, neu i'r gwrthwyneb. Gall hyd yn oed difa chwilod gweithredu cod ei hun fod yn broblemus, yn dibynnu ar y llyfrgelloedd a ddefnyddir a pha mor dda y mae'r offer dadfygio yn gwahaniaethu rhwng llyfrgelloedd/pecynnau/modiwlau a chod arferiad.
Gall adeiladu model meddwl gweithredol o god cais gymryd llawer iawn o amser, ac unwaith eto gosod baich gwybyddol mawr ar y datblygwr. Mae hyn yn arbennig o wir ar gyfer seiliau cod monolithig, lle mae llawer iawn o god, nad yw'r rhyngweithio rhwng y cydrannau swyddogaethol wedi'i ddiffinio'n glir, ac mae gwahanu gwrthrychau sylw yn aml yn aneglur oherwydd nad yw ffiniau swyddogaethol yn cael eu parchu.
Un o'r ffyrdd effeithiol o leihau'r llwyth gwybyddol ar beirianwyr yw symud i bensaernïaeth microwasanaeth. Mewn dull microwasanaeth, mae pob gwasanaeth yn canolbwyntio ar un set o nodweddion; tra bod ystyr y gwasanaeth fel arfer yn cael ei ddiffinio ac yn ddealladwy. Mae ffiniau gwasanaeth hefyd yn glir - cofiwch fod cyfathrebu â gwasanaeth yn cael ei wneud trwy API, felly mae'n hawdd trosglwyddo data a gynhyrchir gan un gwasanaeth i un arall.
Mae rhyngweithio â gwasanaethau eraill fel arfer yn gyfyngedig i ychydig o wasanaethau defnyddwyr ac ychydig o wasanaethau darparwr sy'n defnyddio galwadau API syml a glân, megis defnyddio REST. Mae hyn yn golygu bod y llwyth gwybyddol ar y peiriannydd yn cael ei leihau'n ddifrifol. Yr her fwyaf o hyd yw deall y model rhyngweithio gwasanaeth a sut mae pethau fel trafodion yn digwydd ar draws gwasanaethau lluosog. O ganlyniad, mae'r defnydd o ficrowasanaethau yn lleihau llwyth gwybyddol trwy leihau faint o god, diffinio ffiniau gwasanaeth clir, a darparu dealltwriaeth o'r berthynas rhwng defnyddwyr a darparwyr.
Newidiadau cynyddrannol bach
Elfen olaf yr egwyddor bychander yw rheoli newid. Mae'n demtasiwn arbennig i ddatblygwyr edrych ar y sylfaen cod (hyd yn oed efallai eu cod hŷn eu hunain) a dweud, "Mae hyn yn crap, mae angen i ni ailysgrifennu'r cyfan." Weithiau dyma'r penderfyniad cywir, ac weithiau ddim. Mae'n rhoi baich newid model byd-eang ar y tîm datblygu, sydd yn ei dro yn arwain at lwyth gwybyddol enfawr. Mae'n well i beirianwyr ganolbwyntio ar y newidiadau y gallant eu gwneud yn ystod y sbrint, fel y gallant gyflwyno'r swyddogaethau angenrheidiol yn amserol, er yn raddol. Dylai'r cynnyrch terfynol fod yn debyg i'r un a gynlluniwyd ymlaen llaw, ond gyda rhai addasiadau a phrofion i weddu i anghenion y cleient.
Wrth ailysgrifennu darnau mawr o god, weithiau nid yw'n bosibl cyflawni'r newid yn gyflym oherwydd bod dibyniaethau system eraill yn dod i rym. Er mwyn rheoli llif y newidiadau, gallwch ddefnyddio cuddio nodwedd. Mewn egwyddor, mae hyn yn golygu bod y swyddogaeth yn cael ei chynhyrchu, ond nid yw ar gael gan ddefnyddio'r gosodiadau newidyn amgylchedd (env-var) neu ryw fecanwaith cyfluniad arall. Os yw'r cod wedi pasio'r holl brosesau rheoli ansawdd, yna efallai y bydd yn cael ei gynhyrchu mewn cyflwr cudd. Fodd bynnag, dim ond os yw'r nodwedd wedi'i galluogi yn y pen draw y bydd y strategaeth hon yn gweithio. Fel arall, bydd ond yn annibendod y cod ac yn ychwanegu llwyth gwybyddol y bydd yn rhaid i'r datblygwr ddelio ag ef er mwyn bod yn gynhyrchiol. Mae rheoli newid a newidiadau cynyddrannol eu hunain yn helpu i gadw llwyth gwybyddol datblygwyr ar lefel fforddiadwy.
Mae'n rhaid i beirianwyr oresgyn llawer o anawsterau hyd yn oed gyda chyflwyniad syml o ymarferoldeb ychwanegol. Ar ran y rheolwyr, byddai'n ddoeth lleihau'r baich diangen ar y tîm fel y gall ganolbwyntio ar elfennau swyddogaethol allweddol. Mae tri pheth y gallwch eu gwneud i helpu eich tîm datblygu:
- Defnyddio methodoleg
agilecyfyngu ar yr amserlen y mae'n rhaid i'r tîm ganolbwyntio ynddi ar nodweddion allweddol. - Gweithredwch eich cais fel microwasanaethau lluosog. Bydd hyn yn cyfyngu ar nifer y nodweddion y gellir eu gweithredu ac yn atgyfnerthu'r ffiniau sy'n cadw'r llwyth gwybyddol yn y gwaith.
- Mae'n well gennyf newidiadau cynyddrannol dros fawr ac anhylaw, newid darnau bach o god. Defnyddiwch guddfan nodwedd i weithredu newidiadau hyd yn oed os nad ydynt yn weladwy ar unwaith ar ôl cael eu hychwanegu.
Os byddwch chi'n cymhwyso'r egwyddor o fod yn fach yn eich gwaith, bydd eich tîm yn llawer hapusach, yn canolbwyntio'n well ar weithredu'r nodweddion angenrheidiol, ac yn fwy tebygol o gyflwyno newidiadau ansoddol yn gyflymach. Ond nid yw hyn yn golygu na all y gwaith ddod yn fwy cymhleth, weithiau, i'r gwrthwyneb, mae cyflwyno swyddogaeth newydd yn gofyn am addasu nifer o wasanaethau, a gall y broses hon fod yn anoddach na'r tebyg mewn pensaernïaeth monolithig. Beth bynnag, mae manteision cymryd y dull bach yn werth chweil.
Diwedd y rhan gyntaf.
Yn fuan byddwn yn cyhoeddi ail ran y cyfieithiad, a nawr rydym yn aros am eich sylwadau ac yn eich gwahodd i , a fydd yn digwydd heddiw am 20.00.
Ffynhonnell: hab.com