Aceasta va fi o relatare despre impresiile legate de carte, precum și vor fi discutate unele concepte și cunoștințe care, datorită acestei cărți, au fost învățate.
Arhitectură
Puteți, citind această publicație, să oferiți un răspuns clar la întrebarea ce este arhitectura? Ce înseamnă arhitectura în contextul programării și proiectării? Ce rol joacă aceasta? Există destul de multe neclarități în acest termen. Și, deși pare limpede, este oarecum abstract și lipsit de precizie. Martin consideră, și eu sunt de acord cu el, că o aplicație are două componente:
- Comportamentul (behavior) – funcțiile și sarcinile pe care programul (componenta, serviciul) le îndeplinește.
- Arhitectura – acest termen se referă în principal la modificarea aplicației.
Dar chiar dacă aplicația îndeplinește foarte bine sarcina pe care trebuie să o facă, nu înseamnă deloc că are o arhitectură bună. Arhitectura nu este despre comportamentul aplicației. Arhitectura este despre ușurința de modificare, arhitectura este despre ușurința de desfășurare, arhitectura este despre independența dezvoltării. Arhitectura este despre viteza cu care un nou membru al echipei înțelege lucrurile.
Și iată cum să construiești această arhitectură, cum să scapi de durerile de cap atunci când apar modificări minore în cerințele de la PM sau de la stakeholder: despre asta va vorbi cartea.
Despre autori
Înainte de a spune orice despre această carte, vreau să spun câteva lucruri despre mine.
În prezent sunt Strong Junior Developer, specializat în dezvoltarea de servicii folosind ASP .NET CORE.
Deja lucrez de un an într-o "galerie", și pare că mă descurc puțin câte puțin.
Am citit această carte de două ori și o recomand tuturor:
- dezvoltatorilor de sisteme embeded;
- front-end developerilor;
- back-end developerilor;
- și chiar devops-urilor.
În general, tuturor celor care sunt într-un fel sau altul implicați în dezvoltarea software-ului, mă refer la dezvoltarea efectivă a diferitelor aplicații, nu iau în calcul vânzătorii și PM-ii (deși ar fi util să știi de ce un developer poate să cheltuie de două ori mai mult timp pe o sarcină), vă recomand să citiți această carte.
Și acum voi încerca să argumentez de ce consider asta.
Un pic despre autorul acestei cărți (deoarece pentru mine autoritatea celui ce scrie joacă un rol important). Cred că mă veți înțelege, deși nu este întotdeauna corect, dar dacă vă vorbește o persoană cu autoritate în domeniu — aveți mult mai multă încredere în ceea ce spune. De exemplu, cred că veți crede mai mult în diagnosticul pe care vi-l pune medicul decât în cel al cuiva din mulțime (care a căutat simptomele pe Google).
Robert Martin — cunoscut și sub numele de Uncle Bob (Unchiul Bob) — lucrează în domeniul programării din 1970, acoperind diferite sisteme (de la servicii web la sisteme embeded). Este consultant tehnic și arhitect, a scris pentru diverse reviste tehnice, fiind un programator foarte experimentat și o persoană care a avut un rol esențial în crearea bine cunoscutelor principii SOLID (poate fi considerat creatorul). De asemenea, aș vrea să adaug că mi-a recomandat această carte liderul echipei mele, care are peste 15 ani de experiență.
Despre carte
Dependințe
Înainte de a citi cartea, am citit destul de multe articole pe același site, unde apărea cuvântul „dependență”. Ce înseamnă aceasta, cine este dependent de cine, ce înseamnă, în mod concret, „a depinde” și cum poate un anumit clasă să depindă de alta?
Și, pe măsură ce am citit cartea, am învățat două lucruri:
Dependența este un termen care înseamnă că o anumită clasă (componentă, serviciu) știe despre o altă clasă (componentă, serviciu) și această cunoaștere la nivel de cod este definită (acum programatorii Java, C# și C vor înțelege asta) printr-un anumit import de namespace. Cu alte cuvinte: dacă aveți clasa A cu namespace-ul Default.Classes și clasa B cu Another.Classes. Așadar, dacă în codul sursă al clasei A apare using Another.Classes; — înseamnă că clasa A depinde de clasa B.
Pentru a înțelege din diagramă care este clasa dependentă și care nu — priviți direcția săgeții: în 1) săgeata va indica de la clasa A către clasa B. Acest lucru înseamnă că clasa B este mai independentă decât clasa A. Și modificările din clasa A nu vor cauza niciun „dăun” clasei B.
SOLID
Una dintre principalele motive pentru care am citit această carte — este explicația principiilor SОLID din prima sursă, deoarece unchiul Rob a dezvoltat aceste principii și se poate spune că datorită lui auzim acest nume — SOLID.
Pentru cei care nu știu, aceste principii indică și recomandă să ne proiectăm aplicațiile conform celor 5 reguli:
S — SRP (Principiul responsabilității unice)
O — OCP (Principiul deschis-închis)
L — LSP (Principiul de substituție Liskov)
I — ISP (Principiul segregării interfețelor)
D — DIP (Principiul inversării dependenței)
Toate aceste principii pot fi aplicate la nivelul claselor și obiectelor, al modulelor și componentelor, precum și la nivelul straturilor (serviciilor).
Dacă considerați că Principiul responsabilității unice se referă la faptul că o clasă sau un modul ar trebui să facă doar un singur lucru, atunci trebuie să citiți măcar un capitol despre SOLID. Definiția dată mai sus este o consecință, dar nu este definiția propriu-zisă a principiului.
Despre inversarea dependenței
Aș dori să acord o atenție specială clarificării Principiului inversării dependenței (cel care este D din SOLID). Pe parcursul lecturii cărții, am realizat că nu este doar un principiu, ci și un mecanism și un instrument prin care puteți schimba direcția dependențelor dumneavoastră și face, de exemplu, logica de afaceri (DOMAIN) independentă de detaliile de implementare ale stratului de acces la date (DAL).
Deși principiul în sine, alături de celelalte din SOLID, înseamnă puțin altceva decât mecanismul, acest mecanism este folosit pe parcursul întregii cărți și este unul dintre metodele principale de a inversa și schimba direcția dependențelor dumneavoastră, care este folosit și în DDD.
Despre luarea deciziilor arhitecturale
Foarte des, în carte, se va face referire la principiul luării unor decizii arhitecturale importante: despre ce bază de date să folosiți, ce cadru să utilizați, ce bibliotecă să conectați, ce să folosiți ca motor de căutare etc.
Așadar, autorul consideră că ar trebui să luați CÂT MAI PUȚINE astfel de decizii. Deoarece cerințele se pot schimba, restricțiile de performanță, de asemenea, natura comportamentală tinde să se schimbe. În procesul de dezvoltare, o anumită decizie poate părea mai puțin eficientă decât alta, mai puțin convenabilă decât alta. Și puterea arhitecturii tale va determina cât de rapid și fără durere poți înlocui o tehnologie cu alta (despre asta, de altfel, se vorbește și în OCP).
De exemplu, brusc, ai decis să folosești, în loc de Postgresql, MongoDb, sau chiar fișiere, sau să folosești date simulate, cu care operațiile se vor efectua în memorie. Și în anumite condiții — acest lucru poate obliga să rescrii aproape întreaga logică.
Pentru a preveni astfel de situații, putem utiliza anumite mecanisme care vor maximiza timpul de luare a deciziilor. Unul dintre aceste mecanisme este abstracția.
Referințe la DDD
DDD — Domain Driven Design — este o abordare pentru dezvoltarea serviciilor cu logică de afaceri complexă, critică la schimbări, care se concentrează pe înțelegerea maximă a rolurilor de conducere în proiect (PMs, Manageri de vânzări etc.) împreună cu membrii echipelor. Adică, se dovedește că între toți membrii proiectului există un limbaj omniprezent, astfel încât fiecare să poată înțelege pe ceilalți, iar toți să gândească într-un singur domeniu cu aceleași reguli de afaceri.
Dacă ești un susținător al DDD, sau vrei să devii unul, sau nu înțelegi nimic din asta, dar vrei să înțelegi — cartea este obligatorie de citit, în special partea a doua.
Aici autorul explică existența Regulii Dependenței și de ce, urmând-o, vei construi o arhitectură corectă a aplicației. De ce dependențele trebuie să urmeze o direcție către componentele de Politică Înaltă, de ce. domeniu (Componența de Politică Înaltă) trebuie să fie independentă de infrastructură și cum acest lucru îți va simplifica desfășurarea și dezvoltarea.
Abstrahere
Uncle Bob, de asemenea, vorbește despre cum detaliile de implementare pot dăuna sistemului tău și nu îți vor permite să evoluezi fără durere în viitor.
Amintește-ți!
BD este un detaliu de implementare
Clienții (Web, Mobil etc.) sunt detalii de implementare
Framework-urile sunt detalii de implementare
Trebuie să te abstrezi cât mai mult de toate acestea și să nu depinzi, utilizând inversarea dependențelor descrisă mai sus cu interfețe și abstrații, Regulile de Dependență și alte mecanisme.
Metode de construire a modulelor
Această secțiune mi-a plăcut în mod deosebit, ca dezvoltator de servicii pe ASP .NET CORE. Aici se discută despre metodologiile de construire a unei arhitecturi unice a serviciului din componentele existente.
Robert a descris 4 scheme posibile de separare a straturilor.
El a lăsat de înțeles de ce mecanismul deseori utilizat al arhitecturii în 3 straturi: UI (controale), Servicii (Domeniu), DAL (Bază de date) — este destul de slab în comparație cu altele. Am văzut nu foarte multe proiecte, dar în fiecare, de exemplu în micro-servicii, pe backend, se folosește exact arhitectura în trei straturi.
De asemenea, destul de des, se folosește arhitectura un-component-un-serviciu. În general, ambele sunt acceptabile, dar aceasta are destul de multe dezavantaje comparativ cu modul în care se construiește arhitectura folosind DDD, mai ales în cazul serviciilor critice pentru modificare și complexe.
În concluzie, acest review al cărții a ajuns la final. Mie mi-a plăcut foarte mult cartea, nu regret că am citit-o, mulțumesc autorului. Voi, dragi cititori, mulțumesc pentru atenție, nu judecați prea aspru — această publicație este bazată pe impresiile mele despre carte și pe entuziasmul meu personal.
Sursa: habr.com
