Már ezer éve kódolok és pár éve architectkedek is, de mindig van amit lehet tanulni. Most éppen a Clean Architecture című könyvet olvastam el Uncle Bob-tól egy hosszabb repülőút során. Pár dolgot lejegyzeteltem magamnak egy fecnire, de ezeket inkább bedobom ide, hátha ez időállóbb.
Az első pár oldalon próbálja definiálni az architektúrát, aztán végigmegy a programozási paradigmákon (SP, FP, OOP) ami egyébként érdekes annak akinek ez új és levonja a tanulságot hogy az OO egyetlen előnye a polimorfizmus. Ezután végigmegy a SOLID elveken (ebben a könyvben van azt hiszem benne a története, hogy miért lett SOLID) és átülteti ezt az egészet modul szintre, aminek nem sok értelmét látom mert nehéz ezeket az új rövidítéseket megjegyezni. Nem is fogom.
A 104.-110. oldaltól terjedő rész jó téma. Vannak kollégák akik állandóan szétmodularizálnának, szétcincálnának külön modulokba mindent rögtön az elején. Mindig az volt az érzésem hogy ez fölösleges, túl sokat kell foglalkozni az instabil projektek életciklusával és ez a fejezet megerősít engem ebben.
Jön a szokásos téma, hogy a stabilabb és absztraktabb komponenseken kell függeniük az instabilabb és konkrétabb komponenseknek (vannak azért kivételek) aztán erről még grafikonokat is rajzol ami már elég őrült. Egy későbbi fejezetben előjön, hogy melyik a leginstabilabb és legkonkrétabb rész a kódban. Na melyik? Hát a belépési pont, a “main”. Tehát az oké, hogy az gusztustalanul függ mindentől. De azért nem kell túlzásba esni. Tetszik az a megközelítés -ismét egy későbbi fejezetből- hogy a main-be akár olyan lehetőséget is érdemes lehet betenni, ami a szoftvert valamilyen teszt üzemmódban indítja el.
A 140. oldalon elhangzik az érv amit a menedzserek utálnak, hogy az opciókat nyitva kell hagyni, a döntéseket késleltetni kell amíg lehet. Néha egyébként a döntések mögött csak hatalmi háttér vagy tekintélyelvűség van.
A 157. oldal tetején explicite kimondja, hogy a service-ek szétválasztása drága, fejlesztői időt és hardver erőforrásokat tekintve is. Mikroszervíz fanok, ehhez mit szóltok? De azért hoz pár dolgot hogy mi mentén érdemes szétvágni a szoftvert. Az nekem érdekes hogy a jar fájlot függetlenül telepíthető komponesnek veszi. Ez nyilván lehetséges bizonyos környezetben (OSGi?), de nem szoktuk. Mondjuk élném ha szoknánk.
Egyébként folyamatosan hoz példákat “Bob” régi projektjeiből. Viszont azt vettem észre, hogy engem már kicsit fáraszt ez könyben is és élőben is, amikor egy kolléga elkezdi, hogy “az előző cégemnél” és akkor lenyom egy sztorit és rövid beszélgetés után kiderül hogy a mostani helyzetben miért nem releváns.
A könyv egyik legértékesebb gondolata, ami elég sokszor visszaköszön, az a szintek (level-ek) azaz hogy az implementáció közeli részeket nevezzük alacsonyabb szintűeknek, a domain-hez közeli részeket pedig magasabb szintűeknek. Az alacsonyabb szintű részek függhetnek a magasabb szintűektől, de fordítva nem. Ez az ún. “Dependency rule”. Tehát a domain modellnek tisztának kell lennie, ne legyenek bepiszkolva (JPA) annotációkkal, stb. Ne adogassunk át felsőbb szintekre alsóbb szintű objektumokat, pl Hibernate entitásokat, hanem inkább másoljuk át új DTO-ba az adatokat. Na adjuk át implementáció specifikus paramétereket modulhatárokon. Ez a “Clean Architecture” vagy “Onion Architecture” vagy “Ports and Adapters” amit nem Bob talált ki, hanem Alistar Cockburn. Steve Freeman és Nat Pryce Growing írta ezt le a Object Oriented Software with Tests című könyvben. Bakancslista.
Későbbi fejezetben még leírja, hogy a DB, a Web, a mindenféle framework csak alacsonyabb szintű részlet, ne erről szóljon a kód meg a projekt. Ha ránéz valaki a kódra, ne azt lássa hogy ez egy X framework projekt, hanem hogy ez egy webshop, például. Akármilyen lelkesek is vagyunk egy framework iránt, ne arra építsük fel a mindent. Tartsuk meg lecserélhetőnek. Legyen ott a gondolat, hogy mi lenne ha egy év múlva már nem használhatnánk ezt a frameworköt. Újra kéne írni az egész kódot? Mert az gáz.
A fentiekkel lazán kapcsolatos a “humble object pattern” (humble = szerény). Amikor van egy nehezen tesztelhető vagy más szempontból kritikus aspektusa a kódnak, pl. GUI, akkor úgy kell szétválasztani a kódot, hogy a “humble object”-be minél kevesebb dolog kerüljön, de azok a dolgok kerüljenek oda amik nehezen tesztelhetőek, kritikusak. Tehát a GUI-val foglalkozó osztály pl legyen buta, szerény, ne pakoljunk bele üzleti logikát, ha már tesztelni nem tudjuk rendesen. Egyébként REST APIs alkalmazásoknál az endppoint-ok is humble object-ek lehetnek.
A “partial boundaries” is egy jó téma amit én is előszeretettel használok. Ez arról szól, hogy -habár nem vágjuk szét a kódot függetlenül telepíthető részekre- de mégiscsak ezzel a mindset-tel írjuk a kódot. Így egyébként tisztább, tesztelhetőbb a kód és ha szükség van rá, valóban lehetséges a vágás.
A 240. oldalnál kezdődő, szerviz-orientáltsággal foglalkozó fejezetben azért van valami amivel nem értek egyet, mert más könyvben mást olvastam és azzal az érveléssel jobban egyetértettem. (Az az Eric Evans DDD könyve volt.) Ismét a szervíz-ekre bontások ellen ágál mindenféle érvvel, de figyelmen kívül hagyja a DDD-t. Különböző bounded context-eket továbbra is abszolút érdemes különböző szervizekben implementálni.
Külön fejezet van a hardver közeli kódolásra, hogy ott is érdemes követni a “clean architecture” elveket. Ezt nagyon adom. A regiszter és I/O mókolás elveszi az ember figyelmét. Van is egy olyan hobbiprojektem a polcon ami emiatt áll, hogy elment a kód az erdőbe (nem én voltam, más besegített!) és már nem értem, nem merek hozzányúlni. A könyv vége felé még Simon Brown nyom be egy fejezetet, amiben az Onion Architectúrát fejtegeti tovább. Hogy van ez a dolog az interfészekkel, package-ekkel és osztályokkal.
Aztán pedig Robert C Martin végigveszi a főbb projekjeit a karrierje elejéről. Ez érdekes olvasmány, bár nem túl sokat ad szakmai szempontból. Nagyok voltak a vinyók, szétvágták a falat ha tönkrementek, oké. Viszont leírja hogy hogyan lett ő “Uncle Bob” és ami nekem wow-momentet okozott, hogy dolgozott a Rational Rose-on. Ezt én is használtam jó régen.
Szóval jó könyv, jó olvasmány, ajánlom mindenkinek de főleg aki tapasztalt szoftverfejlesztőnek tartja magát és az architect-kedés felé kacsintgat.
