Si të merreni me kompleksitetin gjatë projektimit të sistemeve softuerike

Për çfarë bëhet fjalë?

Çdo ditë, çdo moment gjatë karrierës sonë inxhinierike, ne hasim shumë probleme të ndryshme të kompleksitetit dhe situatave të ndryshme ku duhet të marrim një vendim ose ta shtyjmë atë për shkak të mungesës së të dhënave. Sa herë që ndërtojmë shërbime të reja, ndërtojmë infrastrukturë, apo edhe formojmë procese zhvillimi, ne prekim një botë të madhe sfidash të ndryshme.

Është sfiduese, dhe ndoshta edhe e pamundur, të renditësh të gjitha problemet. Ju do të hasni disa nga këto çështje vetëm nëse punoni në një kamare specifike. Nga ana tjetër, ka shumë që ne të gjithë duhet të kuptojmë se si t'i zgjidhim, pasi ato janë vendimtare për ndërtimin e sistemeve të IT. Me një probabilitet të lartë do t'i hasni në të gjitha projektet.

Në këtë artikull, unë do të ndaj përvojat e mia me disa nga problemet që kam hasur gjatë krijimit të programeve softuerike.

Çfarë është shqetësimi ndërsektorial?

Nëse shikojmë në Wikipedia, do të gjejmë përkufizimin e mëposhtëm

Në zhvillimin e softuerit të orientuar nga aspekti, shqetësimet ndërsektoriale janë aspekte të një programi që prekin disa module, pa mundësinë e përfshirjes në asnjë prej tyre. Këto shqetësime shpesh nuk mund të zbërthehen nga pjesa tjetër e sistemit si në dizajn ashtu edhe në zbatim, dhe mund të rezultojnë në shpërndarje (dyfishim të kodit), ngatërrim (varësi të konsiderueshme midis sistemeve), ose në të dyja.

Ai përshkruan shumë se çfarë është, por unë dua ta zgjeroj dhe thjeshtoj pak:

Një shqetësim ndërsektorial është një koncept ose komponent i sistemit/organizatës që prek (ose 'pret') shumë pjesë të tjera.

Shembujt më të mirë të shqetësimeve të tilla janë arkitektura e sistemit, regjistrimi, siguria, menaxhimi i transaksioneve, telemetria, dizajni i bazës së të dhënave dhe ka shumë të tjera. Ne do të shtjellojmë shumë prej tyre më vonë në këtë artikull.

Në nivelin e kodit, shqetësimet ndër-sektoriale shpesh zbatohen duke përdorur teknika si Programimi i Orientuar në Aspekt (AOP) , ku këto shqetësime modularizohen në komponentë të veçantë që mund të aplikohen në të gjithë aplikacionin. Kjo e mban logjikën e biznesit të izoluar nga këto shqetësime, duke e bërë kodin më të lexueshëm dhe të mirëmbajtur.

Klasifikimi i aspekteve

Ka shumë mënyra të mundshme se si të klasifikohen aspektet duke i segmentuar ato me veti të ndryshme si shtrirja, madhësia, funksionaliteti, rëndësia, objektivi dhe të tjera, por në këtë artikull, unë do të përdor një klasifikim të thjeshtë të fushës. Me këtë, dua të them se ku drejtohet ky aspekt specifik nëse është e gjithë organizata, një sistem i veçantë, apo një element specifik i atij sistemi.

Pra, unë do të ndaj aspektet në makro dhe mikro .

Me aspektin makro nënkuptoj kryesisht konsideratat që ndjekim për të gjithë sistemin si arkitektura e zgjedhur e sistemit dhe dizajni i tij (monolitike, mikroshërbime, arkitekturë e orientuar nga shërbimi), grupi i teknologjisë, struktura organizative, etj. Aspektet makro lidhen kryesisht me strategjinë dhe të nivelit të lartë vendimet.

Ndërkohë, aspekti Micro është shumë më afër nivelit dhe zhvillimit të kodit. Për shembull, cila kornizë përdoret për të bashkëvepruar me bazën e të dhënave, strukturën e projektit të dosjeve dhe klasave, apo edhe modele specifike të projektimit të objekteve.

Ndërsa ky klasifikim nuk është ideal, ai ndihmon për të strukturuar një kuptim të problemeve të mundshme dhe rëndësinë dhe ndikimin e zgjidhjeve që ne aplikojmë për to.

Në këtë artikull, fokusi im kryesor do të jetë në aspektet makro.

Aspektet makro

Struktura organizative

Kur sapo fillova të mësoja për arkitekturën e softuerit, lexova shumë artikuj interesantë rreth ligjit të Conway dhe ndikimit të tij në strukturën organizative. Sidomos ky . Pra, ky ligj thotë se

Çdo organizatë që harton një sistem (të përcaktuar gjerësisht) do të prodhojë një dizajn, struktura e të cilit është një kopje e strukturës së komunikimit të organizatës.

Unë gjithmonë kam besuar se ky koncept është me të vërtetë shumë universal dhe përfaqëson Rregullin e Artë.

Më pas fillova të mësoj qasjen e Eric Evans-it nga Domain-Driven Design (DDD) për sistemet e modelimit. Eric Evans thekson rëndësinë e identifikimit të kontekstit të kufizuar. Ky koncept përfshin ndarjen e një modeli kompleks domeni në seksione më të vogla, më të menaxhueshme, secila me grupin e vet të kufizuar të njohurive. Kjo qasje ndihmon në komunikimin efektiv të ekipit, pasi zvogëlon nevojën për njohuri të gjera të të gjithë domenit dhe minimizon ndërrimin e kontekstit, duke i bërë kështu bisedat më efikase. Ndërrimi i kontekstit është gjëja më e keqe dhe më konsumuese e burimeve ndonjëherë. Edhe kompjuterët po luftojnë me të. Megjithëse nuk ka gjasa të arrihet një mungesë e plotë e ndërrimit të kontekstit, unë mendoj se kjo është ajo për të cilën duhet të përpiqemi.

Duke u kthyer te Ligji i Conway, kam gjetur disa probleme me të.

Çështja e parë që kam hasur me Ligjin e Conway, i cili sugjeron se dizajni i sistemit pasqyron strukturën organizative, është potenciali për formimin e Konteksteve të Kufizuara komplekse dhe gjithëpërfshirëse. Ky kompleksitet lind kur struktura organizative nuk është në linjë me kufijtë e domenit, duke çuar në Kontekste të Kufizuara që janë shumë të ndërvarura dhe të ngarkuara me informacion. Kjo çon në ndërrim të shpeshtë të kontekstit për ekipin e zhvillimit.

Një çështje tjetër është se terminologjia organizative rrjedh në nivelin e kodit. Kur strukturat organizative ndryshojnë, kjo kërkon modifikime të bazës së kodeve, duke konsumuar burime të vlefshme.

Kështu, ndjekja e Manovrës Inverse Conway ndihmon në ndërtimin e sistemit dhe organizimit që inkurajon arkitekturën e dëshiruar të softuerit. Sidoqoftë, vlen të thuhet se kjo qasje nuk do të funksionojë shumë mirë në arkitekturën dhe strukturat tashmë të formuara pasi ndryshimet në këtë fazë janë të zgjatura, por është jashtëzakonisht performuese në startup, pasi ato janë të shpejta për të prezantuar çdo ndryshim.

Topi i madh i baltës

Ky model ose "anti-model" nxit ndërtimin e një sistemi pa asnjë arkitekturë. Nuk ka rregulla, nuk ka kufij dhe nuk ka strategji se si të kontrollohet kompleksiteti i pashmangshëm në rritje. Kompleksiteti është armiku më i frikshëm në rrugëtimin e ndërtimit të sistemeve softuerike.

Për të shmangur ndërtimin e një lloji të tillë të një sistemi, ne duhet të ndjekim rregulla dhe kufizime specifike.

Arkitektura e sistemit

Ekzistojnë një mori përkufizimesh për Arkitekturën e Softuerit. Më pëlqejnë shumë prej tyre pasi mbulojnë aspekte të ndryshme të saj. Megjithatë, për të qenë në gjendje të arsyetojmë për arkitekturën, duhet natyrshëm të formojmë disa prej tyre në mendjet tona. Dhe vlen të thuhet se ky përkufizim mund të evoluojë. Pra, të paktën tani për tani, unë kam përshkrimin e mëposhtëm për veten time.

Arkitektura e Softuerit ka të bëjë me vendimet dhe zgjedhjet që bëni çdo ditë që ndikojnë në sistemin e ndërtuar.

Për të marrë vendime që duhet të keni në "çantën" tuaj parimet dhe modelet për zgjidhjen e problemeve që lindin, është gjithashtu thelbësore të thuhet se të kuptuarit e kërkesave është çelësi për të ndërtuar atë që i nevojitet një biznesi. Sidoqoftë, ndonjëherë kërkesat nuk janë transparente ose madje të pa përcaktuara, në këtë rast, është më mirë të prisni për të marrë më shumë sqarime ose të mbështeteni në përvojën tuaj dhe t'i besoni intuitës suaj. Por gjithsesi, nuk mund të marrësh vendime siç duhet nëse nuk ke parime dhe modele ku të mbështetesh. Këtu po vij te përkufizimi i stilit të arkitekturës së softuerit.

Stili i Arkitekturës së Softuerit është një grup parimesh dhe modelesh që përcaktojnë mënyrën e ndërtimit të softuerit.

Ka shumë stile të ndryshme arkitekturore të fokusuara në anë të ndryshme të arkitekturës së planifikuar, dhe aplikimi i shumëfishtë i tyre në të njëjtën kohë është një situatë normale.

Për shembull, të tilla si:

1. Arkitektura monolitike

2. Dizajni i drejtuar nga domeni

3. Bazuar në komponentë

4. Mikroshërbime

5. Tub dhe filtra

6. I drejtuar nga ngjarjet

7. Mikrokernel

8. I orientuar nga shërbimi

   
   

e kështu me radhë…

Sigurisht, ato kanë avantazhet dhe disavantazhet e tyre, por gjëja më e rëndësishme që kam mësuar është se arkitektura evoluon gradualisht, ndërsa varet nga problemet aktuale. Fillimi me arkitekturën monolitike është një zgjedhje e shkëlqyeshme për reduktimin e kompleksiteteve operacionale, ka shumë të ngjarë që kjo arkitekturë t'i përshtatet nevojave tuaja edhe pasi të keni arritur fazën e përshtatjes së produktit-treg (PMI) të ndërtimit të produktit. Në shkallë, ju mund të konsideroni lëvizjen drejt një qasjeje të drejtuar nga ngjarjet dhe mikroshërbimeve për arritjen e vendosjes së pavarur, mjedisit heterogjen të stivës së teknologjisë dhe arkitekturës më pak të ndërlidhur (dhe më pak transparente ndërkohë për shkak të natyrës së qasjeve të drejtuara nga ngjarjet dhe në pub-sub nëse këto janë miratuar). Thjeshtësia dhe efikasiteti janë afër dhe kanë një ndikim të madh tek njëri-tjetri. Zakonisht, arkitekturat e ndërlikuara ndikojnë në shpejtësinë e zhvillimit të veçorive të reja, duke mbështetur dhe mirëmbajtur ato ekzistuese dhe duke sfiduar evolucionin natyror të sistemit.

Megjithatë, sistemet komplekse shpesh kërkojnë arkitekturë komplekse dhe gjithëpërfshirëse, e cila është e pashmangshme.

Me të drejtë, kjo është një temë shumë e gjerë dhe ka shumë ide të shkëlqyera se si të strukturohen dhe ndërtohen sisteme për evolucionin natyror. Bazuar në përvojën time, unë kam përpunuar qasjen e mëposhtme:

1. Pothuajse gjithmonë fillon me stilin e arkitekturës monolit pasi eliminon shumicën e problemeve që lindin për shkak të natyrës së sistemeve të shpërndara. Gjithashtu ka kuptim të ndiqni monolitin modular për t'u fokusuar në komponentët e ndërtimit me kufij të qartë. Zbatimi i një qasjeje të bazuar në komponentë mund t'i ndihmojë ata të komunikojnë me njëri-tjetrin duke përdorur ngjarje, por të kesh thirrje direkte (aka RPC) i thjeshton gjërat në fillim. Sidoqoftë, është e rëndësishme të gjurmohen varësitë midis komponentëve pasi nëse komponenti A di shumë për komponentin B, ndoshta, ka kuptim t'i bashkojë ato në një.
2. Kur i afroheni situatës kur duhet të shkallëzoni zhvillimin dhe sistemin tuaj, mund të konsideroni të ndiqni modelin Stangler për të nxjerrë gradualisht komponentë që duhet të vendosen në mënyrë të pavarur apo edhe të shkallëzohen me kërkesa specifike.
3. Tani, nëse keni një vizion të qartë për të ardhmen, që është paksa fat i pabesueshëm, mund të vendosni për arkitekturën e dëshiruar. Në këtë moment, ju mund të vendosni të lëvizni drejt arkitekturës së mikroshërbimeve duke aplikuar gjithashtu qasjet e orkestrimit dhe koreografisë, duke përfshirë modelin CQRS për operacionet e shkrimit dhe leximit në shkallë të pavarur, apo edhe duke vendosur të qëndroni me arkitekturën monolitike nëse i përshtatet nevojave tuaja.

Është gjithashtu jetike të kuptosh numrat dhe metrikat si DAU (Përdoruesit aktivë ditore), MAU (Përdoruesit aktivë mujorë), RPC (Kërkesë për sekondë) dhe TPC (Transaksion për sekondë) pasi mund t'ju ndihmojë të bëni zgjedhje sepse arkitektura për 100 përdorues aktivë dhe 100 milionë përdorues aktivë janë të ndryshëm.

Si përfundim, do të thoja se arkitektura ka një ndikim të rëndësishëm në suksesin e produktit. Arkitektura e dizajnuar keq për produktet kërkohet në shkallëzimin, gjë që ka shumë të ngjarë të çojë në dështim pasi klientët nuk do të presin derisa ju të shkallëzoni sistemin, ata do të zgjedhin një konkurrent, kështu që ne duhet të jemi përpara shkallëzimit të mundshëm. Edhe pse e pranoj se ndonjëherë nuk mund të jetë një qasje e dobët, ideja është që të kemi një sistem të shkallëzuar, por jo tashmë të shkallëzuar. Nga ana tjetër, të kesh një sistem shumë të komplikuar dhe tashmë të shkallëzuar pa klientë ose plane për të marrë shumë prej tyre do t'ju kushtojë para për biznesin tuaj për asgjë.

Zgjedhja e pirgut të teknologjisë

Përzgjedhja e një grumbulli teknologjie është gjithashtu një vendim i nivelit makro pasi ndikon në punësimin, perspektivat e evolucionit natyror të sistemit, shkallëzueshmërinë dhe performancën e sistemit.

Kjo është lista e konsideratave themelore për zgjedhjen e një pirg teknologjie:

• Kërkesat dhe kompleksiteti i projektit. Për shembull, një aplikacion i thjeshtë ueb mund të ndërtohet me kornizën Blazor nëse zhvilluesit tuaj kanë përvojë me të, por për shkak të mungesës së pjekurisë së WebAssembly, zgjedhja e React dhe Typescript për sukses afatgjatë mund të jetë një vendim më i mirë.
• Shkallueshmëria dhe nevojat e performancës. Nëse parashikoni të merrni një sasi të madhe trafiku, zgjedhja e ASP.NET Core mbi Django mund të jetë një zgjedhje e mençur për shkak të performancës së tij superiore në trajtimin e kërkesave të njëkohshme. Megjithatë, ky vendim varet nga shkalla e trafikut që prisni. Nëse ju duhet të menaxhoni potencialisht miliarda kërkesa me vonesë të ulët, prania e Grumbullimit të mbeturinave mund të jetë një sfidë.
• Punësimi, koha e zhvillimit dhe kostoja. Në shumicën e rasteve, këta janë faktorët për të cilët duhet të kujdesemi. Koha për në treg, kostoja e mirëmbajtjes dhe stabiliteti i punësimit drejtojnë nevojat e biznesit tuaj pa pengesa.
• Ekspertiza dhe burimet e ekipit. Grupi i aftësive të ekipit tuaj të zhvillimit është një faktor kritik. Në përgjithësi është më efektive të përdoren teknologji me të cilat ekipi juaj tashmë është njohur, përveç nëse ka një arsye të fortë për të investuar në mësimin e një rafte të re.
• Pjekuria. Një komunitet i fortë dhe një ekosistem i pasur bibliotekash dhe mjetesh mund ta lehtësojnë shumë procesin e zhvillimit. Teknologjitë e njohura shpesh kanë mbështetje më të mirë të komunitetit, e cila mund të jetë e paçmueshme për zgjidhjen e problemeve dhe gjetjen e burimeve. Kështu, ju mund të kurseni burime dhe të përqendroheni kryesisht te produkti.
• Mirëmbajtja dhe Mbështetja Afatgjatë. Merrni parasysh qëndrueshmërinë afatgjatë të teknologjisë. Teknologjitë që janë miratuar dhe mbështetur gjerësisht kanë më pak gjasa të vjetërsohen dhe në përgjithësi të marrin përditësime dhe përmirësime të rregullta.

Si mund të ndikojë të pasurit e shumëfishtë teknologjike në rritjen e biznesit?

Nga një këndvështrim, futja e një pirg më shumë mund të shkallëzojë punësimin tuaj, por nga ana tjetër, ajo sjell kosto shtesë të mirëmbajtjes pasi ju duhet t'i mbështesni të dy grupet. Pra, siç thashë më parë, sipas këndvështrimit tim, vetëm nevoja shtesë duhet të jetë një argument për përfshirjen e më shumë rafte teknologjike.

Por çfarë ka të bëjë me parimin e zgjedhjes së mjetit më të mirë për një problem specifik?

Ndonjëherë nuk keni zgjidhje tjetër veçse të sillni mjete të reja për të zgjidhur një problem specifik bazuar në të njëjtat konsiderata të lartpërmendura, në raste të tilla, ka kuptim të zgjidhni zgjidhjen më të mirë.

Krijimi i sistemeve pa lidhje të lartë me një teknologji specifike mund të jetë një sfidë. Megjithatë, është e dobishme të përpiqemi për një gjendje ku sistemi nuk është i lidhur ngushtë me teknologjinë dhe ai nuk do të vdesë nëse nesër, një kornizë ose mjet specifik bëhet i cenueshëm ose madje i zhvlerësuar.

Një konsideratë tjetër e rëndësishme lidhet me varësitë e softuerit me burim të hapur dhe të pronarit. Softueri i pronarit ju jep më pak fleksibilitet dhe mundësi për t'u personalizuar. Megjithatë, faktori më i rrezikshëm është mbyllja e shitësit, ku ju bëheni të varur nga produktet, çmimet, kushtet dhe udhërrëfyesi i një shitësi. Kjo mund të jetë e rrezikshme nëse shitësi ndryshon drejtimin, rrit çmimet ose ndërpret produktin. Softueri me burim të hapur e zvogëlon këtë rrezik, pasi një ent i vetëm nuk e kontrollon atë. Eliminimi i një pike të vetme dështimi në të gjitha nivelet është një çelës për ndërtimin e sistemeve të besueshme për rritje.

Pika e vetme e dështimit (SPOF)

Një pikë e vetme dështimi (SPOF) i referohet çdo pjese të një sistemi që, nëse dështon, do të bëjë që i gjithë sistemi të ndalojë funksionimin. Eliminimi i SPOF-ve në të gjitha nivelet është thelbësor për çdo sistem që kërkon disponueshmëri të lartë. Çdo gjë, duke përfshirë njohuritë, personelin, komponentët e sistemit, ofruesit e cloud dhe kabllot e internetit, mund të dështojnë.

Ka disa teknika bazë që mund të zbatojmë për të eliminuar pikat e vetme të dështimit:

1. Teprica. Zbatimi i tepricës për komponentët kritikë. Kjo do të thotë të kesh komponentë rezervë që mund të marrin përsipër nëse komponenti kryesor dështon. Redundancia mund të aplikohet në shtresa të ndryshme të sistemit, duke përfshirë harduerin (serverët, disqet), rrjetin (lidhjet, ndërprerësit) dhe softuerin (bazat e të dhënave, serverët e aplikacioneve). Nëse jeni duke pritur gjithçka në një Ofrues të Cloud-it dhe madje keni kopje rezervë atje, merrni parasysh ndërtimin e një kopje rezervë të rregullt shtesë në një tjetër për të zvogëluar koston tuaj të humbur në rast fatkeqësie.
2. Qendrat e të Dhënave. Shpërndani sistemin tuaj nëpër vende të shumta fizike, të tilla si qendrat e të dhënave ose rajonet cloud. Kjo qasje mbron sistemin tuaj nga dështimet specifike të vendndodhjes, si ndërprerjet e energjisë elektrike ose fatkeqësitë natyrore.
3. Failover. Aplikoni një qasje të dështimit për të gjithë komponentët tuaj (DNS, CDN, balancuesit e ngarkesës, Kubernetes, Portat API dhe bazat e të dhënave). Meqenëse problemet mund të lindin papritur, është thelbësore të keni një plan rezervë për të zëvendësuar çdo komponent me klonin e tij sipas nevojës me shpejtësi.
4. Shërbime me disponueshmëri të lartë. Sigurohuni që shërbimet tuaja janë ndërtuar për të qenë horizontalisht të shkallëzueshme dhe shumë të disponueshme që në fillim duke iu përmbajtur parimeve të mëposhtme:
   • Praktikoni pashtetësinë e shërbimit dhe shmangni ruajtjen e seancave të përdoruesve në memorien e memories. Në vend të kësaj, përdorni një sistem memorie të shpërndarë, siç është Redis.
   • Shmangni mbështetjen në rendin kronologjik të konsumimit të mesazhit kur zhvilloni logjikën.
   • Minimizoni ndryshimet e thyera për të parandaluar ndërprerjen e konsumatorëve të API. Ku është e mundur, zgjidhni ndryshime të përputhshme me prapavijën. Gjithashtu, merrni parasysh koston pasi ndonjëherë, zbatimi i një ndryshimi të thyer mund të jetë më kosto-efektiv.
   • Inkorporoni ekzekutimin e migrimit në tubacionin e vendosjes.
   • Krijoni një strategji për trajtimin e kërkesave të njëkohshme.
   • Zbatoni zbulimin, monitorimin dhe regjistrimin e shërbimit për të rritur besueshmërinë dhe vëzhgueshmërinë.
   • Zhvilloni logjikën e biznesit për të qenë idempotent, duke pranuar se dështimet e rrjetit janë të pashmangshme.
5. Rishikimi i varësisë. Rishikoni rregullisht dhe minimizoni varësitë e jashtme. Çdo varësi e jashtme mund të prezantojë SPOF të mundshme, prandaj është thelbësore të kuptohen dhe të zbuten këto rreziqe.
6. Ndarja e rregullt e njohurive. Mos harroni kurrë rëndësinë e përhapjes së njohurive brenda organizatës suaj. Njerëzit mund të jenë të paparashikueshëm dhe të mbështetesh te një individ i vetëm është i rrezikshëm. Inkurajoni anëtarët e ekipit që të dixhitalizojnë njohuritë e tyre përmes dokumentacionit. Sidoqoftë, kini parasysh dokumentimin e tepërt. Përdorni mjete të ndryshme të AI për të thjeshtuar këtë proces.

konkluzioni

Në këtë artikull, ne trajtuam disa aspekte kryesore makro dhe si mund të përballemi me kompleksitetin e tyre.

Faleminderit që lexuat! Shihemi herën tjetër!