Ç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.
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.
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.
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.
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.
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:
Arkitektura monolitike
Dizajni i drejtuar nga domeni
Bazuar në komponentë
Mikroshërbime
Tub dhe filtra
I drejtuar nga ngjarjet
Mikrokernel
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:
Ë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ë.
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:
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.
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:
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!