Ez egy beszámoló lesz a könyv benyomásairól, valamint néhány fogalom és tudás, amelyet ennek a könyvnek köszönhetően megtanultunk.
Architektúra
Tudja-e, hogy olvasva ezt a publikációt, egyértelmű választ tud adni arra a kérdésre, hogy mi az architektúra? Mi az architektúra a programozás és tervezés kontextusában? Milyen szerepet játszik? Sok homályos dolog van ezzel a kifejezéssel kapcsolatban. Úgy tűnik, minden világos, de valahogy túl absztrakt, és pontosság nélkül. Martin úgy véli, és egyetértek vele, hogy az alkalmazásnak két összetevője van:
- A viselkedés (behavior) — a funkciók és feladatok, amelyeket a program (komponens, szolgáltatás) végrehajt.
- Az architektúra — ez a kifejezés inkább az alkalmazás megváltoztatásáról szól.
De még ha az alkalmazás nagyon jól végzi is a feladatot, amit el kell végeznie, ez egyáltalán nem jelenti azt, hogy jó architektúrával rendelkezik. Az architektúra nem az alkalmazás viselkedéséről szól. Az architektúra a változtatás könnyedségéről szól, az architektúra a telepítés könnyedségéről szól, az architektúra a fejlesztés függetlenségéről szól. Az architektúra a gyorsaságról szól, amellyel az új csapattagok megértik a dolgokat.
És arról, hogyan lehet felépíteni ezt az architektúrát, hogyan lehet megszabadulni a fejfájástól, amikor a PM-től vagy a stakeholder-től kisebb követelmények változása érkezik: erről fog mesélni a könyv.
A szerzőkről
Mielőtt bármit is mondanék erről a könyvről, szeretnék egy kicsit magamról beszélni.
Jelenleg Strong Junior Developer vagyok, aki ASP .NET CORE-ban szakterülete eljárások fejlesztésére specializálódott.
Már egy éve dolgozom egy "galériában", és úgy tűnik, fokozatosan megbirkózom a feladattal.
Ezt a könyvet már két alkalommal elolvastam, és mindenkinek ajánlom a figyelmébe:
- beágyazott rendszerek fejlesztőinek;
- frontend fejlesztőknek;
- backend fejlesztőknek;
- sőt, még DevOps-oknak is.
Összességében mindenkinek, aki bármilyen módon kapcsolatban áll a szoftverfejlesztéssel, beleértve a különféle Sales- és PM-ket (bár az is hasznos lenne tudni, miért az ügyfelek kétszer annyi időt töltenek egy feladatra), ajánlom ezt a könyvet.
Most pedig megpróbálom érvelni, miért is gondolom ezt.
Kicsit az könyv szerzőjéről (mert számomra a szerző tekintélye nagy jelentőséggel bír). Azt hiszem, meg fogja érteni, még ha ez nem is mindig helyes, de ha egy tekintélyes személy a szakterületen mond valamit – akkor sokkal nagyobb bizalmat érez az általa mondott iránt. Például, szerintem jobban hinni fog az orvos által felállított diagnózisban, mint valaki másban a tömegből (aki a tüneteket a neten keresgélte).
Robert Martin, más néven Uncle Bob (Bob bácsi) a programozás területén dolgozik, különböző rendszerekben (a webszolgáltatásoktól az embedded rendszerekig) 1970 óta. Műszaki tanácsadó és építész, különféle technikai folyóiratokban írt, maga is nagyon tapasztalt programozó, és az egyik kulcsszereplő volt a híres SOLID elveket megalkotásában (mondhatjuk, ő volt a teremtője). Ezen kívül szeretném hozzátenni, hogy ezt a könyvet a 15+ éves tapasztalattal rendelkező csapatvezetőm ajánlotta nekem.
A könyvről
Függőségek
A könyv olvasása előtt elég sok cikket olvastam ugyanazon a Habr-on, ahol előkerült egy olyan szó, mint az "függőség". Mi ez, ki kitől függ, mit jelent konkrétan a "függ" szó, és hogyan függhet egy osztály valakitől?
Ahogy olvastam a könyvet, két dolgot megértettem:
A függőség egy olyan kifejezés, amely azt jelenti, hogy egy osztály (komponens, szolgáltatás) tud másik osztályról (komponensről, szolgáltatásról), és ez a tudás kód szinten határozódik meg (most a Java, C# és C nyelvűek biztosan megértik) egy adott névtér importálásával. Más szavakkal: van egy A osztályod a Default.Classes névtérrel és egy B osztályod az Another.Classes névtérrel. Ha az A osztály kódjában ott szerepel a using Another.Classes; – akkor ez azt jelenti, hogy az A osztály függ a B osztálytól.
A diagram alapján, hogy hol található a függő osztály, és hol nem – nézze meg a nyíl irányát: 1) a nyíl az A osztályból B osztály felé mutat. Ez azt jelenti, hogy a B osztály függetlenebb, mint az A. Az A osztályban végzett módosítások semmiféle "kárt" nem okoznak a B osztálynak.
SOLID
Az egyik fő ok, ami miatt elolvastam ezt a könyvet – az SОLID elvek magyarázata az eredeti forrásból, mert Uncle Bob dolgozta ki ezeket az elveket, és mondhatjuk, hogy neki köszönhetjük ezt a nevet – SOLID.
Azok számára, akik nem tudják — ezek az elvek azt mondják és javasolják, hogy a saját alkalmazásaikat öt szabály szerint tervezze meg:
S — SRP (Egységes felelősség elve)
O — OCP (Nyitott-zárt elv)
L — LSP (Liskov-helyettesítési elv)
I — ISP (Felület szeparációs elv)
D — DIP (Függőségi inverzió elve)
Ezek az elvek alkalmazhatóak osztályok és objektumok szintjén, modulok és komponensek szintjén, valamint rétegek (szolgáltatások) szintjén.
Ha úgy gondolja, hogy az Egységes felelősség elve azt jelenti, hogy az osztálynak vagy modulnak csupán egy feladatot kell ellátnia — akkor mindenképpen el kell olvasnia a SOLID-ról szóló fejezetet. Mert az a meghatározás, ami fent van, következmény, de nem maga az elv.
A Függőségi Inverzióról
Különös figyelmet szeretnék fordítani a Függőségi Inverzió Elvének magyarázatára (ez a SOLID D-je). A könyv olvasása közben rájöttem, hogy ez nem csupán elv, hanem egy mechanizmus és eszköz, amellyel megváltoztathatja a függőségei irányát, és például a vállalati logikát (DOMAIN) függetlenné teheti az Adat-hozzáférési réteg (DAL) megvalósítási részleteitől.
Bár az elv maga, a többi SOLID elvvel együtt, nem pontosan azt jelenti, mint a mechanizmus, a mechanizmust a könyv során végig alkalmazzák, és ez az egyik fő módszer a függőségek irányának megváltoztatására, amelyet amúgy a DDD is használ.
Az architekturális döntések meghozataláról
A könyvben gyakran említést nyer a fontos architekturális döntések elve: hogy milyen adatbázist, milyen keretrendszert, milyen könyvtárat válasszon, mit használjon keresőmotorként stb.
Szóval az író úgy véli: A lehető legkevesebb ilyen típusú döntést kell hoznia. Mivel a követelmények változhatnak, a teljesítménybeli korlátok is, a viselkedési tényezők pedig hajlamosak változni. A fejlesztés során egy döntés kevésbé hatékonynak vagy kényelmesnek tűnhet, mint egy másik. Az architektúrájának ereje fogja meghatározni, hogy mennyire gyorsan és fájdalommentesen tudja egy technológiai megoldást egy másikkal helyettesíteni (erről egyébként a OCP is beszél).
Például, hirtelen úgy dönt, hogy a Postgresql helyett a MongoDb-t használ, vagy akár fájlokat, vagy egyáltalán beágyazott adatokat, amelyekkel műveleteket végez a memóriában. És bizonyos körülmények között — ez szinte az összes logikáját újraírhatja.
Annak elkerülése érdekében, hogy ilyen helyzetek merüljenek fel, olyan mechanizmusokat használhatunk, amelyek a lehető legmesszebb elhúzzák a döntéshozatali időt. Az egyik ilyen mechanizmus az absztrakció.
Hivatkozások a DDD-re
A DDD — Domain Driven Design — egy olyan megközelítés a komplex üzleti logikát igénylő szolgáltatások fejlesztésére, amely a projekt irányító személyzetének (projektmenedzserek, értékesítési menedzserek stb.) maximális megértésére összpontosít, és a 'hétköznapi' munkatársakra. Azaz, hogy a projekt minden tagja számára egyértelmű nyelvezet alakuljon ki, és mindenki megérthesse a másikat, hogy mindenki egy domainben gondolkodjon, azonos üzleti szabályokkal.
Ha Ön DDD támogatja, vagy szeretne az lenni, esetleg nem érti teljesen, de érteni szeretné — a könyv kötelező olvasmány, különösen a könyv második része.
Itt a szerző a Dependency Rule létezéséről beszél, és arról, hogy miért fogja a helyes architektúra megépítéséhez vezetni az, ha követi ezt. Miért kell a függőségeknek a magas politikai komponensek irányába haladniuk, és miért. domain (Magas politikai komponens) függetlennek kell lennie az infrastruktúrától, és ez hogyan egyszerűsíti a telepítést és a fejlesztést.
Absztrakció
Robert arról is beszél, hogy a megvalósítás részletei hogyan árthatnak a rendszerének, és hogyan akadályozhatják meg a fájdalommentes evolúciót a jövőben.
Ne feledje!
Az adatbázis a megvalósítás részlete.
A kliensek (Web, Mobil stb.) a megvalósítás részletei.
A keretrendszerek a megvalósítás részletei.
Ezektől a dolgoktól maximálisan el kell absztrahálódnia, és nem függni tőlük, a fent leírt Dependency Inversion használatával interfészek és absztrakciók, a Dependency Rule és más mechanizmusok segítségével.
A modulok felépítési módszerei.
Ez a rész különösen tetszett, mint ASP .NET CORE szolgáltatásfejlesztő. Mert itt a kész komponensekből álló egyedi szolgáltatás architektúra kiépítésének módszertanáról van szó.
Robert négy lehetséges rétegszeparációs sémát írt le.
Rámutatott arra, hogy miért rosszabb a háromrétegű architektúra, amelyet olyan gyakran használnak: UI (vezérlők), Szolgáltatások (Domain), DAL (Adatbázis) a többihez képest. Nem láttam túl sok projektet, de mindegyik, például a mikro-szolgáltatás, a backendben éppen ezt a háromrétegű architektúrát használja.
Az egykomponens-egy szolgáltatás architektúráját is gyakran alkalmazzák. Összességében mindkettő megfelelő, de sok hátrányuk van, például a DDD használatakor kialakított architektúrához képest, különösen azokra a kritikus változásokat kívánó és összetett szolgáltatásokra nézve.
Nos, ennek a könyvnek a bemutatója ezzel véget ért. Magát a könyvet nagyon élveztem, nem bánom meg, hogy elolvastam, köszönet a szerzőnek. Kedves olvasók, köszönöm a figyelmet, ne ítéljétek meg szigorúan — ez a publikáció a könyvről szerzett benyomásomon és a személyes lelkesedésemen alapul.
Forrás: habr.com
