A programozó egy napja és a munkájának menete

Visszatérő téma az ügyfélszolgálatunkon az, hogy egy leendő tanulónk amiatt bizonytalan, mert nem tudja, hogy maga a programozás örömet okozna-e neki. Mert a pénzt és az időt szívesen rászánná, de ha a végén nem érzi magát boldogabbnak, mint a jelenlegi munkájában, akkor nem érte meg a folyamat az áldozatot.

Ez egy teljesen érthető szempont, és erre szeretnék reflektálni a sorozat három blogcikkében.

A második rész a programozó egy napját és azon belül a programozás folyamatát mutatja be.

Az első rész itt olvasható.
A befejező részt itt találod.

A programozó egy napja

A programozó egy napja valamilyen szinten minden cégnél változik, de egy viszonylag elterjedt metódus szerint reggelente van egy közös gyors meeting, aminek során mindenki elmondja, hogy mit végzett előző nap, mi a terve az előtte álló napra, és milyen kihívásokkal szembesült, amiben segítségre van szüksége. A hosszabb meetingek 2-3-4 hetente vannak, amikor egy-egy csomag új funkció készen van, és a következőkkel kapcsolatosan kell megbeszélni a lépéseket, terveket.

A meetingeken kívül az ember általában önállóan dolgozik a saját számítógépénél, elmélyülten a saját feladatain.

Hogyan dolgozik egy programozó?

Kezdjük onnan, hogy van egy jól körülhatárolt feladat (mint pl. A StudiCore Online feladatai), amiben már minden lényeges értelmezési kérdés tisztázva van. (Amíg ez nincs, addig lényegileg úgysem fog neki a programozó a programozásnak, mert nem fogja megérteni a feladatot teljes mélységében, ekkor valamilyen döntéshozóval kell egyeztetni tárgyalóban, személyesen vagy videókonferenciában, esetleg telefonon… Ez viszont nem számít bele a következőekben ismertetett folyamatba). A könnyebb érthetőség végett analógiaként egy asztal elkészítését is bemutatom.

Sok esetben nem új funkciót fejleszt a programozó, hanem egy meglévő funkciót módosít, amihez természetesen már ismernie kell a meglévő program / funkció felépítését, ez némi tanulást, utánajárást igényelhet, de ez a bemutatott folyamaton nem változtat érdemben.

1. Először a programot / programrészt / módosítást ki kell találni, hogy hogy épüljön fel kisebb részegységekből, azaz meg kell tervezni. Ebben a fázisban az ember lehet, hogy rajzolgat egy táblán, vagy írogat, mindenesetre elmélyülten gondolkozik azon, hogy hogyan épüljön fel a kisebb egységekből (kockákból) a teljes egész. Addig vizsgálgatja különféle aspektusokból, amíg úgy nem érzi, hogy az egyes részegységek már olyan egyszerűek és annyira simán kapcsolódnak egybe, hogy azt ha leül a számítógép mellé, már könnyedén “le tudja kódolni”, azaz le tudja programozni. (Mekkora és milyen fadarabokból áll majd össze az asztal, hogy nem fog szétesni, ha ráteszünk egy fazekat).
   Ha valamelyik részlet homályos, hogy hogyan fog megvalósulni, érdemes lehet azt a részletet előre kipróbálni, mielőtt a többibe nagyon belemerül az ember. Így akkor kitisztázódik egy részlet, és tovább lehet haladni a terv megalkotásával. (Csinálunk egy kis makettasztalt, ahol kipróbáljuk, hogy nem esik szét.)
   Ennek a fázisnak a része lehet az, hogy a programozó utánanéz egy-egy megoldásnak, hátha van (már újabban) olyan eszköz, ami elegánssá teszi a program tervét. (Megnézzük az interneten milyen megoldások vannak szét nem eső asztalok készítésére).
   Előfordulhat az is, hogy ha éppen a program tervének egy homályosabb részen gondolkozik, akkor az a cél, hogy kiderítse, hogyan lehet az adott részt áthidalni.
   Ez a fázis a leginkább szellemi kihívást jelentő, legtöbb kutatást, utánajárást igénylő, de sokunk számára a leginkább élvezetes része a programozásnak.
2. Ha megvan a terv (még ha csak firkálásként vagy csak fejben, de már összeállt), akkor lehet leülni programozni. (Elkezdünk fűrészelni.) Ilyenkor nyílik a fejlesztőkörnyezet, és készülnek a programsorok. Ha a terv jó volt, akkor a végén előáll a kész program(rész).
   Persze nem mindig tökéletes a terv, lehet, hogy az ember menet közben jön rá, hogy ahogyan elképzelte, úgy nem is lehet megoldani a problémát. Ekkor visszalép az előző lépésre, és újragondolja a megoldási lehetőségeket, és új utat választ. (Az asztal kicsiben elbírta a terhet, nagyban meg szétesik). A rutinnal egyébként egyre jobb tervek készülnek, és egyre inkább “ráérez” az ember, hogy mit kell előre kipróbálnia, minek kell utánanéznie, mire kell odafigyelnie.
3. Ellenőrzés. Ha egy program “kész”, akkor még hátravan az ellenőrzése. Legalapabb szinten az ember csak kipróbálgatja különböző bemenetekre vagy végigkattintgatja, de ez ugye nem szokott minden részletre kiterjedni, és elég unalmas is. (Az asztalunkra rátesszük a súlyokat, megnézzük elbírja-e, illetve lemérjük, akkora, amekkora kellett).
   (Nem is annyira) újabban már inkább az a divat, hogy az ellenőrzést az 1-es és 2-es fázis között elkezdik, mégpedig úgy, hogy az ember a saját programjának először az ellenőrzését írja meg, majd utána a programot magát. Így akkor kap egy egy kattintással futtatható másik programot, ami mindig azonos módon és mindig az összes megírt ellenőrzést elvégzi. (Test Driven Development -TDD – a StudiCore Online 14. fejezete erről a témáról szól)
4. “Kész van”. Azért az idézőjel, mert nem biztos, hogy a tesztjeink minden részletet lefedtek, illetve hogy az a program, amit írtunk, a felhasználónak is kielégíti az igényeit. Szóval átcsúszhat még hiba. (Az asztal nem biztos, hogy tetszik majd annak, akinek készítettük).
5. A nem megfelelő működést úgyis jelzik a felhasználóink. A jelzések általában egy hibakezelő rendszerben gyűlnek, amelyeket az adott rész írója – fontosságtól függően előbb vagy utóbb – kezel, és megírja az adott rész javítását. (Mondjuk úgy, hogy kiegészíti a tesztjeit egy olyan új funkcióval, ami reprodukálja a hibás működést, majd megírja a javítást, hogy minden teszt rendben legyen).
   (Az asztalnál pl. rájöhetünk, hogy szuvas volt a fa, ezért idővel kitörik a lába – ahogy a programokban is már benne van a hiba, ami miatt a probléma előkerül.)

Az 5-ös és az 1-3. pontok a legtöbb esetben átlapolódnak egymással.

Lehet, hogy amit itt leírtam, egyelőre még elég homályos, nem is tudod mélységeiben elképzelni, így azt javaslom, hogy tegyél egy próbát a StudiCore Online-nal. Már a Java SE modulban lesznek olyan feladatok, amelyeken ezeket a lépéseket komolyan ki tudod próbálni. Aztán ha tetszik, haladhatsz tovább.

Ha még nem töltötted ki a tesztünket, töltsd ki, és 5 napos ingyenes hozzáférést kaphatsz a StudiCore Simple programhoz. Ha kérdésed van, az ügyfélszolgálatunk tud segíteni.

Pasztuhov Dániel