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].