Anno, mikor először programozni tanultam, akkor pár alapszabályt minden könyv, minden tanárom a fejembe vert. Ezek azok a szabályok, amit a saját érdekében mindenkinek be kellene tartania programkészítés közben. A feltételes mód nem tévedés. Nem fog senki a fejünkhöz fegyvert szorítani, hogy tartsuk be a szabályokat, de hosszútávon nem fog ártani. Az itt ismertetett modellt a szakirodalom vízesés modellként tartja számon, mivel az egyes lépések egymásból következnek.
-
Specifikáció
A programozás azzal kezdődik, hogy kitaláljuk, hogy mire akarunk programot írni és hogy hogyan kellene működnie a programnak. Értelemszerűen minél bonyolultabb, minél összetettebb dologra kell programot írnunk, annál bonyolultabb lesz a specifikáció is.
-
Tervezés
Ez a fázis a specifikáció tovább részletezése. Itt már konkrét tervezési részletekbe is bele kell menni. Az egyes algoritmusokat1 itt kellene megtervezni, illetve itt gondolni kell a jövőbeli bővíthetőségre is.
-
Kódolás
A kész terv megírása a választott programozási nyelven. Bonyolultsága, időigénye függ a terv részletességétől és a program bonyolultságától.
-
Tesztelés
Minden programot tesztelni kell. Egy tipikus programozó vicc szerint minden érdekes program tartalmaz egy elágazást, egy ciklust és egy rejtett hibát. Ebben a lépésben a rejtett hibákat igyekszünk kiszűrni. A tesztelés folyamata szintén az elvégzett tesztek sokaságától és a program bonyolultságától függően eltérő lehet.
-
Hibajavítás
Az előző pontban feltárt hiányosságok, hibák javítása. Hibától függően vagy vissza kell mennünk a tervezés lépéséig, vagy csak a kódolásig.
-
Dokumentálás
A dokumentálás két dolgot takar: a fejlesztői és a felhasználói dokumentációt. A fejlesztői dokumentáció lényegében feljegyzés, iránymutatás magunknak a program megvalósítását illetően. Ennek részét képezi a specifikáció és a tervezés során megalkotott összes dokumentum is. A felhasználói dokumentáció iránymutatást kínál a felhasználóknak, hogy miként is kell használni a programunkat.
Gyakori hibák
A gyakori hibák közé tartozik a specifikáció menet közbeni megváltozása, a fenti vízesés modell szerint dolgozunk. Ez főleg akkor fordul elő, ha előre nem lett egyeztetve kellő részletességgel, hogy a felhasználó mit szeretne. Éppen ezért a specifikációt érdemes írásban rögzíteni, vagy agilis módszertan szerint tervezni.
A tervezési hibák többsége tapasztalatlanságból vagy a nem elég részletes specifikáció miatt következik be. Ezek egy része rutinnal és gyakorlással elkerülhető.
Kódolási hibák minden nyelv esetén előfordulhatnak, viszont C# esetén lényegesen nehezebb hibás kódot produkálni a beépített intelligens ellenőrzések miatt, mint mondjuk C++ esetén.
Programot tesztelés nélkül nem szabadna kiadni, azonban már volt rá példa, nem is egyszer, hogy ez megtörténjen. Éppen ezért ipari környezetben általában külön csapat foglalkozik a már meglévő kódok tesztelésével.
Ha hibát találunk a programunkban, akkor azt illik kijavítani. Azonban ez nem biztos, hogy egyszerű folyamat lesz. Ennek oka a dokumentáció hiányában, hiányosságaiban vagy a tervezésben keresendő. Képzeljük el azt a szituációt, hogy alkotunk egy programot, leteszteljük, azonban ~1-2 év múlva jelentkezik egy olyan hiba, amire eredetileg nem számítottunk. Ilyenkor, ha nincs részletes dokumentációnk, akkor újra meg kell értenünk a program működését és csak utána tudunk érdemileg a hiba javításával foglalkozni. Egy vicces mondás szerint, amit illő lenne kerülni a programjainkban: „Mikor írtuk ezt a programot, akkor ketten értették a működését: Én és Isten. Mára csak egy valaki érti: Isten”
A hibák elkerülésében segít, ha betartjuk a S.O.L.I.D és a D.R.Y elveket. A S.O.L.I.D elvekről a könyv későbbi részében lesz szó. A D.R.Y elv a Don’t Repeat Yourself szavakból képzett rövidítés. Lényege, hogy ha már kitaláltunk egy megoldást egy problémára, akkor használjuk azt újra és ne ismételjük magunkat, mivel ha hibásan másoljuk a megoldást, akkor új hibát viszünk a rendszerbe és nem utolsó sorban, ha változtani kell, akkor nem elég ezt egy helyen megtenni.
Hogyan tanuljunk programozni?
Ez alapvetően egy pedagógiai kérdés, amire nagyon jó válasz nincs. Ennek oka leginkább abban keresendő, hogy ez egyén függő. Ezzel ki is térhetnék a válaszadás elől, de ennek nem sok értelme lenne. Az alábbi pontokban a nekem bevált módszert ismertetném.
- Szerezzünk egy jó könyvet (ezt kipipálhatjuk szerintem, ha egy picit lehetek nagyképű) és olvassuk el.
- Gyakoroljunk, írjunk programokat.
- Írjunk további programokat.
- Ha elakadnánk, akkor keressünk interneten rá a problémára. A sikeres kereséshez angol nyelv ismeret és Google felhasználói ismeretek szükségesek.
- Ha nem találtunk választ a problémára, akkor próbáljuk meg minél jobban specifikálni a problémát és kérdezzünk rá egy fórumban.
- Képezzzük magunkat folyamatosan. Rengeteg programozásról, módszertanokról és tervezési mintákról szóló könyv van és fog megjelenni.
- Ismételjük végtelenségig a fentebb említett pontokat.
A programozás varázslat?
Mióta tanítok, számos diákkal találkoztam, akik szerint a programozás valamiféle varázslat. Szeretném ezt mondani, de helytállóbb a varázslatos kifejezés. Alapvetően a programozás egyfajta gondolkodásmód elsajátításából áll. Ha ezt a gondolkodásmódot sikerül elsajátítanunk, akkor teljesen mindegy, hogy milyen nyelvet tesznek elénk, mert csak az aktuális nyelv szintaxisát2 és egy-két nyelvi jellemzőt kell elsajátítanunk és már tudunk is egy adott nyelven programozni alap szinten.
-
Algoritmuson vagy inkább eljáráson olyan megengedett lépésekből álló módszert, utasítás(sorozato)t, részletes útmutatást, receptet értünk, amely valamely felmerült probléma megoldására alkalmas.” – https://hu.wikipedia.org/wiki/Algoritmus↩
-
A nyelv szabályrendszere, amit be kell tartani ahhoz, hogy a programunk helyesen működjön.↩