Ez a történet a könyvvel kapcsolatos benyomásaimról fog szólni, és néhány fogalmat és tudást is tárgyalni fog, amelyeket ennek a könyvnek köszönhetően megtanultak.
építészet
Tud-e a kiadvány elolvasásával egyértelmű választ adni arra a kérdésre, hogy mi az építészet? Mi az architektúra a programozás és a tervezés kontextusában? Milyen szerepet játszik? Elég sok kétértelműség van ebben a kifejezésben. És úgy tűnik, minden világos, de valahogy elvont, és nem precíz. Martin úgy véli, és egyetértek vele, hogy az alkalmazás két összetevőből áll:
- Viselkedés - funkciók és feladatok, amelyeket egy program (összetevő, szolgáltatás) végez.
- Építészet - ez a kifejezés inkább az alkalmazás megváltoztatására vonatkozik.
De még ha egy alkalmazás nagyon jól teljesíti is azt a feladatot, amelyet el kell látnia, ez nem jelenti azt, hogy jó architektúrája van. Az architektúra nem az alkalmazások viselkedéséről szól. Az architektúra a változtatás egyszerűségéről, az architektúra a könnyű telepítésről, az architektúra a fejlesztés függetlenségéről szól. Az építészet arról szól, hogy milyen sebességgel éri el a megértés egy új embert a csapatban
És íme, hogyan kell felépíteni ezt az architektúrát, hogyan lehet megszabadulni a fejfájástól, amikor egy PM vagy egy érdekelt fél a követelményekben kisebb változást tapasztal: erről szól a könyv
A szerzőkről
Mielőtt bármit is mondanék erről a könyvről, szeretnék egy kicsit mondani magamról.
Jelenleg Erős Junior Developer vagyok, ASP .NET CORE-t használó szolgáltatások fejlesztésére szakosodtam.
Már egy éve dolgozom ugyanabban a „galériában”, és úgy tűnik, egy kicsit irányítok
Ezt a könyvet már 2-szer olvastam, mindenkinek ajánlom:
- beágyazott rendszerek fejlesztői;
- front-end mérnökök;
- háttérmunkások;
- és még devopsnak is.
Általánosságban elmondható, hogy mindenki számára, aki bármilyen módon kapcsolódik szoftverfejlesztéshez, a különféle értékesítési és PM-ek közvetlen fejlesztését értjük, itt nem vesszük figyelembe (bár azt is hasznos lenne tudni, hogy a lányok miért költenek néha 2-szert több idő jut egy feladatra), azt tanácsolom, hogy olvassa el ezt a könyvet.
És most megpróbálok érvelni, miért gondolom így
Egy kicsit a könyv szerzőjéről (mert számomra az író tekintélye nagy szerepet játszik). Szerintem meg fogsz érteni, bár ez nem mindig helyes, de ha a szakma tekintélyes embere mond neked valamit, akkor sokkal jobban bízol abban, amit mondott. Például szerintem jobban fog hinni abban a diagnózisban, amit egy orvos ad neked, mint valakinek a tömegből (aki a tüneteket kereste a google-ban)
Robert Martin - alias Bob bácsi (Bob bácsi) - 1970 óta dolgozik a programozás és különféle rendszerek (a webszolgáltatásoktól a beágyazott rendszerekig) területén. műszaki tanácsadó és építész, írt különböző műszaki folyóiratokba, maga is nagyon tapasztalt programozó, aki az egyik kulcsszerepet játszotta a jól ismert SOLID elvek megalkotásában (mondhatnánk az alkotót). Azt is szeretném hozzátenni, hogy ezt a könyvet a 15+ munkatapasztalattal rendelkező csapatvezetőm ajánlotta nekem
A könyvről
Függőségek
A könyv elolvasása előtt elég sok cikket olvastam Habréról, ahol megjelent a „függőség” szó. Mi ez, ki függ kitől, mit jelent pontosan a „függő”, és hogyan függhet egy osztály valakitől?
És ahogy olvastam a könyvet, két dolgot tanultam meg:
A függőség egy olyan kifejezés, amely azt jelenti, hogy egy osztály (összetevő, szolgáltatás) tud egy másik osztályról (komponens, szolgáltatás), és ezt a kódszintű tudást egy bizonyos névtér-import határozza meg (most a javasok, élesek, sishnik megértenek engem) . Más szóval: van A osztálya Default.Classes névtérrel és B osztálya Another.Classes. Tehát, ha az A osztály forráskódja tartalmazza az Another.Classes; - ez azt jelenti, hogy az A osztály a B osztálytól függ.
Hogy a diagramból megértsük, hol van a függő osztály és hol nem, nézzük meg a nyíl irányát: 1) a nyíl A osztályból a B osztály irányába mutat. Ez azt jelenti, hogy a B osztály függetlenebb, mint A osztály. És az A osztályban bekövetkezett változások, a B osztályban nem történik „kár”.
SZILÁRD
Az egyik fő ok, amiért ezt a könyvet elolvastam, a SOLID elvek eredeti forrásból való magyarázata volt, mivel Rob bácsi dolgozta ki ezeket az elveket, és mondhatni neki köszönhetjük, hogy ezt a nevet halljuk - SOLID.
Azok számára, akik nem ismerik, ezek az alapelvek szólnak, és azt tanácsolják, hogy az alkalmazásokat 5 szabálynak megfelelően alakítsák ki:
S - SRP (egyedüli felelősség elve)
O - OCP (nyitott-zárt elv)
L - LSP (Liskov-helyettesítési elv)
I – ISP (interfész szegregációs elv)
D – DIP (függőségi inverzió elve)
Mindezek az elvek alkalmazhatók az osztályok és objektumok szintjén, a modulok és alkatrészek szintjén, valamint a sínek (szolgáltatások) szintjén.
Ha úgy gondolja, hogy az Egységes felelősség elve azt jelenti, hogy egy osztálynak vagy modulnak csak egy dolgot kell tennie, akkor feltétlenül el kell olvasnia legalább a Solidról szóló fejezetet. Ugyanis a fent megadott definíció magának az elvnek a következménye, de nem meghatározása
A függőségi inverzióról
Külön figyelmet szeretnék fordítani a Dependency Inversion Principle magyarázatára (a SOLID D-ből). A könyv olvasása közben rájöttem, hogy ez nem csak egy elv, hanem egy olyan mechanizmus és eszköz is, amellyel megváltoztathatja függőségei irányát, és függetlenítheti például az üzleti logikát (DOMAIN) a Adathozzáférési réteg megvalósítása (DAL)
Bár maga az elv a többi SOLID-ban egy kicsit mást jelent, mint a mechanizmus, magát a mechanizmust alkalmazzák az egész könyvben, és ez az egyik fő módszer a függőségek megfordítására és irányának megváltoztatására, ami egyébként a DDD-ben használják
Az építészeti döntések meghozataláról
A könyv gyakran megemlíti a fontos építészeti döntések meghozatalának elvét: melyik adatbázist használjuk, melyik keretrendszert használjuk, melyik könyvtárat vegyük be, mit használjunk keresőként stb.
A szerző tehát úgy véli: a lehető legkevesebbet kellene meghoznia az ilyen döntéseket. Mivel a követelmények változhatnak, a teljesítmény korlátozásai is, maga a viselkedési komponens is hajlamos a változásra. A fejlesztési folyamat során az egyik megoldás kevésbé tűnik hatékonynak, mint a másik, kevésbé kényelmes, mint a másik. És az architektúrája erőssége határozza meg, hogy milyen gyorsan és fájdalommentesen cserélheti le az egyik technológiát a másikra (az OCP egyébként erről beszél).
Például hirtelen úgy dönt, hogy a Postgresql vagy általában a fájlok helyett MongoDb-t használ, vagy hamis adatokat használ, amelyekkel a műveleteket a memóriában hajtja végre. És bizonyos feltételek mellett ez arra kényszerítheti, hogy szinte az összes logikát átírja.
Az ilyen helyzetek elkerülése érdekében olyan mechanizmusokat alkalmazhatunk, amelyek a döntéshozatali időt a lehetőségekhez képest kitolják. Az egyik ilyen mechanizmus az absztrakció.
Linkek a DDD-hez
DDD – Domain Driven Design – a változásokhoz kritikus, komplex üzleti logikával rendelkező szolgáltatások fejlesztésének megközelítése, amelynek célja a projektmenedzseri pozíciók (PM-ek, értékesítési menedzserek stb.) maximalizálása a hétköznapi evezősöknél. Vagyis azért, hogy a projekt minden tagja között mindenütt jelen legyen a nyelv, és mindenki megértse a másikat, és mindenki ugyanazon üzleti szabályok mellett egy területen gondolkodjon.
Ha a DDD híve vagy, vagy az akarsz lenni, vagy nem értesz hozzá valamit, de meg akarod érteni, akkor a könyvet kötelező elolvasni, különösen a könyv második részét.
A szerző itt elmagyarázza a függőségi szabály létezését, és azt, hogy miért segít a betartása a megfelelő alkalmazásarchitektúra felépítésében. Miért kell a függőségeknek a magas szabályzatú komponensek felé irányulniuk, és miért... tartomány (A magas szintű szabályzat komponensének) infrastruktúrától függetlennek kell lennie, és hogyan egyszerűsíti ez a telepítést és a fejlesztést
Absztrakció
Rob bácsi arról is beszél, hogy a megvalósítás részletei hogyan károsíthatják a rendszert, és megakadályozhatják, hogy a jövőben fájdalommentesen fejlődjön.
Ne feledje!
Az adatbázis egy megvalósítási részlet
Ügyfelek (web, mobil stb.) – a megvalósítás részletei
A keretrendszerek megvalósítási részlet
Amennyire csak lehetséges, elvonatkoztatni kell ettől, és nem szabad attól függeni, a fent leírt függőségi inverzió segítségével interfészekkel és absztrakciókkal, függőségi szabállyal és egyéb mechanizmusokkal.
Modulok építésének módszerei
Különösen tetszett ez a rész, mint az ASP .NET CORE szolgáltatások fejlesztője. Mert itt olyan módszertanokról beszélünk, amelyek segítségével kész komponensekből egységes szolgáltatási architektúrát lehet felépíteni.
Robert 4 lehetséges rétegelválasztási sémát írt le.
Világossá tette, hogy a 3 rétegű architektúra oly gyakran használt mechanizmusa: UI (vezérlők), Services (Domain), DAL (Database) miért elég rossz a többihez képest. Nem sok projektet láttam, de mindegyik, például egy mikroszolgáltatás a hátoldalon, háromrétegű architektúrát használ.
Ezenkívül gyakran használják az egykomponensű-egy szolgáltatás architektúrát. Általánosságban elmondható, hogy mindkettő elég jó, de ennek elég sok hátránya van, ahhoz képest, hogy például DDD használatakor hogyan épül fel az architektúra, különösen a kritikus szolgáltatásoknál és a komplex szolgáltatásoknál.
Mindenesetre ez a könyvismertetés vége. Maga a könyv nagyon tetszett, nem bántam meg, hogy elolvastam, köszönöm a szerzőnek. Nektek, kedves olvasók, köszönöm a figyelmet, ne ítéljetek szigorúan - ez a kiadvány a könyv benyomásán és az én személyes lelkesedésemen alapul.
Forrás: will.com
