A Programírás elmélete... vagyis miből lesz a cserebogár

Mottó: “Dolgozni csak pontosan, szépen, ahogy csillag megy az égen”...

Szögezzünk le bevezetőként egy dolgot: van különbség a programozás elmélete, és a programírás elmélete közt. És nem csak két betű... Előbbi olyan dolgokkal foglalkozik, mint algoritmusok, meg komplexitások, meg hasonlók. Na, itt nem erről van szó. Itt programírásról fogunk tárgyalni, és én azt látom ez alatt a fedőnév alatt, hogy miként kell egy programot megtervezni, megírni, sikeres programmá varázsolni.

Egy program életében talán a legjelentősebb szakasz az maga a tervezés szakasza. Ha egy program megfelelő tervezés nélkül kerül abba a szakaszba, amit egyszerűen csak “kivitelezésnek (leprogramozásnak)” nevezzünk akkor, nagy valószínűség szerint a programozó, akire az a hálátlan feladat jutott, hogy kivitelezze a programot, rengeteg gonosz gondolatot fog küldeni a program tervezője fele. Ezeknek a gonosz gondolatoknak az alapjai lehetnek akár olyan egyszerű kis dolgok is, hogy a program tervezője nem specifikálta le világosan a menürendszert, vagy lehetnek olyan súlyos gondok is, hogy a tervező nem gondolt arra, hogy a programot a (távoli vagy közeli) jövőbe hálózaton is lehessen használni, tehát “kifelejtette” a kommunikációs modult.

Amikor a program túljutott a tervezés fázisán, a programozó(ko)n van a sor, hogy nagyot alakítsanak. Amennyiben csapatmunkáról van szó (és manapság szinte csak arról van már szó), ott nem az a lényeg, hogy mindegyik programozó fitogtassa a szuper programozói képességeit:

Első Programozó: “Hú, három tömör sorba megírtam a teljes adatbázis beolvasást. Király vagyok!”.

Második programozó (miután bepillantott Első Programozó kódjába): “Igen, igen, de látod, te feltételezed, hogy táblának mindig négy sora van. Ha most berakok még egy sort, akkor a szuper három tömör sorod azt már nem fogja kiolvasni. Ne feledd, hogy a program nem a mi tesztadatainkkal fog futni.”

A csapatmunka is egy jól megszabott protokollon alapul, ahol olyan dolgok is le vannak szögezve, mint a változók elnevezése, a modulok neveiről, meg az osztályok elnevezési konvenciójáról nem is beszélve.  Jó programot csak jó csapattal lehet írni.

Természetesen, mindez nem elég. Szükség van még egy nagyon alapos tesztelésre is, ahol a tesztelők úgymond ”kínozzák” a programot. És ott nem lehet elnézni a kis (nagy) hibákat, vagy átkeresztelni őket “feature” -nek, mert ha a végfelhasználó (rosszabb esetbe a kliens aki megrendelte a programot) nincs megelégedve ezzel vagy azzal, akkor késik a fizetés a programért, emiatt késik a programozó fizetése, emiatt elégedetlen a programozó, és nem úgy javítja ki a bugot ahogy kell, és íme, végtelen ciklusba kerültünk.

Tanulságként: programot írni nem könnyű feladat. Jó programot írni viszont kifejezetten nehéz. Sok tapasztalat szükségeltetik, és nem csak a jó programozó meglétén múlik egy program sikere.

Deák Ferenc