Avagy tanuljunk meg programozni, első rész.

A programozás vajon mi?

Mielőtt megpróbálnánk megválaszolni ezt a kérdés, kérdezzük meg a nálunk okosabbakat.

Például a magyar wikipedia-t:
Számítógép-programozás (vagy egyszerűen programozás) egy vagy több absztrakt algoritmus megvalósítását jelenti egy bizonyos programozási nyelven. A programozásban megtaláljuk a művészet, a tudomány, a matematika és a mérnöki tudomány elemeit.

Absztrakt algoritmus? Mi?? Művészet?! Már azzal kapcsolatban is vérremenő viták vannak, hogy mi a művészet. A programozás, mint művészet? Néhány év futószalagfejlesztés után kijelenthetem, hogy annyi művészet van a programozásban, ahány fotómodell a női rögbicsapatban. Ez a meghatározás teljesen használhatatlan, mehet a levesbe.



Angol wikipedia:
Computer programming (often shortened to programming or coding) is the process of writing, testing, debugging/troubleshooting, and maintaining the source code of computer programs.

Igen, ez lényegében helytálló, de úgy érzem, hogy pont a lényeg marad ki. És egyébként is túl száraz, kukába vele. Nézzünk valami érdekesebbet.



ROYAL PRECISION, Electronic Computer PROGRAMMING MANUAL:
Programming is planning how to solve a problem. No matter what method is used -- pencil and paper, slide rule, adding machine, or computer -problem solving requires programming.

Ott a pont. Ez a kézikönyv már több mint ötven éve, 1957-ben készült. Ezek a fickók már akkor megmondták a frankót. A programozás egy jól behatárolható probléma (az "unatkozom, mit csináljak?" nem az) megoldásának tervezése, függetlenül attól, hogy ezt milyen eszközzel végezzük. Programozni nem csak számítógépet lehet (bár célszerű azt), hanem lehet szövegszerkesztőt, számológépet, gyári gépsort, sőt még mosógépet is. Az agykontrollosok szerint akár embert is, de szerintem ők meg vannak húzatva.
Persze ennek az elgondolásnak nem az a lényege, hogy legyen OKJ vizsgánk abakuszra is. Mindegy hány nyelvet ismerünk, és milyen szinten, ettől még nem leszünk jó szakemberek. Természetesen a rutin, a magunk mögött hagyott sikeres projektet száma is fontos, de sokkal lényegesebb, hogy kifejlesszük magunkban azokat a készségeket, amiktől jó szakemberré válhatunk.

De hagyjuk az rizsát; a végső szót egykori munkatársam mondta ki anno:
A programozás egy roppant buta gép tanítása egyszerű feladatokra.

Miért egyszerű programozni?

Vajon mik lehetnek a programozás műveléséhez szükséges titokzatos készségek. Elgörbíteni a teret? Nem, azt csak a szcientológusok tudják. Meginni száz korsó sört 4 perc alatt? Nem, csak a schönherzesek gondolják, hogy ez programozás. Meghajlítani egy kanalat? Nem, nem, az meg a Geller. Megszökni a Nemzetközi Űrállomásról? Nem, az Michael Scofield. Akkor?

Nos, a szükséges készségek ezeknél sokkal hétköznapibbak.

• Tudnunk kell általánosítani dolgokat. Hm, ez könnyű. A szőke nők okosak. Majdnem. Nem ennyire egyszerű, de első nekifutásra nem is túl bonyolult. Arról van szó, hogy fel tudjuk ismerni, és ki tudjuk emelni a közös tulajdonságokat különböző fogalmakból. Például, ha megvizsgálunk egy csomó állatot, akkor észrevehetjük, hogy vannak olyan közös tulajdonságaik, amik alapján csoportokba oszthatjuk őket. Vannak például elevenszülő állatok és vannak tojással szaporodó állatok. De egy más aspektusból vizsgálva elkülöníthetjük az állatokat úgy is, hogy vannak szőrös, tollas vagy csupasz állatok (például az egyiptomi kopasz macska, a szfinx). A gyakorlatban macskákkal és tojásokkal nem lesz sok dolgunk, viszont nagyon fontos, hogy egy adott feladat és egy hozzá hasonló másik között felismerjük a párhuzamot és lekezelve a különbségeket, egyetlen feladatot gyúrjunk a kettőből.
• A megkülönböztetés az általánosítás fordítva lejátszva. Van egy tág csoport, például az emberek. Mindannyian képesek azokra a feladatokra, amelyeket az összes ember meg tud tenni (fülvakarás, orrpiszkálás, tüsszentés), de van három ember, aki ezeken felül képes megjavítani az órákat. Ők az órások, akik emberek (vakarnak fület), de képesek olyasmire is, amire a többi ember nem (órát buzerálni).
• Dekompozíció. Ez tényleg egyszerűbb, mint ahogy hangzik. Arról van szó, hogy tudnunk kell komplex problémákat feladatokat, könnyebben megoldható feladatokra bontani. Például ha az a misszió, hogy "utazzunk Kínában", akkor ezt a feladatot felbonthatjuk a "útlevélvadászat", "vízum kikönyörgése a követségen", "szállodai szoba stipi-stopi", "röpülőjegy megvásárlása" problémákra. Természetesen ezeket aztán újabb, még egyszerűbb feladatokra bonthatjuk, és ezt addig csináljuk, amíg eljutunk nagyon egyszerű feladatokhoz jutunk, amit aztán egyszerű lesz algoritmizálni is.
• Nem árt némi intuíció, különösen akkor, amikor megpróbáljuk kitalálni, hogy mi lehetett a kedves kolléga fejében, amikor megszületett az a fantasztikus alkotás, amit éppen megpróbálunk kijavítani (ugyanez fordítva is igaz - szerk.).
• Természetesen az sem árt, ha valamennyire tisztában vagyunk azzal, hogy hogyan működik egy számítógép. Ez azért nagyon fontos, mert a számítógépek és a szoftverek a legkomplexebb ember alkotta szerkezetek, amiből adódik, hogy a legtöbb hibalehetőség is itt van. És ugye tudjuk, ami el tud romlani, az el is fog.
• Ha élesben is hasznát akarjuk venni a tudásunknak, akkor szükségünk lesz arra, hogy legyen rutinunk, ahogy bármely más szakma esetében is. Bármit meg lehet oldani programozással, de egyáltalán nem mindegy, hogy mennyi idő alatt. Ezt azért érdemes fejben tartani, mert van olyan eset, amikor nem szabad ész nélkül nekiugrani valaminek, és olyan is, amikor belekezdeni sem érdemes.

Persze a felsorolás nem teljes, de első körben én ezeket szerettem volna kiemelni.

Miért bonyolult programozni?

Ha elolvastuk az előző fejezetet, akkor úgy gondolhatjuk, hogy pofonegyszerű lesz belevágni a bitkukta bizniszbe. Sajnos a valóságban tényleg sokan így gondolják, ezért is van olyan sok kontár. Azonban van egy-két dolog, ami miatt mégsem lesz minden wannabeből jó fejlesztő.

• Az előző fejezetben néhány egyszerű példával dobálóztam: állatok, emberek. Ezekkel tényleg nagyon könnyű dolgozni, hiszen ezek egyértelmű fogalmak, amiket nagyon egyszerű kategorizálni. Azonban a gyakorlatban nem ilyen egyszerű a dolog. Amikor fejlesztünk egy rendszert, akkor rengeteg mesterséges fogalmat alkotunk, amelyeknek nincs túl sok köze a valósághoz.
  Nézzünk egy példát (aki nem ismeri az objektumorientált programozás alapjait, ki is hagyhatja ezt a részt egyelőre). Létrehozunk egy mailsender nevű osztályt, amivel egy levél küldőjét akarjuk reprezentálni.  Itt máris felmerülnek kérdések. A valós világból modellezett rendszerben logikusnak tűnne, hogy a levelet ez az osztály küldje el, tehát ennek a felelősége, aminek az eredménye az lenne, hogy lesz egy "send" nevű metódusa. Azonban a legtöbb esetben ez csak egy adattároló osztály, ami nem csinál semmit, vagy ha igen, akkor sem ez vezérli a levél küldését. Ha saját magunk készítettük az osztályhierarchiát, akkor viszonylag könnyű értelmezni saját agymenéseinket, de ha más is beszáll a projektbe (ami ugye a gyakoribb eset), akkor könnyen bajba kerülhetünk...
• A valóságban végbemenő üzleti (vagy akármilyen) folyamatok nem egyértelműek és a hozzájuk tartozó fogalmak nem hierarchikusak. Minden fejlesztő azt szeretné, ha a valóság logikus lenne, sőt, szögletes, tökéletes derékszögekkel, minden szépen szimmetrikusan elrendezve. De a környezet inkább a "folyamatosan változó káosz" kategóriába tartozik, és az nem fekszik kettes számrendszernek.
• Az informatika önmagában értelmetlen, minden megoldható problémának valamilyen más területen végbemenő folyamathoz van köze (természetesen informatikai problémákat is oldunk meg informatikai eszközökkel, de ez most nem lényeges). Emiatt a fejlesztőknek mindenhez kell érteni egy kicsit, valamelyest ismernie kell azt a területet, amelynek dolgozik. Például, ha egy fejlesztőnek fogalma sincs arról, hogy mi történik egy raktárban (a "dolgokat tárolnak ott" az kevés), akkor nem fog használható rendszert készíteni egy raktárosnak soha. Sajnos sok programozó nem érzi magáénak ezt a gondolatot, nem tartják fontosnak, hogy megismerjék azt a folyamatot, amelyet informatikai környezetbe ültetnek. Átadás után meg persze kezdődik a hülyézés, a felhasználók szerint az átadott termék gagyi, a fejlesztők szerint meg az összes felhasználó hülye.
• Szerintem kevés olyan rendezetlen káoszszakma van, mint az IT. Szabványból annyi van, mint égen a csillag. Legyen választék, az a fontos. A sikeres projektet aránya 10% körül van. Mindenre létezik keretrendszer, nem is egy, hanem ötszáz, és egyik se mondható tökéletesnek. Persze ettől még használhatóak, de általában elég nehéz eldönteni, hogy a keretrendszer nyűgjeinek kiismerése, vagy saját megoldás kifejlesztése visz el több időt.

Programozó-e leszek?

A válasz nem nehéz: igen, programozó leszel, ha akarsz, mert ez nem rocketscience. Azonban nem mindegy, hogy milyen. Sok ember vallja magát annak, miután rájött hogyan kell html-ben linkelni, és írt három sort phpben. De ez nem elég. Sokféle módja van annak, hogy rendes fejlesztő legyen belőled, de egyik sem gyaloggalopp. Szóval, harcra fel.
És még valami: ha van egyetemes jó tanács ebben a kérdésben, akkor az ez: mindig a felhasználó szemével nézd a programod. Egyébként szar lesz.

Folyt. köv.

Források:
Számítógép-programozás
Computer Programming
ROYAL PRECISION Electronic Computer PROGRAMMING MANUAL

Könyvajánlat:
Angster Erzsébet - Objektumorientált Tervezés és Programozás JAVA I. kötet

A bejegyzés trackback címe:

Trackbackek, pingbackek:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.