Adam Nemeth's Blog

Architect dolgok - A tervezési fázis folyamata

Aadaam — Sat, 26 Dec 2009 21:52:58 +0000

3700

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.

13cf

Boldog Karácsonyt

Aadaam — Thu, 24 Dec 2009 15:34:09 +0000

Avagy, lusta vagyok leveleket írni

A kedvenc karácsonyi dallamom a Carol of The Bells, másnéven Ukrainan Carol, abbol is Ray Conniff 1962-es feldolgozása:

Ugyanis olyasmit mond el, amit kevés karácsonyi dalban látok viszont.

Ez nem a meleg szobák éneke: ez a vidéké, a hideg télé, a bizonytalanságé, a félve kimondott reményé, a csakazértis Jézusé, amikor már csak kapaszkodóként is ezt énekled, mert bár Tudod, de bizonyos sose lehetsz benne teljes valójában földi léted során, mégha naponta tapasztalod is.

Ez az értékrendeddel ellentétes világban énekelt dallam, aminek része vagy, de mégse úgy jó itt amit jónak hívnak, ahogy szeretnéd, hogy jó legyen, a huszonegyedik századi mindennapok tapasztalata - és a huszadik századi Ukrajnáé is minden bizonnyal. De mégis, bár picit félve, kiállsz, és Jézusért kiáltasz.

Az eredetileg kora tavaszi szerencsekívánó versikét már abban az időben írta át Leontovics kórusművé, amikor Ukrajnában az újévet nem tavasszal, hanem január közepén ünnepelték, megmagyarázva ezzel az eredeti szöveg- és dallamvilág különbözőségét. Keresztény kontextusra és angol szövegre csak a 30-as években ültette át Peter Wilhousky.

Ezt a hangulatot adja vissza olyan jól a Connif-feldolgozás.

Az ukrán eredetit meg lehet hallgatni itt (Oleg Bulaschenko professzor oldaláról).

Ebben a playlistben pedig 3 kiváló feldolgozás szerepel egymás alatt, köztük egy cseh amatőr kvintett zseniális videója.

Mindenkinek Boldog Karácsonyt és - bár addig tervek szerint jelentkezünk - sikeres új évet!

Architect dolgok - Use case-ek 2.: mindless cloning

Aadaam — Sat, 12 Dec 2009 14:30:02 +0000

1970

Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.

Az adatstruktúrákkal ne foglalkozz. Nyilván pillanatok alatt le fog jönni az

űrlapokból,
adatlapokból és
táblázatokból

úgyis, hogy milyen adatokra lesz szükséged.

Emlékezz: a modellek három dolgot ábrázolnak:

elemeket,
viszonyokat,
és kölcsönhatásokat.

Ezek közül az elemek felismerése a legkönnyebb, viszont épp ezért a legkevésbé hangsúlyos.

De mik a kölcsönhatások? Azaz: mik lehettek a fő use case-ek? Erre kell rájönnöd első körben.

Ebben segíthet a rendszer igéinek kigyűjtése (gombok, menük feliratai), de én mégis azt mondom, inkább a

méretekkel és az
ismétlődések gyakoriságával
(az elhelyezkedéssel)

foglalkozz. Nyilván az a legfontosabb, ami a főoldalról (vagy a leggyakoribb képernyőfajtákon) elérhető, nagy, és középen van.

A végeredménynek olyannak kell lennie, mintha a másik végéről fogtad volna meg a requirement analízist. Tehát pontosan olyannak amiről az előző requirement postban szó volt.

Ez azért van így, mert az az a formátum, amivel lehet dolgozni. Természetesen az ügyfél, pláne, ha informatikai végzettséggel rendelkezik, ezt el fogja bagatellizálni, de ne higgy neki! Ha kell, részletekben, és folyamatában, részről-részre csináld, de akkor a legfontosabbakat vedd előre, és győződj meg róla, az a legfontosabb, építésbe ne kezdj requirementek nélkül!

A viszonyokra sokkal nehezebb lesz rájönnöd, persze, ehhez már szükséged lesz az adatstruktúrákra is, de sokszor sajnos rejtve maradnak, illetve csak a fejlesztés egy későbbi szakaszában jössz rá.

Mi a baj a klónokkal?

A probléma a klónprojektekkel, hogy a legtöbb megrendelő nem túl segítőkész ilyenkor: minek kérdezel, ott az eredeti (aztán persze konkrétan rámutatva egy-egy adott részre kiderül, mégsem.).

Megmondom az őszintét: a legtöbb klónprojektem bebukott, mert nem vagyok jó klónozó, és félreértésekkel volt teli a dolog. Ezért minden tapsot megérdemelnek azok, akiknek ez sikerül (a programozók, nem a kitalálók! Azok így néha megússzák házifeladatukat…)

Látszatra pl. a belső használatú szoftvereknél néha tényleg olcsóbb saját fejlesztéseket készíteni, mint megvenni a konkrét terméket, de ez sokszor csak látszat: hosszabb távon kijön, a szoftverházak által tömegével árusított szoftverek jelentősen olcsóbbak, jobbak.

A belső klónprojekteket elég nagy számban váltja le előbb-utóbb maga a klónozott szoftver vagy versenytársa, akkor is, ha a projekt amúgy sikeres volt, (több, mint) dupla árat fizetve a funkcionalitásért. Ehhez persze az kell, hogy az eredeti termék jól adaptálható legyen (de erre a jobbak figyelnek.)

(Meg persze a klónozás gyakran eltereli a figyelmet az aktuális szituációról, környezetről, de ez ismét megrendelői kritika lenne.)

De ha ugyanolyan, az nem is jó?

Ötleteket lopni nem szégyen. Volt, hogy egy interfész-tervem egy-az-egyben hasonlított egy már meglévő, asztali szoftverre. Ennek két oka lehet pozitív esetben:

Úgy a jó! Ha neked is az jön ki, hogy az ideális az adott helyzetben is az, amit láttál (pl. egy ikon elhelyezkedése, mérete, szimbólumkészlete), akkor egyszerűen úgy jó és kész.
A baj az, hogy a végiggondolást a már meglévő minta sokszor akadályozza, nota bene, ezzel izzadós munkát spórolnak a concept-emberek, és néha áldásnak, nem pedig akadálynak tekintik.
Így szokta meg a célközönség: általában a honlapokon a keresők a jobb felső sarokban vannak. Ez nem az egyetlen lehetséges helyük (és tudom, a honlap jelenlegi reinkarnációban nem is ott van nálam), viszont itt szokták meg az emberek.
Így alakult ki a jelenlegi, néha leválthatatlannak tűnő asztal-ablak metaforarendszerünk is.

Végül egy jótanács azoknak, akik mégis enélkül a lépés nélkül vágnának bele:

Előbb-utóbb kialakul benned a specifikáció, de ez leginkább olyan, mint vakegér a labirintusban: ahelyett, hogy GPS-szerűen megmondanák, mikor merre kell fordulni, ehelyett folyamatosan mész valamerre, falakba ütközve pedig visszafordulsz. Az meg, hogy van egy kész szoftver, amit másolsz, legfeljebb abban segít, hogy nem ködből vannak a labirintus falai.

1df6

Merre tovább?

Aadaam — Sat, 05 Dec 2009 15:32:34 +0000

Az architect dolgok sorozatra több megoldásom is lett volna a héten, de sajnos időközben ideiglenesen lekorlátozódtak az energiáim.

Szeretnék azonban némi interakciót is, nem kell komment, kéne egyet szavazni. Remélem, jövő héten már jobban leszek, és akkor tudok tartalmat is mögérakni…

Témajavaslatok:

Architect dolgok - mindless cloning, avagy, hogyan kell mérnöki módon kezelni azt, ha a specifikáció annyi “ugyanilyet szeretnék mint ez?”
Architect dolgok - Közösségi webalkalmazás építése PHP alapokon, szépen - van elfekvőben egy jó minőségű kis symfonys kódom, közösségi (twitter,facebook, iwiw) appnak, nem túl sok, de sokmindent be lehet rajta mutatni, és senki felé nem licencköteles
Architect dolgok - tervezési folyamatok - tovább folytatva az általános részt, rendszertervezési gyakorlat
Egyéb - akkor kommentelj

A tarsolyban van még egy félkész játék JS-ben, opensocial okosságok, webes modultervezés (ami nem azonos a rendszertervvel), de ezek azok, amik előránthatóak könnyedén.

Nos, mit gondoltok?

(Alant egy poll-r szavazás, ha nem jelenne meg rss-ben)

Eddig megjelent architect cikkek:

A hiba az Ön (de nem mindenki) Google Readerében van (ha spamet látsz, klikk)

Aadaam — Sun, 29 Nov 2009 13:58:50 +0000

Sziasztok,

Sorozatunkat megszakítva, mert már annyian cseszegettek miatta:
1) A szájt fájlrendszere érintetlen
2) A szájt adatbázisához most nem tudok hozzáférni (Márk, hogy lehet?), de az is érintetlennek tűnik
3) Ha a feedURL-t betöltöd egy böngészőbe, helyes
4) Ha nem google readert használsz, helyes
5) A google readeres ismerőseim átlag felénél jó a szájt, másik felénél spam van.

Szóval nem tudom, mi a baja. Alternatív RSS-nek itt van Gazs feedje (kösz, Gazs!), illetve egy Yahoo Pipes feed, ezek mennek a birodalmi readerrel is.

Persze, frissítenem kéne wordpress-t, ez nem feltétlen pusztán lustaság okán nem történik meg…

Architect dolgok - modellezés a gyakorlatban

Aadaam — Sat, 28 Nov 2009 13:05:35 +0000

33c2

Ez már majdnem kód… bocsi, kitaláltam valamit, kell a gondolatmenet felépítéséhez ennek az ismerete… Meg aztán remélem, haszonnal forgatjátok, megismerkedtek egy olyan eszközzel, amiről eddig sokszor csak előítéleteket hallottatok…

A modellek sokszor folyamatokat írnak le, nem struktúrákat (Beiratkozás az egyetemen, forrás: Agilemodeling.com)

Az előző postban elejtettem, hogy “a diagramjaim rendszerint rövidtávra készülnek”. Ez egy nagyon fontos mondat, szeretnék rajt elidőzni.

A modellezésről a legtöbb embernek a Model-Driven Development jut eszébe, ami egy szép elméleti elképzelés, a gyakorlatban viszont nehéz kivitelezni, bár vannak működő rendszerek, főleg bankoknál.

Pedig a modellezés fontos része a programozásnak, enélkül nem lehet átlátni a szoftvereket, nemhogy minőségi programot írni.

A modellezés definíciója

Két definícióm van. Az egyik, amit az egyetemen tanultunk:

A modell a világ adott szempontú nézete, amely a szempont szerint lényeges dolgokat kiemeli, a lényegteleneket elrejti.

A másik a sajátom:

A modell a [rendszer] dolg[aina]k [tulajdonságai és] összefüggései [és összefüggéseinek tulajdonságai] [adott szempontok szerint] [ábrázolva]

([] - opcionális)

Tévhitek a modellezésről

Nem igaz, hogy az egész rendszert modellezni kell.
Általában csak egy kis, de fontos / bonyolult / más módon megbeszélést igénylő részét szoktuk
Nem igaz, hogy minden modellt folyamatosan frissiteni kell.
Alapvetően háromféle modell van:
- Az egyszerhasználatos, ezt teljesen logikus okokból nem frissítjük nagyon.
- Az architekturális, vagy egyéb nagy, szükséges és fontos modell, amik ritkán változnak, akkor viszont napra készen kell őket tartani. Végül pedig:
- A rendszer részét képező modell, azaz, amikor az adott modell adatfájlját beolvassa a program, és aszerint működik (akár konvertáláson keresztül) Ez pedig definició szerint friss.
A modell nem feltétlenül létezik ábrázolva
ha az a modelled a Mariskáról, hogy nagyok a csöcsei, formás a popsija, és jól tud ezekkel végigvonulni az irodán (elnézést a hölgyektől), világos, hogy ebből a szempontból lényegtelen, hogy tök jól tud németül, ugyanakkor az is, hogy ez a mentális kép inkább a fejedben, semmint ábrázolva jelenik meg.
A modell nem feltétlenül diagram

Sőt, az UML-nek is vannak olyan részei, amik szöveges leírásként fogalmazzák meg a problémát! De a modell lehet adatfájl is (doc, txt, 3ds, de a kedvencem: YAML) - Sokféle módon lehet ábrázolni egy rendszer összefüggéseit, lényeges tulajdonságait
A modell nem feltétlenül UML nyelvű

Bár az UML készlete bőséges, és helyenként jó is (máshol szódával elmegy persze), bármikor előfordulhat olyan probléma, ahol nem áll kézre épp, vagy egy más rendszer jobban megfelel.
Az egyik projektemnél például sokat használtam az AAM-től lesett folyamatábrák egy saját származékát, (minden botrányuk ellenére sok tehetséges, fiatal informatikust ismerek ott, akik komolyan veszik a szakmájukat.), nem teszem ki ide
(szellemi tulajdonuk), de a trükköt elárulom: nem csupán a feladat-, de a vele párhuzamosan folyó adatfolyamat is fontos.

Mire jó a modell?

A modell elsősorban a kommunikáció segédeszköze.

Attól jó, hogy:

Félexplicit
Már nem csinálhatsz benne bámit, mintha simán írnál, de még nem program
Olcsó
Nem kerül annyiba, mint a tényleges program (Nem értek egyet azzal, hogy egy jó UML ábra elkészítése annyi idő mint a vele ekvivalens programé, vagy én programozok baromi lassan.)
Átlátható
Persze, csak ha jól csinálod

Mivel ez egy kommunikációs eszköz, ezért három helye van tipikusan:

Az ügyfél és közted
Egymás között (programozók)
Magadban

Igazából ha valamit nem értesz, az ügyfél nem ért, vagy a kollega nem ért, akkor nem szabadna kódhoz nyúlnod, akkor kellene használnod a modellezést. Ezért kéne a modellezési eszközöket és szabályokat ugyanúgy ismerni, mint a programnyelveket.

Modellezés a mindennapi életben

Ha vitás kérdés van, évek óta berántom a csapatot tábla elé, ez mostani munkahelyemen se változott sokat

A modellezés tökéletesen alkalmas arra, hogy ezeket a vitákat tisztázzuk (nem feltétlenül pusztán hierarchikus alapon, “merénaszontam”), illetve annak ellenőrzésére, hogy tartja-e magát mindenki ehhez (az adott szempontú) közös megegyezéshez.

A kódolás végeztével ezzel a modellel lehet ellenőrizni, jól csináltuk-e azt, amit csináltunk, többet viszont nem használjuk, max mellérakjuk a modulnak valahogy, hogy ha kell, itt van egy ábra, ki tudja még, mire lesz jó.

Az ilyen ábrák elsősorban táblára készülnek. Ezért van a legtöbb informatikai cégnél jó sok nagy fehér filctábla. Ha ez nincs, akkor van flipchart, de az pici, és kényelmetlen is.

Modellezés tábla nélkül

Végső megoldásnak elárulok egy trükköt: ha ezek egyikére sincs pénz, lehetőség, keressetek egy szabad falfelületet, legalább másfél-két négyzetmétert, és oda ne tegyetek semmit, ami nem eltolható bármikor (asztal, szekrény, stb). Egy adag flipchart papir (vagy felhasználatlan buliplakátok, mint a jó-helynél anno), és párszáz forintért beszerezhető bluetack vagy gyurmaragasztó (az leszedhető) is megteszi, csak ragasszátok egymás mellé a lapokat, ha pedig váltani kell, leszeditek az egyiket a gyurmaragasztóról, fel a másikat. Magát a bluetack-ot óvatosan szedjétek, különben vakolattal jön (tapasztalat)!

Sokan max befényképezik ezt az ábrát, úgy küldik szét, vagy akár csak ezt se, annyira egyszerhasználatos.

Szerintem viszont készítsd el rendesen, gép előtt. Ilyenkor mindig figyelek arra, a megfelelő szavakat, a megfelelő vonalakat, megfelelő sztereotípiákat használjam, mindent oda, úgy kössek be ahogyan kell, a felesleges részeket kihagyjam, ha rájövök, több nézőpont egyesül az ábrán, esetleg szétszedjem azt.

Fontos ugyanis, hogy ne egy körülbelüli massza alapján dolgozzunk. A tapasztalat az, hogy a programozók ezeket az ábrákat utána kinyomtatják, és ott van előttük, miközbe dolgoznak (akkor is, ha ezt nem kérem külön). Amikor jössz átnézni a kódot, akkor is lehet hivatkozni a kezedben lévő lapra, hogy hol vannak az egyes modulok, hol vannak az összekötések. Sokkal tisztább ez így.

Ez másfél-két órát vesz el maximum ábránként az életemből: az érvényességük általában 1-2 hét, ez alatt bőven megtermelik ezt, mivel nem a kétértelműségeken vitatkozunk naponta fél órát egy-egy apróbb félreértés miatt.

Mi ezeknek az ábráknak a sorsa? Van egy megbeszélés, felskicceljük a táblára, én megrajzolom gépen, körbeküldöm, ez alapján leimplementálunk egy modult, vagy épp megváltoztatjuk azt, ellenőrizzük a végén, hogy jól van-e, de alapvetően egyetlen iterációra, vagy még annyira sem érvényesek, tehát tényleg 1-2 hét, egy-egy hónap az, amíg aktuálisnak nevezhetőek. Ezzel nincs semmi baj, ez alatt az idő alatt is rengeteget segítenek, sok félreértéstől kimélnek meg minket.

Persze vannak állandóbb ábrák, ilyenek az architektúra-leírások, a keretrendszerek ábrái, a fizikai topológia, adatbázis-séma. Ezeket figyelnünk kell, karban kell tartani, és emiatt lehetőleg minél kevesebb ilyen ábránk legyen, azok viszont legyenek jók, és a ciklusok végén naprakészek.

Rendszerszintű modellek

Hogy ez egy osztály, egy validálandó űrlap, vagy egy adatbázis-tábla? Te döntöd el. Hogy ez PHP, Ruby, Python vagy Java? Bármelyik lehet, ettől is modell. Azt döntsd el, érthető-e egyetlen ránézésre?

Említettem, hogy nem fogok Model Driven Developmenttel foglalkozni, most egy picit mégis. Van nekem egy trükköm ugyanis: a legtöbb model hierarchiára, gráfra, illetve függvénynevekre fog leképződni. Ezeket tök jól lehet pl. egy YAML fájlban tárolni, és megfelelően általános program ebből fog dolgozni, vagy használhatunk speciálisan elnevezett, esetleg más módon jelölt (annotációkkal, PHP-sok: getDocComment) függvényeket, sőt, MVC frameworkök, pl. a Symfony vagy a Zend Framework be is tartat velünk ilyeneket sokszor.

Miért pont YAML?

Lehetne XML is, a jó-hely idején konkrétan PHP asszociatív tömbök voltak, máskor JSON-fájlok, de ezek közül a YAML tartalmazza a legkevesebb felesleges látható karaktert (az XML pedig a legtöbbet sajnos.)

A YAML-ek jók, mert néha jobban átláthatóak, mint az ábrák, a modell pedig nem feltétlenül ábra. Ha ábrát akarunk belőlük csinálni, vegyünk fel egy új tulajdonságot: hideInModel. Ha ez van, skippeljük, egyébként tegyük lehetővé, hogy valamilyen ábrát (legegyszerűbb: GraphViz Dot ) tudjunk belőle készíteni.

A keretrendszereknél tipikusan az executeAction függvények szoktak ilyenek lenni, hogy mely modulokon milyen metódusok végezhetőek. Ezeket is össze lehet gyűjteni akár egy jobban átlátható YAML fájlba, akár egy DOT-ból generált diagramba.

A jo-helynél a modellek többsége nem létezett grafikus formában.

Mindehhez nem kell más, csak pár szöveges eszköz, pl. grep, find, esetleg az IDE beépített modellje a programkódról. Ne kézzel gyűjtögessük, írjunk programot rá!

De alapvetően akkor vagyunk jók, ha a programkódunk maga is olyan tiszta, mint egy model: más szempontokat máshol modellez,mégis, pont annyit ír le, amennyi szükséges.

Irodalom

Úgyse fogsz könyvet venni, így elektromos formában itt az agilemodeling.com, ami nem véletlenül ugrik be első találatként sokszor. A többi meg biztos megtalálható PDF-ként az internet latinos nevű közkönyvtáraiban.

Két könyvem van (a szabvány mellett): az UML Földi halandóknak és a Harald Störrle-féle UML 2.0.

Előbbi könyvet már ajánlottam itt, ezt megteszem ismét, kezdőknek, UML-lel egyetem óta igazából csak most ismerkedőknek mindenképp javaslom, de hozzátenném, napi használatra sokszor inkább a Störrle-könyvet használom, bármennyire is szeretem a Rational narancssárga kiadványát

A Störrle-könyv abban segít ugyanis, hogy rengeteg típusproblémát, és az ezekre nyújtott diagramválaszokat mutat be, mikor mit érdemes használni, ugyanakkor rendkívül száraz és tömény tud lenni, míg az UML Földi halandóknak egy nagyon jó bevezető ahhoz, hogy kell UML-t használni a mindennapi munkában, kedves hangvétellel (pl. hogy nem visz el az UML rendőrség

49c

Architect dolgok - agilis projekt

Aadaam — Sat, 21 Nov 2009 20:03:09 +0000

2934

A legutóbbi post után egyik olvasóm (feltéve, hogy több is van), arra kért, írjak az Agile módszerekről.

(Jövő héttől esküszöm, programozni fogunk. Suszter meg kaptafa, ugye.)

(Illetve lehet, hogy nem értek hozzá: viszont mi tudtunk határidőre is hozni dolgokat, nagyjából ezzel a készlettel. Azért ebben az iparban ez nem egyértelmű…)

A baj az, én nagyon rég vezettem projekteket, akkor is inkább vezetőfejlesztő voltam (úgy hívtam: szakmai / műszaki projektmenedzser), de leírhatom, hogy mik voltak az alapelveim a jó-hely és az azt megelőző projektek idején, és hogy látom most, akár az agilis módszertanok tükrében.

Itt szeretném halkan megjegyezni, biztos-ami-tuti, hogy ennek nem feltétlen van köze ahhoz, ahogy mostani munkahelyemen vezetnek projekteket, nem mintha nem csinálnának egy csomó dolgot nagyon jól, csak én ott fejlesztő vagyok, és nehogy valaki összekeverje.

Először is: a projekt csapatmunka. Az egyszemélyes projekt az az ott b… tad meg kategóriája. Tisztában vagyok vele, hogy sok van ilyen. De egyszerűen nincs mit projektmenedzselni vele! Vagy van motivációd, erőd, kitartásod végigcsinálni (aminek szerves része az, hogy a pénzt adó - ügyfél főnök, stb - rendszeresen cseszeget, illetve van merszed kérdezni), vagy nincs, és kb. itt van vége a történetnek. Ilyenkor problémák lehetnek, hogy:

Nincs aki átnézze a kódod, lehet, szar az egész.
Nincs akivel megbeszéld a problémáidat, ha megakadtál, meg vagy akadva, a Google vagy segít, vagy nem.
Nincs, aki megvédjen attól, hogy az ügyfél hülyeséget beszél
Ha nincs ötleted, nincs ötleted, valamit kiszenvedhetsz magadból, nem derül ki, hogy jó-e, még a végén se (maga a dolog szívás, vagy az elején félreértetted az ügyfelet / túlbonyolítottad? Sose fogod megtudni!)

Ezért én nem is szeretem az egyszemélyes projekteket. Emellett ugyanakkor a legfontosabb dolog a motiváció. Mondok egy példát: Georgy és Void, a KSZK két ikonikus veteránja, volt szobatársak. Előbbi egyszer azt mondta, hogy az egyetemi fejlődésének szerves része volt, hogy egymást húzták az újabb és újabb kihívásokkal, és így alakult ki pl. a saját funkcionális nyelvük (az SchML). De hozhatnánk példának a Szilícium-völgyet is, az is pontosan ezért működhet.

Ellenben számtalan olyan egyszemélyes projektem van, amit egyszerűen nem bírtam végigvinni, akkor se, ha fizettek volna érte. Egyszerűen nem ment, ott voltam a semmibe egyedül, tudom, hogy meg tudnám csinálni, tudom, hogy pénzt kapnék érte, de nem megy, nem megy és kész… Irigylem azokat, akiknek ez könnyen megy.

(Néha persze átszenvedtem magamat ezen.)

Tanulság: mindig legyetek legalább ketten.

A nap menete

Reggeli standup: Azt gondolom, az Agile legfontosabb vívmányainak egyike, hogy megtalálta azt a formátumot, amivel 10-15 percessé lehet tenni egy meetinget. Minden egyes napot ezzel a meetinggel kell kezdeni. A legfontosabb a rendszeressége, minden munkanap legyen!

Egy ilyen meeting pontosan 3 dologról szól:

mit csináltam tegnap
mit tervezek mára
milyen elakadásaim vannak, amikhez szükségem lenne segítségre.

A részvétel kivétel nélkül kötelező. Figyelemelterelő eszközök (számítógép, mobiltelefon) használata tilos!

Ez nem azt jelenti, hogy amúgy szóba se álltok egymással, csak ebből világosan látszik, hogy épp veszted el a motivációdat (ha már két napja van fontosabb dolgod, jó esély van rá, számodra a projekt belül már véget ért, nincs erőd rá), világosan látszik, mik azok, amik nélkül nem tudsz továbblépni, így nem leszel napokig elakadva, és az is kiderülhet, ha valakinek épp keresztbe tennél nem szándékosan.

Ezen kívül én egyébként figyelni szoktam az embereket: ha azt látom, hogy valaki már két órája iwiwezik, chatel, vagy nem nyúlt a billentyűzethez, akkor ott általában elakadás van. Egyébként is meg szoktam kérdezni 2-3 óránként, hogy áll, ilyenkor időszerűnek látom. Félreértés ne essék: nem a chateléssel van a bajom, vagy a pár perces pihenéssel, talán az arckifejezésen is látszik, ha valaki épp nem tud mit kezdeni a feladatával. Ekkor kell az, hogy még egy szem lássa a feladatot, és ne azért hogy azt mondogassa: márpedig ezt meg kell csinálni, hanem hogy vagy segítsen megoldani, vagy feladatváltást eszközöljön, hátha másnap, friss fejjel már egyértelmű lesz a megoldás.

Ezen túl is fontos, hogy a beküldött kódokat valaki nézze át: elvárásom szokott lenni a napi egy commit per fejlesztő, hogy tényleg tevékeny legyen a nap, és ezeket a kódokat átnézem. Ahogy öregszem, egyre szigorúbb a rostám, de ettől függetlenül még mindig abból derül ki bármi, ha ketten is látják azt a kódot, és csak attól fejlődhetsz.

Muszáj, hogy arról, amit csinálsz, rendszeresen beszéltessenek. Nem mindig, nem minden áron persze, de ha mindenkinek egyértelmű felelősségkiosztás van, egymás dolgaihoz pedig nem nyúlunk, az rosszabb lesz, mint az egyszemélyes projekt! Nem mellesleg az ilyenek úgy szoktak csúszni mint állat, mert a motiváció a legkisebb közös minimum szintjére csökken (”kész lehetnék vele, de Józsi se hajtja magát, én minek?”). (Igen, kettős játék ez: ha senki nem felelős semmiért, azért bukik be a projekt. Ha egyáltalán nincs közös felelősség, akkor meg azért.)

A hely

Fontos a legalább két helyiség: legyen egy hely, ahol meetingeltek, beszélgettek, terveztek, és legyen egy hely, ahol programoztok! Ez segít ezeket a ciklusokat jól kezelni, hogy mikor van kódolás, mikor van tervezés. Ha valami nem egyértelmű, esetleg többeket érint, sipirc be a meeting szobába megbeszélni! Mindenki lerakja az utolsó pontosvesszőt, és annyi.

Én nem szeretem, amikor a tábla a kódolóteremben - az arénában - van, csak zavarja a rendet. Annak a meetingszobában a helye. Persze a meetingszoba az is, ahol a telefonálások zajlanak, hogy ne zavarjátok a többieket!

Ide viszont csak indokolt esetben hozunk gépet, illetve nem illik hosszabb időre “kibérelni”. Erre esetleg lehet egy külön darálósarok, ami 4 csupasz falas, hogy csak arra tudj koncentrálni, amit épp csinálsz, meg egy pihenőszoba, ahol kanapé van, esetleg csocsóasztal (bár engem idegesít, ha egy pihenőszoba zajos.)

Szoftver

Nem hiszek a nagy wikizésben, se a szoftverdokumentációban általában, mert cseszettül nem frissítik őket, a kommentekkel együtt, épp ezért a minőségi kódokon szoktam inkább végigtekerni az embereket, amik pontosan azt tükrözik, amit csinálni akarsz, ha kell, kódgenerátorokon keresztül (hisz ekkor a forráskód az, amiből generálsz, a generálás tulajdonképpen fordítás egy köztes nyelvre). Így nem mondom azt, hogy tarts fenn egy wikit, de valami fájltároló azért jól tud jönni, meg szórd be az overview meg getting started doksijaid valahova, a diagramjaiddal együtt (a legtöbb diagram, amit készítek, rövidtávú felhasználásra szánt, de néha jól jön, ha még megvan.)

Viszont mindenképp legyen egy feladatkövetőd: a legtöbben a jirára esküsznek, ez ménkűdrága tud lenni, de nagyságrendileg mindent tud. Nekem az is jó, ha egy egyszerű flyspray-t felhúz valaki, az PHP-s, nem egy bonyolult dolog, a lényeg, hogy látszódjon:

kinek milyen dolga van még
mikor lesz ez az egész kész
mik a megbízó prioritásai (persze, minden most important, meg blocker a legtöbbnek, de erről néha le lehet beszélni)

Amit mindenképp tegyél meg, hogy ezt integráld valahogy a kommunikációs csatornáiddal: ha IRC-n kommunikálsz, legyen egy botod, ami egy parancsra felvisz egy új taszkot, ha e-mailen, akkor valami progi, aminek tudod forwardolni, és felrakja, nem érdekes, csak ne legyen plusz erőfeszítés az, hogy taszkot kell valamiből csinálni, mert annak sosincs jó vége. Ebből a kedvencem az I Want Sandy (sajna már megszűnt), klónja a cc:Betty, de biztos kitalálsz valamit. A cégnél az outlookba raktam bele egy virtuális mappát, aminek a home page-ét a projektmenedzsment rendszerre állítottam.

Az egyik legfontosabb célja a projektmenedzsmentnek, hogy mindig tudd, kinek, mit kell csinálnia, és ehhez várhatóan mire lesz szüksége, később meg konkrétan. Erre esetedben három dolog szolgál:

A use case-eid, amiket voltál szives felvenni, merthogy ezeket kell megoldani
A napi standup meeting, mert ez mondja meg, melyik use case hogy áll. Lehetséges, hogy modularizáltátok a feladatot a use case-ek alapján, nyilván, de ettől még ezt oldod meg. Hogy a use case-t user story-nak akarod hívni, az nem érdekel, a kettő közti különbség se.
A feladatkezelő szoftver, mert ez mondja meg, az egész projekt hogy áll. (Tőlem lehet excel tábla is, de hidd el, jobban jársz, ha mindenki magának tudja beírni a dolgokat)

Összegzés

Ha jól megnézed, ezen problémák mindig két dolog köré szerveződnek: kommunikáció és felelősség. Rossz hírem van. Egy átlag szoftverprojekt 40-60% kommunikáció, és 10-20% kódolás.

Hogy ez mennyire javítja a kódminőséget? Jó kérdés. Elsősorban határidők betartásában segít, hisz jobban fel tudsz készülni a helyzetekre, látod, ki hol tart.

Ami nagyban növeli a minőséget az a kommunikáció és a közös felelősségvállalás. Ha nem az van, mint a legtöbb cégnél ,hogy Sanyi ért a kapáláshoz, így Sanyi fog kapálni, és csak ő fog kapálni, a többiek meg azt se tudják, hogy néz ki a kapa…

511

Architect dolgok - informatika elméletben és gyakorlatban

Aadaam — Sat, 14 Nov 2009 13:35:56 +0000

2758

Az informatikának az elmélete és gyakorlata néha élesen kettéválik egymástól. Két tábor van: az egyik tábor - ők vannak kevesebben - megpróbál az elméleti principiumok mentén létrehozni egy akadémiai alapokra épülő szakmát, ahol a dolgok folyamata valamiféle profi rend szerint történik.

A másik tábor - ők vannak többen - az egyetemi tudás jó részét hasztalannak tartja, a saját életére nem érzi alkalmasnak.

Az Architect dolgok nem titkolt célja, hogy bemutassa az utóbbi tábor tagjainak, hogy igenis, érvényesek az ő életükre is ezek a szabályok. Az pedig, hogy nem így csinálják, hiányosság, ad absurdum legtöbbször hiba.

Ezt általában rendkívül gyakorlati - mindennapi munkámból vett - példák hétköznapi, az akadémiai életben kevésbé népszerű - php, javascript - nyelvekkel való megoldásán keresztül mutatom be.

A mai post ennél picit elméletibb. Én szeretném, ha ez egy kis vitát generálna köztetek, köztünk, így, író-olvasó között, már úgy értve, hogy a blogpostot mégiscsak én írtam, a kommenteket, visszajelzéseket meg majd reméljük, mások.

A Software Crisis arról szól, hogy a projektek 60%-a nem készül el időre vagy költségkeretre. Ez egy folyamatosan létező probléma, nem csupán a korai informatikára igaz, mai napig velünk van.

Amiről a software crisis nem szól, hogy azok a szoftverek, amik a végén így-vagy-úgy elkészülnek, mennyire teszik elégedetté az ügyfelet. Nem árulok zsákbamacskát, a legtöbb esetben semennyire.

Lehet ezért az ügyfelet okolni, hisz nem tudja mit akar, mindig változtat úgyis… De az építészetben ugyanez a helyzet, mégse omlanak össze az épületek, és alapvetően lakható helyeket készítenek jobb - akár magyar - építészeink.

Lehet ezért a beosztott programozóinkat okolni, de hisz legtöbben főiskolát, egyetemet végeztek, de legalábbis elkezdték: az építészetben a végrehajtók sokkal kevesebb képzettséggel rendelkeznek; mégis, a házak állnak, még a középszerű mérnökök által tervezett, vezetett projektek végén is.

Szerintem a hiba bennünk van: senior programozókban, vezetőkben, projektmenedzserekben, architektekben, bennünk, akiknek hozzáértésünket, akadémiai ismereteinket, szakolvasmányainkat kéne hozzárakni tapasztalataink mellett a projektekhez.

Profizmus - ennyiből?

Nem hiszek abban, hogy ez a munka nincs jól megfizetve: az orvosok se keresnek sokkal többet paraszolvenciával se (anélkül pedig pláne). Mégis felháborodnánk, ha bennünk maradna egy szike, félrekezelne, sőt, legtöbbször perelünk is emiatt.

Abban se hiszek, hogy ez az ügyfél kérése az “alacsony” árért cserébe: egyrészt a fejlesztések ára minden, csak nem alacsony, másrészt az építészetben is biztos jobb szeretnék az alacsony árat, csak épp nem mernénk végigsétálni az utcán: bármikor ránkomolhatna egy tetőszerkezet, új vakolat, kieshetne a frissen berakott ablak.

Pedig az ismereteink, eszközeink megvannak. Pontosan tudjuk, hogyan kell egy fejlesztési folyamatot kezelni: specifikáció, tervezés, implementálás, tesztelés. Azt is tudjuk, hogy ezeknek mik a gyorsított változatai (már az én időmben is kötelező tananyag volt pl. az eXtreme Programming).

A hiányzó megértés, tiszta kép

Tudjuk, hogy jó rendszerünk csak akkor lesz, ha a fejünkben tiszta a kép arról, mit kell megírni. Erre is ott vannak az eszközök, a use case analízis, az entitás- és folyamatmodellezés.

Hiányzik néha a metakogníció, hogy felismerjük, ha valami nem tiszta; de ezt el kell sajátítani, nincs mese.

Lássuk be: az informatika bizonyos szempontból egy kommunikációs szakma, egy gépnek tolmácsoljuk, mit akar az ügyfél. Ha nekünk nem tiszta, a gépnek hogy lehetne az? Ha egymásnak nem tudjuk elmagyarázni, ha - minden iránymutatás ellenére - képtelenek vagyunk megérteni az ügyfelet, akár saját személyiségünk hiányosságai miatt, mit akarunk egy objektív, merev gépszerkezettől?

Ezen álljunk meg egy picit: nem hiszek benne, hogy az ügyfélnek feladata lenne érthetően fogalmazni; őt ezért nem fizeti senki. Az ő feladata egyrészt fizetni, másrészt a feladatot érintő bármely kérdésre válaszolni. Ha ez ellentmondásos, nekünk kell ezt illusztrálni számára, felvázolva a lehetőségeket.

De az ügyfél a kisebbik baj: egymás közt is képtelenek vagyunk kommunikálni.

Ezt jól nyomon lehet követni a modellezési szokásainkon: a legtöbb magyar programozó képtelen modellezni. Nem, nem nem akar modellezni, képtelen; bár ezt nyafogással - ajj, minek? - szokták palástolni.

Jó példa erre, nem egyszer esik meg: egy programozótól (egyetemi diplomával) kérek pl. egy szekvenciadiagrammot, mert magyarázatából nem világos számomra, többezer soros objektumok hogy kommunikálnak egymással. De mindenféle kibúvó megjelenik, minden fontosabb lesz, szar az UML, meg fölösleges modellezni; és ha megcsinálja, abban sincs köszönet, használhatatlan lesz az egész.

Fontos megérteni: itt nem az UML a hibás (nem mintha nem lenne hosszú számlája sokunknál), az UML egy kommunikációs (és persze modellező) eszköz a sok közül; nem is az a probléma, hogy az illető ne ismerné az UML szekvenciális diagramm szintaktikáját; hanem hogy fogalma nincs arról, pontosan mit és miért is kell csinálnia a kódjának - és valószínűleg nem is érdekli.

Minták, frameworkök, az általánosításra képtelenség

Ismerjük a mintákat is, a jól bevált megoldásokat;sőt, elvileg arra is megtanítottak minket, hogy kell új, máshol le nem írt mintákat felismerni. Mégse vagyunk képesek ezekre reagálni sokszor. Ehelyett barmolunk, vagy csukott szemmel (erről még lesz szó, code review!) hagyjuk, hogy mások barmoljanak. Pedig a mi felelősségünk.

Nagyon zavarba ejtett, amikor megszóltak a múltkori framework-poszt miatt: “minek egy n+1. framework?” Minek? Azért, mert különben a nyers semmibe kezdtek volna implementálni. Nem lehetett behozni teljesen külsős rendszert, mert akkor a saját apukáik nem ismerik fel a modult, viszont a már létezőbe fel lehetett, és fel kellett ismerni a mintákat, ezekre pedig általános megoldást adni.)

Ennyi. Ha egy autókereskedő webshopba be tudsz rántani egy webshop frameworköt, ettől még lehetséges, kénytelen vagy egy hitelkonstrukció-frameworköt írni, mert egy más aspektusból viszont hiányzik az előre csomagolt, helyben felhasználható megoldás. De ennek nem megbocsátása, kiváltása az, ha külön, minden hitel-számítást kódból végzünk.

Ráadásul itt csak meglévő kód racionalizálását végeztük, addig-addig, amíg már nem kellett soronként vigyáznunk a biztonságra; amikor már csak egy, max két helyen kellett megmondanunk, mit is szeretnénk tulajdonképpen, nem pedig végig, három réteg 10 fájljában, folyamatosan escape-elve, sorokat másolva már meglévő kódokból..

Minden rendszer más mintákat követ, de a minták olyan dolgok, amik automatizálhatóak, programozhatóak. Ennek ellenére ritkán látok a “netről szedett” alap frameworkök (nevezzük nevén őket: perzisztencia, webcontroller, esetleg üzenetsor-kezelő, illetve sablonmotor) mellett ezekre ortogonális, tehát más szempontból megközelítő általános rendszereket - sokkal többször látok viszont többszörözött controller-sorokat..

(Egyébként külön öröm, amikor a rosszul kigondolt / használt frameworkökben a programozónak 25 helyen “kell” jelölnie valamit. Ekkor igazán eszébe juthatna, hogy vagy az eszköz rossz, vagy rosszul használja, mert ha két helynél többre kell valamit beírni, akkor már tuti bukta van.)

Egyedül nem mehet

A code review szokásokról nem is beszélünk, mivel ilyenek gyakorlatilag nincsenek: mások kódját is ritkán olvassuk ha az nem egy tutorial része, nemhogy egy munkahelyen egymásét, “mindenkinek van dolga”. Pedig ez a minőség egyetlen záloga, az egész módszertani felépítmény, a frameworkök, metodológiák nem érnek semmit, ha nem látja még legalább egy szakértő szem a forráskódot.

A Te felelősséged!

Fontos lenne megérteni: a minőség az iparág belső igénye kell, hogy legyen, a saját önbecsülésedé: a Te dolgod az, hogy az ügyfél minőséget kapjon, a Te dolgod, hogy olyat kapjon, amit szeretne, hogy ha egy mód van rá, szeresse használni, mert megkönnyíti a dolgát, mert logikus, mert intuitív, mert illeszkedik ahhoz, amit csinálna.

A Te dolgod, hogy a kód biztonságos legyen, hogy a honlap esztétikus legyen (igen, csak ritka esetben van külön dizájner a gyakorlatban), hogy megegye az internet explorer, hogy ne legyen lassú, és ezek egy része olyan nemfunkcionális igény, amiről az ügyfél nem is tud, nem is tudhat!

Nehéz szakma? Az. Sok az elvárás? Igen. De ezért nem bíznak sokan pusztán érettségivel rendelkező emberekre nagyobb rendszereket, mégha felsőoktatásunk az “egyik fülön be, másikon ki” embereket is termeli tömegével. Mert ezért van az a diplomádon, hogy okleveles mérnök[-informatikus].

51a

Architect dolgok - Use case-ek, modellek, követelmények

Aadaam — Sat, 31 Oct 2009 23:25:16 +0000

1d9b

A mai post kicsit alapszintűbb, műegyetemi infoképzést őszintén végighallgatók sok újat nem fognak benne találni. Az apropója egy új, fiatal kolléga a csapatban, aki teljesen új modult fog kapni, és arról beszélgettünk, ehhez hogy kell nekilátni - szerintem.

A kezdő informatikus - vagy a nem kezdő, ugyanakkor más szemléletű vagy épp autodidakta - ha kap egy feladatot, mivel kezdi?

Az adatstruktúrák felállításával.

You’re doing it wrong. *

(* Legalábbis szerintem, a legtöbb esetben)

Egy programnál sohasem az a kérdés, hogy milyen elemek vannak, ez részletkérdés. Ami a fontosabb: mit kell csinálnia annak a szegény programnak?

Erről ad információt az (egyesek kedvéért huszonötször átnevezett, elrejtett, átsematizált) use case modellezés.

Hadd kezdjem egy kijelentéssel: ha valami hülyeség az UML-ben, akkor a use case diagrammok bátran ilyenek lehetnek: a karikákkal ábrázolt use case-ek sokkal kevésbé hatékonyak, mint az egyszerű, jól megfogalmazott felsorolások. (Védelmükben: az UML 2.0-nak azért sok olyan része van, amit nem véletlenül nem emlegetnek egyáltalán nyilvánosan, azoknál azért hasznosabb, de talán leginkább a tisztán UML-alapú tárgyalás miatt szerepel a tananyagokban.)

De egyáltalán: miért is kellenek nekünk use case-ek?

Kedvenc példám: egy kisgyereket megkérdeztek arról, milyen az a kedvenc játékrobot, amit kezében tart. A gyerek nem azt mondta, hogy vannak szárnyai, csipogója, meg villogója, hanem hogy: “Hát ha kinyitod ííígy akkor wooooom és ha megnyomod iiitt akkor brrrrrrrrr és ha hátrahúzod így, akkor vijuvijuviju…” Nem azt mondta, milyen struktúrális elemei vannak - hanem hogy miket lehet vele csinálni!

Pl. ha nincsenek use case-eid, akkor jó esélyed van arra, a programod felesleges. Nem egy alkalmazás volt, amiről megkérdezték a véleményemet (vagy nem kérdezték, csak mondtam) különféle cégek, szervezetek, és a specifikáció megtekintése után azt kérdeztem: hol vannak a use case-ek?

Ezek egy része bemutatott, az Olvasó számára is hallomásból ismert, és kivétel nélkül bukott szolgáltatások.

A use case elemzéstől félünk a webszakmában, ugyanis kiderülhet, az oldalunk felesleges, nincs igény arra, amit mi ott kitaláltunk, vagy van már, ami jobban, szebben teszi ezt célcsoportunk számára, és ismerik is azt. Ezt persze nehéz beismerni, így a weboldal bukása után érdemes lehet a use case analízist a pszichoanalízissel együtt alkalmazni.

De mégis szükséges. Szükséges egyrészt programoknál is, másrészt viszont jó ötlet sima, statikus honlapoknál is.

És akkor most elárulok egy szakmai titkot: a szereplő fogalmat lehet párosítani a média és marketing célközönség fogalmával, gyakran meglepő (semmiképp nem korosztály-alapú) célközönségfelosztást alkalmazva, sikeressé tehetjük oldalainkat, hisz azt, és csak azt készítjük el, amire céközönségünknek szüksége van!

Miből is áll a use case analízis?

szereplőkből
use case-ekből, azaz a használat módjaiból (hogy lehet zümmögtetni, és vijjogtatni, és…)
forgatókönyvekből, azaz ezek hogyanjából (a zümmögtetéshez meg kell fogni iitt és aztán megnyomni iiitt…)

Először is a szereplőkről.

Ezt szinte mindig utólag finomítani kell, előszőr mindig gondolkozzunk azon, van-e a “rendes felhasználón” kívül esetleg valamiféle “karbantartó-jellegű” felhasználónk is, pl. adminisztrátor, moderátor, hírfeltöltő, anyagrögzítő, sőt, az informatikai modellezés szabályai szerint a külső rendszerek (pl. API-kliensek) is szereplőnek számítanak.

Ha már vannak szereplőink, gondoljuk végig: “mit is akarnak ezek az emberek (gépek) a leendő programunktól?”

Ez egy nagyon nehéz kérdés, pláne azért, mert arra is rá kell jönnünk, mit nem akarnak (pl. nem akarom, hogy az iWiW kávét főzzön, de a facebook se. Nem érdekel, készíthető-e kávéfőző app, én oda nem azért járok, arra ott van a kávéfőzőm adminfelülete. Integrált youtube se kell.)

(Nincs ilyen kávéfőző gépem: megrögzött teamániás vagyok. )

Ezek listái, szereplőkre bontva, lesznek a use case-ek

Ezeknek a leírásoknak viszont, mint már említettem, van formátumuk. A formátum alapesetben:

Ki mit mivel, azaz
Géza főz kávét a kávéfőzővel (Angolul: George cooks a coffee with the coffee machine: alany, ige, tárgy, többi. Tudom, hogy George az György…)

Ez nem véletlenül van így. Amikor áttekintjük őket, lesz egy rakás igénk és tárgyunk: ezek lesznek a rendszer alapkövei, a gombjaink, menüpontjaink feliratai. Érdemes esetleg segédigéket (Géza tud főzni kávét, akar főzni, szeretne, képes, stb) bevenni azért, sokszor könnyebben csúszik le így a torkon.

Ugyanakkor: lehet rossz use case: A Rendszer főz kávét Gézának. A Rendszer, ha egy mód van rá, ne csináljon semmit, amíg meg nem kérik. Géza főz kávét a segítségével, ez inkább. Vannak kivételes esetek, tipikusan az autonóm működés. Meg aztán ne feledjük, minden use case-nek lesz forgatókönyve (későbbi algoritmusa), amiben majd ott lesznek az autonóm részek, ahol a vizet forralja a Rendszer, meg kávét pörköl, de a use case az az, hogy mi az elvárás, mindig egy felhasználó igényét, és így interakcióját írja le.

(Honlaptervezés: Diák megnézi az órarendet / végigböngészi a galériát. Szülő tájékozódik a tanév menetéről / értekezletek időpontjairól / csemetéi állásáról / felvételi információkról. Felhasználó zenevideót keres előadó alapján. Kutató cikket keres évkritériumok alapján. Páciens felküldi frissen felújított mellei képét twitterre.)

Forgatókönyvek

A use case-ek forgatókönyvei szintén szövegesen szoktak készülni, itt már picit elválik egymástól az agilisabb user story, és a merev use case fogalom, előbbi ugyanis kevésbé foglalkozik a hibalehetőségek kezelésével és az intelligens hibaelhárítással, míg utóbbi nagyon is.

A forgatókönyvekre hasonló szabály vonatkozik ige-elrendezés szempontjából, de itt többször fog szerepelni a rendszer vagy a szervezet, mint alany. Pl. az use case, hogy pénzt akarunk levenni az automatából, az viszont már forgatókönyv-részlet, hogy a Bank leellenőrzi a pin-kódunkat.

Belőlük kivadászva a főneveket, és ezek rész-egész kapcsolatait elemezve fogjuk megkapni a struktúráinkat, amikből aztán osztályok, űrlapok, táblázatfejlécek, és persze osztálydiagramjaink lesznek.

De az már egy másik téma.

Ja, tudjátok, hol pionírkodták ki többek közt a use case-orientált gondolkodást?

Az én emlékeim szerint - de lusta vagyok adatokat kutatni, házi feladat - Palo Altoban, a Xerox PARC laborban. Talán ezért van annyira kevés gomb az Apple programokon?

a06

Architect dolgok - Ajánló: Javascript in the enterprise

Aadaam — Wed, 21 Oct 2009 21:46:55 +0000

(Kettő és feledik rész, linkajánló)

A tapasztalatom az, hogy a magyar programozók, ritka ám tiszteletreméltó kivételektől eltekintve, nem szeretik, nem is értik a javascriptet. A legtöbbje backend ember, jobban megbízik a statikus nyelvekben. Szíve joga.

Egy magyar srácot hallani beszélni arról, hogy hogy használják a javascriptet szerveroldali nyelvként, mennyivel biztonságosabb és skálázhatóbb(!) a javascript kód a javahoz képest, mennyivel egyszerűbb javascriptes embereket szerezni egyszerre meglepő és felemelő érzés.

A java számomra egyértelműen túl van értékelve. Persze nem azért szidom, mint mások, de ettől még nem mindig jó megoldás ott, ahol használják, és komoly problémák vannak vele nyelvi szinten is.

Hallgassátok hát Szegedi Attila előadását a Javascript üzenet-orientált banki rendszerükről az InfoQ-n.