Adam Nemeth’s Blog

Kértétek, itt van. Alapvetően itt a modultervezésről lesz szó, a komplett rendszerek tervezése egyrészről picit más tészta, másrészt ebből a szempontból meglepően sokszor van megkötve a kezünk. Érdemes elolvasni a cikket is, de a kapcsolódó két esettanulmány a legértékesebb talán.

Ha a specifikáció megvan, hányszor adjuk oda tetszőleges, az implementációs környezetet valamelyest ismerő kollegának azt, már implementált (és titokban: tesztelt) terméket várva vissza cserébe? Mi sem természetesebb ennél, nem igaz? Az alkotói szabadság, a modulok amúgyis függetlenek, a srác amúgyis megbántódna, ha beleszólnának a dolgába… ugye?

Hát egy lúf.szt.

Alapvetően a kód azon részei, amit senki nem menedzsel (nem látja senki a készítőjén kívül), fekete dobozok. A fekete doboz pedig nem elhanyagolható valószinűséggel lehet rossz, hibás. Azt, hogy megvalósítja-e egyáltalán a specifkációt, csak akkor tudjuk, ha ténylegesen leteszteltük (amit általában szintén a programozóra bízunk..). A specifikáció gyakorlatilag mindig interfészspecifikáció: azt mondja meg, adott interfésze(ke)n keresztül milyennek tűnjön a program. Lehet ez UI, lehet ez adatbázis, de lehet épp másik programrész.

A tervezés elsődleges feladata, hogy részekre válassza a megoldandó feladatot, a részek közti összefüggéseket (interfészeket) pedig rögzítse. Tehát eme fázis nem más, mint részekre bontás, és részspecifikálás.

Ezért van, hogy a legtöbb kezdő programozótól egy masszát kapunk vissza, ahol a felelősségeket hibásan veszik széjjel, ha egyáltalán. Hiába az MVC, template-jeik általában tartalmaznak logikát, controllereik az adatbázisokat szinte közvetlenül kezelik, az absztrakciók rendszerint gyengék (hányszor láttam natív SQL hívásokat kezdő programozóktól ORM modellek függvényeiként…)

Minél több komponens menedzselt (nem .net értelemben), annál kevesebb a hibalehetőség, annál kisebb része van potenciálisan elrontva a kódnak, igaz, exponenciálisan nő a tesztesetek száma is.

Mégvalamit vesz el a tervezés: a felfedezés örömét. Bár én már megtanultam örömemet lelni a mérnöki hozzáállásban, az UML-ábrák és tervezési, szervezési folyamatok közt érzem jól magam, nem pedig a kódolásban, ez azonban egyfajta egyensúlytalanságot is erdményez: a nagy szívások a kód elírásaiban, az alsóbb rétegek félreértésében vannak. (Persze kiveszem a részem a debuggolásban, de mégis más nézőpont.) Dijsktra viszont ezzel magyarázza gyakran tökéletes hiányát, hogy az örömöt veszi el a programozásból (na, nem neki).

Az általános tervezési folyamat

A tervezés mindig az adott rendszertől függ: a frameworkök jó keretet nyújtanak, de nem ebből kell kiindulni, elvégre nem a frameworköt modellezed, hanem a valós folyamatot. Persze, ha a valós folyamatod jól leképezhető ezekre (végülis a Rational Analysis Classes se véletlenül jött létre), akkor hajrá: ettől még igyekezz a két világban - az ügyfélében és a platforméban - párhuzamosan járni.

(Ehhez persze érteni kell, az ügyfél mit akar és miért.)

A tervezési folyamatod a csapatodtól és a rendszeredtől is függ: jó, ha 1-2 projektet azonos csapattal tudsz csinálni, így nem kell minden alkalommal az új körülményekkel együtt új embereket is megismerni, így felhasználható a tapasztalat.

Egy picit ez olyan, mint a javascript-fordítók: általánosítani csak az ismétlődések felismerésének árán lehet. Persze ezt a tapasztalatot megszerezheted sok projekten keresztül is, de ezeknek adott területre kell fókuszálniuk (és épp ezért nem vállalok pl. beágyazott rendszereket).

A SOLID szabályok közül (ha a SOLID kifejezés, így, nagybetűkkel nem ismerős, akkor azonnal kattints ide) én leginkább a felelősség-problémát tartom irányadónak, megoldja a decoupling jó részét: legtöbb problémád ugyanis a különböző rejtett függőségekből és feltételezésekből lesz. Ha egy osztály pontosan egy feladatot lát el, azt viszont jól, kevesebb az esélyed arra, hogy spagettiként tapadjanak össze a moduljaid (mégha a kód kinézete nem is spagetti, a tapadásuk jól hasonlít rá.)

(Persze, a többi szabály jól jön ha nagy rendszereket tervezel, meg iszonyatos modularitasra van szükség, bár a megvalósítás módjáról vitáznék sokszor.)

És akkor itt most álljunk meg egy pillanatra.

Ha arra kérnélek, rajzold le azt a munkafolyamatot, amit naponta csinálsz, le tudnád?

Ha arra kérnélek sorold fel a tipikusan ismétlődő dolgokat, fel tudnád?

Az informatika dolga kettős:

• az egyik a folyamatok felismerése, és azok formalizálása.
  Ha a napodnak ritmusa van, sok az egymást követő robotikus taszk egy projekten, pláne programozó vagy szoftvermérnök vagy, akkor valamit elrontasz. A robotikus taszkokra a számítógépek valók, meg a buta programozók. Szinte mindig létezik kiút, a generátorok, a windows makrók végső megoldásként mindig ott vannak.
• A másik az ismétlődések kiváltása: általánosítással, ciklusokkal, újraszervezéssel, DE: semmiképp sem kopipasztával.

A legtöbb programozó, akivel eddig beszéltem, vagy dolgoztam, külső kényszerítő erő híján a specifikáción túl nem tervezett semmit: ha igen, az is leginkább adatbázis modell volt, meg levadászott a netről az adott feladat megoldására jónak tűnő csomagokat. Nem értek vele egyet. Ennek több oka van, részint az adatstruktúrák érzékenysége a rosszul definiált folyamatokra, részint az az egyszerű meglátás, hogy itt egy valós világot feleltetünk meg egy virtuálisnak, ez pedig nem írható le pusztán taxonómiai ( ~hierarchikus) alapon. A tervezés ennél több.

Annak eldöntése, hogy az informatika, mint mérnökszakma, megállja-e a helyét, nem pusztán az én tisztem. Szerintem igen, naponta eszerint a paradigma szerint dolgozom, ezt veszem alapul. Viszont azt is gondolom, ha valaki úgy gondolja, igen, az, akkor úgy is kell hozzáállnia munkájához, hogy ez megfeleljen ennek.

Tervezés MVC (desktop és web) rendszerekben

Általában az MVC-sorrend az UI tervekkel indul, mert ez az,amit az ügyfélnek meg lehet mutatni, illetve ez alapján lehet tőle kérdezni dolgokat. Ezekről majd lesz szó egy másik cikkben.

Valamelyest párhuzamosan készülhetnek a folyamattervek (algoritmustervek), amik az egyes akciókat írják le. Félreértés ne essék: a klasszikus információs rendszerek világában az akciók elég vékonykák.

Én csak ezek után szoktam adattervezéssel foglalkozni, a legvégén. Ennek két oka van, adattervezni egyrészt mindenki tud, gyakorlatilag ez az egyetlen tervábra amit viszontlátok a legtöbb kezdőtől, másrészt viszont ha rossz gondolatmeneted van a UI-ban, vagy a folyamatokban, sokkal könnyebben javítható, mint ha elnéztél egy use case-t és elrontottad az egész adatbázis-sémádat.

Case study: A prototípus-alapú tervezés

Az egyik projektben két dolog állt rendelkezésünkre: a grafikus felületek prototípusai (mock-upok), és néhány user story. Ezeket az ügyfél adta, az ő emberei készítették, ezért módosításuk nehézkes volt. Mint az én esetemben szinte mindig, weboldalról volt szó, az adatok egy része egy - szintén általunk fejlesztett - webservice szolgáltatásból, más része adatbázisból jött, és HTML-CSS-JS felületen kötött ki a végén, természetesen.

A prototípusok widgeteket írtak le, tehát egységes blokkokat, nem feltétlenül teljes oldalakat.

Elég sok fejlesztői szerepet készítettem, jóval többet, mint ahány fejlesztő adott volt rá, ezekre emlékszem:

• Volt a layout engineer (én), ez a prototípus képek alapján meghatározta az osztályneveket, az interakciós pontokat, a felépítés alapjait, ezeket bejelölte a prototípuson
• A template engineer ennek megfelelően készített egy HTML template-et, amely fals adatokkal is tudott dolgozni, viszont csak felépítményt tartalmazott
• A CSS engineer készítette el a megfelelő CSS-eket a már meglévő sablonhoz a jelölt prototípus alapján, viszont nem nyúlt bele az interakciókba. Az ő problémája volt jórészt az IE (amely az oldal más részei miatt eleve quirks-módba került sajnos)
• A JS engineer az AJAX - és mozgásinterakciókért volt felelős az interakciós pontok alapján
• A service engineer a megfelelő webszolgáltatásokat készítette elő
• A PHP engineer pedig az MVC-modellben a puszta PHP-t készítette el, adott GET/POST bemenetekre template-es vagy épp JSON-választ adva, a modellrétegekben megfelelően modellezett szolgáltatásokat használva.

Prototípus alapú tervezés, légbőlkapott, gyors ábra, bár már itt is látszik, az adatstruktúra nem lesz jó

A szép az volt, hogy ezzel 2-3 embernek rögtön lehetett adni szöszmötölnivalót, mihelyst rászántam azt a 2-3 órát, amely minimálisan szükséges volt rá, hogy ezeket a feladatokat megfelelően függetlenre elkészítsem.

A dolog egyik titka a scaffolding: először mindenkitől egy körülbelüli változatot kértem, amelyet a másiknak oda tud már adni, fals adatokkal: Egy konstansokkal kitöltött XML-t, egy megfelelő struktúrájú HTML-t, aztán következő körbe egy jól rendezett CSS-t, üres válaszokat visszaadó PHP-ket.

Ez főként akkor lehet működőképes, ha teli vagy kevéssé tapasztalt, vagy épp nagyon specializált fejlesztőkkel, esetleg egyetemistákkal, viszont abból tényleg van 2-3.

(BTW: az összes agilis módszertan - eXtreme Programming, SCRUM - feltételezi, hogy rendkívül tapasztalt emberekkel dolgozol, akik már évek óta az adott szakterületen vannak. Manapság, mikor minden projekt “agilis”, mégis honnan szednék össze ezt a tudást a fiatalok?)

Case Study: Tervezés webes fogalmakkal

Másik nagy kedvencünk a Typo3 rendszer volt. Ma már kissé idejétmúlt a legtöbb rendszerlib benne - főként CSS szempontjából - de tartalomkezelői tervezéshez nagy alapot nyújtott.

Az ilyen modellek alapja az oldal és a tartalomelem, vagy blokk. Az asszociáció megfelel a linkeknek, a rekordokat (=adatbázis-elemeket) pedig - typo3-as fogalmakkal - szintén oldalakhoz tudjuk rendelni. A leszármaztatás sajátos viszonyok miatt a sablonok master-jellegét tudta jól ábrázolni.

Az alábbi ábrán összegyűjtöttem néhány jelölést, bár így ezek együtt nem szoktak szerepelni. Két sztereotípiánk van, a jól felismerhető oldalon kívül (PI = speciális blokk, a Plug-In rövidítése, a szürkék pedig a rekordok)

Webes tervezés typo3-mal: típusok és kapcsolataik

(Megkérdezheti valaki, hogy lehet megkülönböztetni az oldalt az UML note-októl: nos, az eredeti jelölésrendszer pre-UML, másfajta nyilai is voltak, így ez nem okozott akkor fejtörést, de figyeljük meg: a note-ok általában landscape, az oldalak pedig mindig portrait ábrázolást kapnak. Opcionálisan: máshova a szamárfület!)

Nyilván ez egy elég rendszerközeli modell volt, a Typo3 látványosan ábrázolta az oldalstruktúráinkat, mégha nem is mindig tökéletesen (a hierarchia volt pl. az egyetlen kapcsolatmodell, amit szépen kezelt, mi tudtunk ábrázolni mást is.), IDE-ként pedig jól kezelte a pluginblokkokat. Éveken át küzdöttünk viszont a hírek és hírkategóriák kezelésével, amely áthatotta az egész aktuális rendszert, így valójában a rendszer modellje nem illeszkedett jól az ügyfél igényeihez.

Typo3 adminfelület: én szerettem, az ügyfelek viszont néha hisztit kaptak tőle (forrás: www.gcnpublishing.com)

A blokk és oldalak viszonya mai napig jól jön tartalommodellezésben, és más keretrendszerekben is jól alkalmazható, mégha máshogy is hívják.