Ky do të jetë një tregim mbi impresionet për librin, si dhe disa koncepte dhe njohuri që, falë këtij libri, janë mësuar.
Arkitektura
A mund të jepni një përgjigje të qartë për pyetjen se çfarë është arkitektura? Çfarë është arkitektura në kontekstin e programimit dhe dizajnit? Çfarë roli luan ajo? Ka mjaft pasiguri për këtë term. Duket se gjithçka është e qartë, por ndonjëherë është paksa abstrakte dhe pa saktësi. Martin beson, dhe unë jam dakord me të, se aplikacioni ka dy komponentë:
- Shtimi (behavior) — funksionet dhe detyrat që programi (komponenti, shërbimi) i kryen.
- Arkitektura — ky term në masë të madhe lidhet me ndryshimin e aplikacionit.
Por shumë, nëse aplikacioni bën shumë mirë detyrën që duhet të kryejë, kjo nuk do të thotë aspak që ai ka një arkitekturë të mirë. Arkitektura nuk ka të bëjë me sjelljen e aplikacionit. Arkitektura ka të bëjë me lehtësinë e ndryshimeve, arkitektura ka të bëjë me lehtësinë e shpërndarjes, arkitektura ka të bëjë me pavarësinë e zhvillimit. Arkitektura ka të bëjë me shpejtësinë me të cilën njohuria arrin tek një person i ri në ekip.
Dhe kështu të ndërtojmë këtë arkitekturë, si të heqim dorë nga dhimbja e kokës për ndryshimet e vogla të kërkesave nga PM ose nga palët e interesit: për këtë flet libri.
Për autorët
Para se të them diçka për këtë libër, dua të them pak rreth vetes.
Aktualisht unë jam Strong Junior Developer, i specializuar në zhvillimin e shërbimeve përmes ASP .NET CORE.
Kam punuar për një vit në një “galerë”, dhe duket se po e përballoj pak nga pak.
E kam lexuar këtë libër 2 herë dhe e rekomandoj për të lexuar të gjithëve:
- zhvilluesve të sistemeve embedded;
- front-end developerëve;
- back-end developerëve;
- dhe madje edhe DevOps.
Për të gjithë ata që janë ndërlidhur në ndonjë mënyrë me zhvillimin e softuerit, duke iu referuar zhvillimit të drejtpërdrejtë të ndrysheve si Sales dhe PM, këtu nuk përfshihen (edhe pse do të ishte e dobishme të dija pse disa zhvillues ndonjëherë shpenzojnë dy herë më shumë kohë në një detyrë), ju rekomandoj të lexoni këtë libër.
Dhe tani do të përpiqem të argumentoj se pse mendoj kështu.
Pak rreth autorit të këtij libri (sepse për mua autoriteti i shkrimtarit ka një rol të madh). Mendoj se do të më kuptoni, ndonëse kjo nuk është gjithmonë e drejtë, por nëse një person autoritar në fushë ju thotë diçka — ju tregoni shumë më shumë besim në atë që ai thotë. Për shembull, mendoj se ju do të besoni më shumë në diagnostikimin që ju jep mjeku, sesa nga ndonjë person tjetër nga turma (që ka kërkuar informacion rreth simptomeve).
Robert Martin — i njohur si Uncle Bob — punon në fushën e programimit, përfshirë sistemet e ndryshme (nga shërbimet në internet deri te sistemet e inkorporuara), që nga viti 1970. Ai është një këshilltar teknik dhe arkitekt, ka shkruar për revista të ndryshme teknike, është një programues shumë i përvojshëm dhe një person që ka luajtur një nga rolet kyçe në krijimin e principeve të njohura SOLID (mund të thuhet se është krijuesi i tyre). Gjithashtu, dua të shtoj se këtë libër ma rekomandoi timlidi im me mbi 15 vjet përvojë në punë.
Rreth librit
Varësitë
Para se të filloja të lexoja librin, kam lexuar mjaft artikuj në të njëjtën faqe në internet, ku përmendej një fjalë si "varësi". Çfarë është kjo, kush është i varur nga kush, çfarë do të thotë konkretisht "të jesh i varur" dhe si mund të varet një klasë nga dikush tjetër?
Dhe kështu, gjatë leximit të librit, kuptova dy pika:
Varësia është një term që do të thotë se një klasë (komponent, shërbim) di për një klasë tjetër (komponent, shërbim), dhe kjo dije në nivelin e kodit përcaktohet (tani programuesit e Java, C#, dhe C do të më kuptojnë) me një import të caktuar të hapësirës së emrave. Me fjalë të tjera: keni një klasë A me hapësirën e emrave Default.Classes dhe një klasë B Another.Classes. Pra, nëse në kodin burimor të klasës A do të shfaqet using Another.Classes; — kjo do të thotë se klasa A varet nga klasa B.
Për të kuptuar nga skema, ku është klasa e varur dhe ku nuk është — shikoni drejtimin e shigjetës: në 1) shigjeta do të tregojë nga klasa A drejt klasës B. Kjo do të thotë se klasa B është më e pavarur se klasa A. Dhe ndryshimet në klasën A, nuk do t'i shkaktojnë asnjë 'dëm' klasës B.
SOLID
Një nga arsyet kryesore që më nxitën të lexoj këtë libër është shpjegimi i principeve SОLID nga burimi i parë, sepse Xhaxhi Rob i zhvilloi këto principe dhe mund të thuhet se falë tij ne dëgjojmë këtë emër — SOLID.
Për ata që nuk janë në dijeni — këto principe flasin dhe sugjerojnë që të dizenjoni aplikacionet tua përkatësisht me 5 rregulla:
S — SRP (Principi i përgjegjësisë së vetme)
O — OCP (Principi i Hapur-mbyllur)
L — LSP (Përgjigjja e Zëvendësimit të Liskovit)
I — ISP (Parimi i Ndashjes së Interface)
D — DIP (Parimi i Invertimit të Varësive)
Të gjithë këta parime mund të aplikohen në nivelin e klasave dhe objekteve, në nivelin e moduleve dhe komponenteve dhe në nivelin e shtresave (shërbimeve).
Nëse mendoni se Parimi i përgjegjësisë së vetme i referohet faktit që klasa ose moduli duhet të bëjë vetëm një gjë — atëherë ju duhet të lexoni të paktën një kapitull mbi SOLID. Sepse ajo përkufizim që u dha më lart është një pasojë, por jo përkufizimi i vetë parimit.
Për Invertimin e Varësive
Dua të theksoj shpjegimin e Parimit të Invertimit të Varësive (ai që është D në SOLID). Gjatë leximit të librit, kuptova se, kjo nuk është thjesht një parim, është gjithashtu një mekanizëm dhe mjet, me anë të të cilit mund të ndryshoni drejtimin e varësive tuaja dhe të bëni, p.sh., logjikën e biznesit (DOMAIN) të pavarur nga detajet e implementimit të Shtresës së Qasjes në Të Dhëna (DAL).
Megjithëse parimi vetë, së bashku me të tjerët në SOLID, do të thotë pak më ndryshe nga mekanizmi, ky mekanizëm përdoret gjatë gjithë librit dhe është një nga metodat kryesore për të invertuar dhe ndryshuar drejtimin e varësive tuaja, i cili, gjithashtu, përdoret në DDD.
Rreth marrjes së vendimeve arkitektonike
Shumë shpesh në libër do të përmendet principi i marrjes së vendimeve të rëndësishme arkitektonike: për atë, çfarë DB të përdoret, cilin framework të përdoret, cilën bibliotekë të lidhet, çfarë të përdoret si motor kërkimi, etj.
Kështu, autori mendon: duhet të merrni sa më pak vendime të tilla. Sepse kërkesat mund të ndryshojnë, kufizimet për performancën gjithashtu, dhe komponenti i sjelljes ka tendencë të ndryshojë. Gjatë zhvillimit, një vendim mund të duket më pak efektiv se një tjetër, më pak i rehatshëm se një tjetër. Dhe fuqia e arkitekturës tuaj do të përcaktojë, sa shpejt dhe pa dhimbje do të mund të zëvendësoni një teknologji me një tjetër (për këtë, OCP e thekson).
Për shembull, papritur, vendosni të përdorni në vend të Postgresql MongoDb, ose madje skedarë, ose të përdorni të dhëna të simuluara, operacionet me të cilat do të kryhen në memorie. Dhe në disa kushte — kjo mund t'ju detyrojë të shkruani përsëri pothuajse gjithë logjikën.
Për të parandaluar situata të tilla, ne mund të përdorim disa mekanizma që do të shtyjnë sa më larg që të jetë e mundur kohën e marrjes së vendimeve. Një nga këta mekanizma është abstraksioni.
Referencat në DDD
DDD — Design i Bazuar në Domain — është një qasje për zhvillimin e shërbimeve me logjikë të komplikuar biznesi, kritike ndaj ndryshimeve, e cila synon të maksimizojë kuptimin e pozita drejtuesve të projektit (PM, menaxherë shitjesh etj.), për të bërë që të gjithë anëtarët e projektit të kenë një gjuhë ubiquitaire, që secili të mund të kuptojë tjetrin dhe të mendojnë në të njëjtin domain me të njëjtat rregulla biznesi.
Nëse jeni një mbështetës i DDD, ose dëshironi të jeni, ose nuk kuptoni diçka në këtë aspekt, por dëshironi ta kuptoni — libri është i detyrueshëm për t'u lexuar, veçanërisht pjesa e dytë e librit.
Këtu autori shpjegon mbi ekzistencën e Rregullit të Varësisë dhe arsyen pse, duke e ndjekur atë — ju do të ndërtoni një arkitekturë të duhur të aplikacionit. Pse varësitë duhet të ndjekin drejtimin ndaj komponenteve të Politikes së Lartë, pse domain (komponenti i Politikës së Lartë) duhet të jetë i pavarur nga infrastruktura dhe si kjo do t'ju thjeshtojë shpërndarjen dhe zhvillimin.
Abstraksioni
Daja Rob, gjithashtu tregon se si detajet e implementimit mund të dëmtojnë sistemin tuaj dhe të pengojnë evolucionin pa dhimbje në të ardhmen.
Mos harroni!
Baza e të dhënave është një detaj i implementimit
Klientët (Web, Mobile, etj) janë detaje të implementimit
Framework-et janë një detaj i implementimit
Duke u ndarë sa më shumë nga këto dhe duke mos u varur, duke përdorur mbi të gjitha Inversionin e Varësisë me ndërfaqet dhe abstraksionet, Rregullin e Varësisë dhe mekanizma të tjerë.
Metodat e ndërtimit të moduleve
Ky seksion më pëlqeu veçanërisht si zhvillues i shërbimeve në ASP .NET CORE. Sepse këtu flitet për metodologjitë e ndërtimit të një arkitekture të vetme shërbimi nga komponentët e gatshëm.
Robert përshkroi 4 skema të mundshme për ndarjen e niveleve.
Ai bëri të qartë pse mekanizmi kaq shpesh i përdorur i arkitekturës me 3 nivele: UI (kontrollerët), Shërbimet (Domeni), DAL (Baza e të dhënave) është mjaft i dobët krahasuar me të tjerët. Kam parë jo shumë projekte, por në çdo mikro-shërbim, në backend përdoret pikërisht arkitektura me tre nivele.
Gjithashtu, shpesh përdoret arkitektura një-komponent-një-shërbim. Në përgjithësi, të dyja janë të mira, por ajo ka shumë mangësi në krahasim, për shembull, me ndërtimin e arkitekturës duke përdorur DDD, posaçërisht në shërbime që janë kritike ndaj ndryshimeve dhe komplekse.
Në përgjithësi, ky është përfundimi i këtij rishikimi të librit. Libri më pëlqeu shumë, nuk e pendohesha për atë që lexova, faleminderit autorit. Ju, të dashur lexues, faleminderit për vëmendjen, mos gjykoni ashpër — kjo publikim bazohet në përshtypjet nga libri dhe entuziazmin tim personal.
Burimi: habr.com
