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