Egy szakmai beszélgetésen megkérdezték tőlem, melyik Angular-verziót használjuk, én pedig nem próbáltam időt nyerni, és nem is kerülgettem a választ, mert egyszerűen nem tudtam.
A kérdés után tartottunk egy rövid, de éppen elég hosszú szünetet ahhoz, hogy megértsem, mit hallott ki a másik fél a válaszomból: ha architektként ennyire otthon vagyok ebben a technológiában, hogyan felejthetek el egy ilyen alapvető adatot?
Azt mondtam, hogy nem verziószámokon dolgozom, hanem problémákat oldok meg, miközben azt nézem, melyik eszköz milyen helyzetben használható; ez ugyan igaz volt, mégis inkább védekezésnek hangzott, mint válasznak. Hazafelé aztán újra lejátszottam magamban a beszélgetést, ahogy az ember az ilyen beszélgetéseket szokta, a pontosabb válasz azonban csak jóval később állt össze.
Mit mér valójában a kérdés?
Martin Fowler a Who Needs an Architect? című esszéjében Ralph Johnsont idézi, aki szerint az architektúra a tapasztalt fejlesztők közös képe arról, mi fontos a rendszerben, vagyis egy elem nem önmagában jelentős, hanem azért, mert a csapat annak tekinti.
Ugyanez történt abban a beszélgetésben is, ahol a verziószám önmagában alig mondott volna valamit a munkám minőségéről, mégis jelképpé vált, mert könnyű rákérdezni, gyorsan ellenőrizhető, és egyetlen számmal helyettesít egy jóval nehezebb vizsgálatot: érti-e valaki a platform működését, a korlátait és a döntései következményeit?
A keretrendszer kiválasztása valóban hosszú évekre meghatározhat egy rendszert, az aktuális major verzió azonban többnyire csak pillanatfelvétel, amely fontos lehet egy migráció vagy egy támogatási probléma idején, de önmagában még nem architekturális tudás. Attól, hogy valaki fejből tudja a számot, még nem biztos, hogy felismeri a rosszul megválasztott absztrakciót, ahogy abból sem következik feltétlenül a technológiától való elszakadás, ha a verziót nem tudja azonnal felidézni.
Nem mindent ugyanúgy őrzünk meg
Ennek hétköznapi kognitív oka is van, hiszen Sparrow, Liu és Wegner Google Effects on Memory című kutatása szerint másképp emlékezünk arra az információra, amelyről tudjuk, hogy később könnyen elérhető lesz: magát az adatot kevésbé pontosan őrizzük meg, viszont jobban emlékszünk arra, hol találjuk meg.
A verziószám tipikusan ilyen adat, mert néhány másodperc alatt kiolvasható a package.json-ból, ezért az agyam nem feltétlenül tartja készenlétben, ez azonban még nem jelenti azt, hogy minden tudás kiszervezhető volna a dokumentációba.
Kahneman és Klein a Conditions for Intuitive Expertise című tanulmányban azt írja le, hogy a szakértői intuíció felismerhető mintákból épül, ezért a tapasztalt ember nem pusztán több tényt tud felidézni, hanem olyan helyzeteket ismer fel, amelyekkel korábban már találkozott, és gyorsabban észreveszi, hol lehet a döntés ára.
Ha tehát valaki arra kíváncsi, mennyire ismerem az Angulart, a verziószám helyett megkérdezheti, mikor nem vezetnék be signalalapú reaktivitást egy meglévő alkalmazásba, mit vizsgálnék meg a standalone komponensekre történő átállás előtt, vagy melyik tesztekre támaszkodnék egy zoneless alkalmazás bevezetésekor.
Ezekre nem elég egy dokumentációs oldalt megnyitni az interjú előtt, mert a válaszhoz korábbi döntések, félresikerült migrációk és működő kompromisszumok emléke, vagyis nemcsak információ, hanem a technológiával való rendszeres érintkezés is kell.
A kényelmetlen ellenérv
Mindez jól hangzik, de túl könnyű lenne itt megállni, mert bár a verziószám rossz mérőeszköz, a hiánya nem mindig véletlen.
Aki naponta dolgozik egy platformmal, követi a változásait, migrációkat tervez és a csapatával új képességekről beszél, arra rendszerint nem azért ragad rá az aktuális verzió, mert bemagolta, hanem azért, mert gyakran találkozik vele; a szám ilyenkor nem maga a tudás, hanem a rendszeres munka nyoma.
Ezért az én válaszom sem intézhető el annyival, hogy az adat bármikor kikereshető, mert a fontosabb kérdés az, miért nem találkoztam vele elégszer ahhoz, hogy megmaradjon: valóban olyan feladatokra figyeltem, amelyekhez nem kellett, a csapat megfelelő embereire támaszkodtam, vagy egyszerűen ritkábban érintettem a platformot, mint amennyire a szerepem alapján gondolták?
Az architektnek nem kell minden részletet magánál tartania, sőt Fowler egyik legerősebb állítása szerint az értéke fordítottan arányos az általa meghozott döntések számával, vagyis nem az a feladata, hogy minden kérdésben ő mondja ki az utolsó szót. A delegálás azonban csak addig működik, amíg van elég saját tapasztalata ahhoz, hogy meg tudja ítélni a mások által meghozott döntéseket.
A fűrészpor nem az asztal
Ha ma újra megkérdeznék, melyik Angular-verziót használjuk, előbb megnézném, majd valószínűleg ugyanazt mondanám, csak kevésbé sértődötten: a verziószám melléktermék.
Olyan, mint a fűrészpor az asztalosműhelyben, ahol az asztalos nem forgácsot akar előállítani, hanem asztalt, a padlón maradó nyomok mégis jelzik, hogy mostanában dolgozott. Hibás volna a munkáját a fűrészpor mennyiségéből megítélni, de a makulátlanul tiszta műhely is felvet néhány kérdést.
A beszélgetésben rajtam a fűrészport keresték, és ezzel rosszat mértek, nekem azonban nem az volt a legkellemetlenebb, hogy pontatlan volt a mérőeszköz, hanem az, hogy abban a pillanatban egy friss asztalt sem tudtam megmutatni helyette.
A helyes válasz tehát nem az, hogy a verziószám egyáltalán nem számít, hanem az, hogy nem szabad megállni a számnál: meg kell nézni, milyen döntéseket hoztam, melyeket hagytam másokra, és mitől lett könnyebben változtatható a rendszer, mert ha ezekre sincs válaszom, akkor már nem a kérdéssel van baj.
A következő részben arról, hogyan számolja fel az architekt a saját architektúráját.
Források
- Martin Fowler: Who Needs an Architect? — IEEE Software, 2003. július/augusztus
- Sparrow, Liu, Wegner: Google Effects on Memory: Cognitive Consequences of Having Information at Our Fingertips — Science, 2011
- Kahneman, Klein: Conditions for Intuitive Expertise: A Failure to Disagree — American Psychologist, 2009
- Angular dokumentáció: Signals, Standalone migráció, Zoneless