Nevezd meg és uralni fogod!

Az elv lényege az (üzleti) szoftverfejlesztésben az, hogy ha programot írunk, akkor a kódban mindent próbáljunk névvel, ill. megfelelő névvel illetni.

Ökölszabály: a kódban lévő azonosítók kövessék az üzleti terület fogalmi rendszerét. Építsünk egy mindent átható nyelvet (Ubiquitous Language), amelynek célja, hogy egy közös nyelvet beszéljünk az ügyféllel és ugyanezen fogalmakat használjuk a program kódjában is.

Mit is jelent ez a szoftverfejlesztő szemével nézve a kódban?

Van pár “alacsony szintű” szabály, amelyet érdemes követni:

  • Amikor épp egy új változót, metódust, osztályt deklarálunk, gondoljuk végig: az adott elnevezés valóban azt jelenti-e, amit a változó, metódus szándékszik kifejezni? Ha egy kódrészlet már régebben írodott, akkor is alkalmazzuk az elvet a már meglévő fogalomra.
  • Ha épp egy összetett metódust írunk, akkor a metódus törzsében kialakult külön választható logikákat emeljük ki külön metódusba. Hogyan tudunk (értelmes) nevet adni az új metódusnak (mit csinál)? Ha nem megy, valószínűleg nem volt jó ötlet a kiemelés, vagy valamit nem jól csinálunk.
  • Szervezzük ki az osztályokból az összetartozó mezőket, metódusokat, amelyek rejtett (implicit) fogalmakat takarnak:
  • Ha az osztályban sok a mező, sok a metódus, akkor valószínűleg több felelősséget is ellát az osztály. Az új osztály bevezetésével és a kiszervezéssel csökkenthető az osztály felelőssége, csökken a mérete, ezáltal növekszik az áttekinthetőség, és könnyebben unit-test-elhető a kód.
  • Ha logikailag több mező is összetartozik, és ezeknek tudunk egy összefogó nevet adni, akkor egy külön osztályba szervezzük ki őket. Pl. egy olyan programban, ahol szerződéseket nyilvántartanak, célszerű lehet a szerződések egyes adatcsoportjait összefogni, és külön osztályban tárolni. (Pl. szerződő fél adatai, szerződés hatálya stb.)

Ha egy új fogalmat vezetünk be a szoftverben, akkor célszerű az üzleti terület fogalmi rendszerét figyelembe venni. Ideális esetben már létezik ilyen fogalom, és azt használhatjuk. Van-e esetleg hasonló fogalom? A hasonló fogalom hogyan viszonyul az általunk bevezetésre kerül fogalomhoz? Lehet, hogy célszerű inkább a meglévő, hasonló fogalmat használni, és végiggondolni, hogy ez hogyan befolyásolja a szoftverünket.

Ha nem tudjuk pontosan az üzletben már meglévő fogalommal lefedni a kívánt új fogalmat, vagy tanácstalanok vagyunk, mindenképpen célszerű egyeztetni az üzleti szakértővel, és megosztani vele a gondolatainkat. A végeredmény lehet az is, hogy végül nem kerül bevezetésre az új fogalom, mert:

  • Rosszul közelítjük meg a problémát. Nem kell tovább erőltetni a dolgot.
  • Nem látjuk egyelőre tisztán az üzleti problémát, ezért tegyük is félre a problémát.

Manapság a modern fejlesztő eszközök az átnevezésekre (Rename Method, Rename Class, Rename Field stb.), ill. más egyszerűbb kódtranszformálásokra (pl. Extract Method) simán képesek. Használjuk őket!

Miért jó ez?

A sztandard válasz: segít a kód olvashatóságában, a kód karbantartásában.

Valójában a tudatos elnevezés, és a fogalmak “hajkurászása” ennél sokkal többet segít. A fogalmak kutatásának nem csupán egy tisztább, érthetőbb kód az eredménye; a fogalmak tudatos rendszerezése segít egy tiszta mentális modellt is megalkotni. A kód írásakor és a fogalmi rendszer megismerése során a hosszú távú memóriánkban kialakuló sémák lehetővé teszik, hogy otthonosan mozoghassunk a kódban és az üzleti területen egyaránt. Az újabb és újabb megismerések, felismerések magasabb szintű sémákat eredményeznek. Minél rendszerezettebbek a sémáink, annál könnyebben találunk megoldást a felmerülő problémákra, és annál könnyebben tudjuk magát a kódot is kezelni.

Közismert tény, hogy a rövid távú memória 7+-2 tételt képes rövid távon (kb. 20mp-ig) tárolni. A korlátozott rövid távú memóriánk hatékonyan felhasználható, ha képesek vagyunk tömbösíteni a tételeket (pl. egy 7 jegyű telefonszám megjegyzésekor nem a hét számjegyet külön-külön jegyezzük meg, hanem helyette három számot próbálunk memórizálni. Pl. 334-23-40). A tömbösítés egy hosszú tanulási folyamat eredményeképpen jöhet létre, amely során a saját sémáinkat, absztrakcióinkat kialakítjuk. Ha egy nagyobb kódbázison dolgozunk, és különféle részeit egyszerre szerkesztjük, elemezzük, a magasabb szintű sémáink lehetővé teszik, hogy a kód nagyobb részeit egyszerre legyünk képesek áttekinteni.

Az üzleti fogalomrendszer megértése, leképezése

Eric Evans DDD könyve a fogalmak tudatos kereséséhez egy külön részt is szentel, “Making implicit concepts explicit” – mondja. Az ingyenes, angol nyelvű kivonatban“Bring key concepts into light” c. fejezet szól erről. Nagyon jól leírja, hogy hogyan fejlődik a domain modell, ahogy egyre jobban megértjük:

[Fordítás] “A refaktorálást apró lépésekben kell végezni. Vannak olyan esetek, amikor sok apró változtatás ellenére sem lesz sokkal értékesebb a kód, míg más esetekben kevés változtatás is hatalmas különbséget eredményez, ezt áttörésnek (Breakthrough) nevezik.

A projekt kezdetén a modell durva és felszínes, amit aztán a kóddal együtt finomítunk annak alapján, ahogy egyre mélyebbé válik a tudásunk a domain-ről, és ahogy egyre jobban megértjük a benne rejlő érdekeltségeket. Új fogalmakat és absztrakciókat vezetünk be, aztán a kódot refaktoráljuk. Minden egyes finomítással a kód világosabbá válik, másfelől pedig megteremti egy igazi áttörés előfeltételeit.

Az áttörés gyakori velejárója a gondolkozásmódbeli változás, azaz annak a módja, ahogyan a modellt látjuk. Ugyancsak a forrása lehet a projekt jelentős előrehaladásának, azonban akadályt is jelenthet. [...]

Ahhoz, hogy áttörést érjünk el, a rejtett fogalmakat egyértelművé, kifejezetté kell tenni. Amikor a domain-szakértőkkel beszélünk, sok ötletet és tudást osztunk meg egymással, aminek során bizonyos fogalmak a mindent átható nyelv részévé válnak, míg mások már a kezdetekkor is figyelmen kívül maradnak. Ezek az ún. rejtett fogalmak, amelyeket csak a többi modellbeli fogalom magyarázatához használunk. A kód finomításának ezen szakaszában néhány rejtett fogalom a figyelmünk előterébe kerülhet. Amennyiben úgy vesszük észre, hogy kulcsszerepet játszanak a modellben, akkor ezen a ponton kifejezésre kell juttatnunk őket, és létre kell hoznunk a megfelelő osztályokat és kapcsolatokat számukra. Ha mindezeket megtesszük, akkor esélyünk lehet egy áttörésre.

A rejtett fogalmaknak a felszínre kell törniük. Amennyiben ezek domain fogalmak, akkor meg kell jelenniük a modellben és a kódban is. Hogyan ismerhetjük fel őket? Az egyik módja, hogy megfigyeljük a nyelvet. A modellezés és fejlesztés során használt nyelv ugyanis sok információt rejt a domain-ről. A projekt elején ez még nem feltétlenül igaz annyira, és az is lehet, hogy az információk egy részét helytelenül használjuk. Előfordulhat, hogy egyes fogalmak nem egyértelműek, esetleg teljesen rosszul értelmeztük őket. Mindez az új domain tanulási folyamatának a része. Ahogy a mindent átható nyelvet építjük, a kulcsfogalmak utat törnek maguknak. Ez az a pont, ahol a rejtett fogalmakat felderíthetjük.

A kódrészletek olykor nem teljesen tiszták. Bizonyos fennálló kapcsolatok nehezen követhetővé teszik a kódot, vagy a metódusok olyan bonyolultak, hogy szinte lehetetlen megérteni, mit csinálnak. Ez ügyetlenség a kódolás során, de egyben a megfelelő hely arra, hogy fény derüljön egy rejtett fogalomra. Talán valami hiányzik. Ha egy kulcsfogalom hiányzik a “kirakós játékból”, akkor másoknak kell helyettesíteniük a hiányzó funkcionalitást. Ennek következtében néhány objektum “elhízik” olyan működés hozzáadása miatt, amelynek nem is ott kellene lennie, és mindez a kód tisztaságának rovására megy. Keressünk rejtett fogalmat, és ha megtaláltuk, tegyük egyértelművé, azaz vezessük be a modellbe. A modell refaktorálása egyszerűbbé és rugalmasabbá teszi azt.

A tudás megszerzése (felépítése) során néha ellentmondásokhoz juthatunk. Ha valamit mond a domain szakértő, az ellentmondásba kerülhet azzal, amit mások helyesnek tartanak, azaz az egyik követelmény ütközhet egy másikkal. Az ellentmondások nem biztos, hogy valóban azok: lehetnek ugyanannak a dolognak más nézőpontjai, vagy egyszerűen csak az értelmezés pontatlanságának eredménye. Meg kell próbálnunk összhangba hozni az ellentmondásokat, aminek során fontos összefüggések kerülhetnek figyelmünk előterébe. Még ha ez nem is így fog pontosan történni, a modell tisztaságát akkor is figyelmünk előterében kell tartanunk.

Egy másik módja a fontos fogalmak előásásának a domain szakirodalmának használata. Rengeteg könyv áll rendelkezésre szinte minden lehetséges témában, amelyek hatalmas tudást közvetítenek a megfelelő domain-ről. Ezek a könyvek általában nem tartalmaznak modelleket az általuk bemutatott domain-ről. A hordozott információt fel kell tudni dolgozni, leszűrni a lényeget és finomítani azt. Mindazonáltal a könyvekben található információk hasznosak, és mély betekintést nyújtanak a domain-be.”

“Nevezd meg és uralni fogod!” – tartották a középkorban a démonűzők: ha kimondod, amitől félsz, akkor megszabadulsz tőle.

Share
This entry was posted in Módszertan and tagged , , , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Comments

Leave a Comment