L

A jó és a profi programozó közötti különbség

Szóval profi programozó szeretnél lenni? Büszkén akarod a világnak hirdetni, hogy "Profi vagyok!"? Azt szeretnéd, hogy az emberek tisztelettel tekintsenek rád, vagy hogy a szülők példaképként emlegessenek a gyerekeik előtt? Ráadásul minezt egyszerre?

A profizmus kétélű fegyver

Már az előző bejegyzésben taglaltam, hogy mitől jó egy jó programozó. Tehát, ahogy kifejtettem előzőleg, a jó programozó minden erejével a fejlődésre és a tudásszintjének növelésére koncentrál. Minden helyzetben feltalálja magát, minden aktuális újdonságot ismer, és nem lepődik meg, ha ritkán látott technikákat kérnek tőle. Tehát fejlődik, tanul, gyakorol.

De mit tud egy profi programozó?

A profi programozó büszke arra, amit elért, de emellett ez a cím a felelősséget és az elszámoltathatóságot is magával vonja. Nem lehetünk valamire büszkék, amiért nem vállalunk felelősséget.

Ha nem vagy profi, akkor csak az amatőr programozó címet érdemelheted ki. Az amatőrnek nem kell felelősséget vállalnia azért, amit csinál, ezt megteszi a felettese, vagyis a munkaadója. Ha egy amatőr hibázik, a munkaadó takarít fel utána. Ugye már érzed mi jön? Ha profi hibázik, ezek a felelősségek rá hárulnak, maga után kell takarítania, vállalnia kell a következményeket.

Mi történik, ha például a megrendelt webshop rosszul számol és ez a cégnek 1.000.000 Forint kárt okoz? Az amatőr megvonja a vállát és csak annyit mond, "Megesik az ilyesmi", és folytatja tovább a munkáját, esetleg kijavítja a hibát. A profinak ekkor ki kell fizetnie a keletkezett kárt, ha nem kötött szerződést a céggel, melyben levédte magát az ilyen hibák esetére. Ugye fájdalmas lenne ezt az összeget kifizetni, főleg hogy a saját pénzedről van szó? Egy profinak mindig éreznie kell ezt. Tehát a profinak vállalnia kell a felelősséget a munkájáért.

Hogyan vállald a felelősséget?

Főleg kisebb cégeknél, ahol nincs tesztelő csapat, gyakran fordulnak elő hasonló hibák. Túlhajszolod magad, túlórázol, hogy a határidőt tudd tartani, aztán reggel feldobod a rendszert és hátradőlsz. A felhasználók folyamatosan rendelnek, egymás után jönnek az új megrendelések, majd kiderül, hogy rossz értékeket töltöttél fel, így minden kiküldött és elmentett megrendelésben kevesebb összeget tárolsz. Mire a hiba kiderül, már milliós károkat okozott a program a megrendelő cégnek. Ilyenkor hívnak, hogy azonnal állítsd le a rendszert, tedd vissza a régit. Aztán dühösen hív a főnököd, hogy mi a franc történt. Elkezded keresni a hibát, és rájössz, hogy elírtad a kódot, rossz adatokat töltöttél fel, így rossz értékekkel számol a rendszer. A javításba belekezdesz, de napokba telik, mire teljesen újrateszteled és már a jó verziót töltöd fel.

Ezután felmondasz vagy kirúgnak.

Az egyetlen hiba, amit ebben az esetben elkövettél, nem tesztelted át a programot normálisan, hogy azt mondhasd kész vagy határidőre. Persze megteheted, hogy felhívod a főnököt, hogy a tesztelés miatt 2 napot csúszol, ennek általában nem örülnek, de legalább nem okozol vele kárt.

Ne tégy kárt

Milyen kárt tehet egy szoftverfejlesztő? Csak a szoftver szemszogéből nézve, kárt tehet annak működésében és felépítésében is. Hogyan kerüljük el ezeket?

A szoftver működésében okozott kár elkerülése

Arra törekszünk, hogy a programunk működjön. Legtöbben azért választottuk ezt a szakmát, mert egyszer már sikerült valamilyen működő szoftvert összeraknunk, és ezt az érzést akarjuk újra és újra átélni. De ez nem csak a mi vágyunk, nem csak mi akarunk működőképes programot, hanem a főnökünk és a megrendelőnk is. Azért kapsz fizetést, hogy a kívánalmaiknak megfelelő szoftvert kapják. Persze, ha megfizetik, ahogy ezt már írtam, ne hagyd lehúzni az áraidat, ha project alapon dolgozol, ha fix fizetésért, akkor vedd tárgytalannak. Ez is tönkreteheti a profizmusod, hisz kevesebbet keresel, kevesebb kedved van a programmal foglalkozni, de profiként az így okozott károkért is ugyanúgy vállalnod kell a felelősséget.

A programunk működésében akkor teszünk kárt, ha hibát ejtünk. Tehát a profik első szabálya, ne hagyjunk hibát a programunkban.

Természetesen erre most mondhatod, hogy a programok túl bonyolultak, lehetetlen hiba nélkül elkészíteni őket. Ebben igazad is van, de sajnos ez nem mentség.

A tökéletes kód megírása gyakorlatilag lehetetlen. Pont ez a szépsége a programozásnak, hogy 100 programozó 101 különböző programot fog készíteni ugyanannak a problémának a megoldására. A kódodban mindig lesznek hibák, ezekért pedig felelősséget kell vállalnod.

Egy profinak vállalnia kell a terhet, hogy bármikor felelősségre vonhatják olyan hibákért, melyek felbukkanása elkerülhetetlen. Így meg kell tanulnunk bocsánatot kérni. Persze ezt gyakorolni kell, mert általában a bocsánatkérésben áthárítjuk a hibát másra, még ha burkoltan is. A bocsánatkérés elengedhetetlen, de nem teheted meg, hogy profiként ugyanazokat a hibákat követed el újra és újra. Ahogy egyre több tapasztalatot szerzel a szakmában, egyre inkább arra kell törekedned, hogy a hibaszázalékod a nulla felé haladjon. Persze, ahogy feljebb is említettem, gyakorlatilag lehetetlen hibamentes kódot írni, de a te felelősséged, hogy a lehető legközelebb kerülj hozzá.

Tehát törekedni kell arra, hogy ne legyen hiba a kódban. Szakmaiatlan úgy kiadni a programot a kezedből, hogy tudod, hibák vannak benne. Feltöltés előtt mindig győződj meg róla, hogy biztosan hibátlan-e a kód. Persze játszhatsz zsákbamacskát, hogy talán nem derül ki és nem lesz probléma, vagy majd az ügyfél leteszteli és összeírja a hibákat. Ismétlem, ez szakmaiatlan hozzáállás, emellett kárt okozol a cégednek, a munkáltatóidnak és az ügyfélnek is. Miért?

  • csúszik a program átadása a tesztelések miatt
  • ha hibát találnak, te a hiba javításával fogsz foglalkozni, nem az új munkákkal
  • rengeteg plusz időt vesz el, a hibák keresése és javítása, amiért te a pénzed megkapod, de a munkaadódnak ez plusz kiadás

Mit tehetsz az ügy érdekében?

Tesztelj. Minden változtatáskor teszteld le, hogy amit csináltál, jó-e. Igen a teljes kódot, igen időigényes, ha kézzel csinálod, igen maradhat benne hiba. Ezért automatizáld a tesztelési folyamatot.

Szerencsére a TDD már a php programoknál is megszokott. Erre találtam is egy jó kis kiindulási alapot (Test Driven Development). Én is csak nem rég kezdtem el vele foglalkozni, nem volt elvárás, hogy fejlesszem a tudásom. Most ez egy új kihívás a számomra, mivel profivá szeretnék válni és persze jó programozóvá. Fejlődök, tanulok, gyakorlom a tanultakat.

A szoftver felépítésében okozott kár elkerülése

A profik tudják, hogy a felépítés kárára őrültség beépíteni egy új modult a programba. Ha feláldozod a programod felépítését, a jövődet áldozod fel. A kódodnak könnyen módosíthatónak, hatékonynak és átláthatónak kell lennie.

Képesnek kell lenned túlzott költségek nélkül változtatni a programon. Sok program van, ami pont emiatt bukik el a csatában. Az elején napokba, majd hetekbe, végül hónapokba telik, hogy a feladatot végrehajtsd, a munkáltató kétségbeesetten próbálja behozni a lemaradást, esetenként több programozót vesz fel, hogy ezzel gyorsuljon a munka. Ezzel pedig csak romlik a helyzet. Az új programozók máshogy gondolkodnak, a program szerkezetét tovább cincálják, és így még több kárt okoznak a programban és a projektben.

Sajnos azt kell mondjam, hogy eddig mindenhol ezt csináltuk. Előttem lévő programozó elkezdte a programot, én később csatlakoztam hozzá, majd saját ötletekkel, saját felépítéssel fejlesztettem a kódot, ezután kaptam egy társat, aki szintén máshogy alakította a programot. Ennek az lett a vége, hogy a program 2 percenként omlott össze. Ha profik lettünk volna, egységes szerkezetet tudtunk volna használni.

Persze lehetetlen mindig mindent az elejéről kezdeni. Így, a programodat rugalmassá kell tenned, hajlítgasd. Ha módosítani kell rajta, és rájössz, hogy a jelenlegi szerkezetben ez lehetetlen, akkor kicsit módosíts rajta, hogy könnyebb legyen belenyúlni. Állandóan formáld a programodat. Soha ne elégedj meg vele, ugyanúgy, ahogy a szobrász is addig faragja a követ, míg számára tökéletes nem lesz. Te is ezt tedd a programoddal. Változtasd, fejleszd folyamatosan.

Végszó

Kicsit hosszúra sikerült ez az írás, és még mindig lenne miről írni.

Mindig hangsúlyozom, hogy saját tapasztalatból beszélek. A fenti problémák mind igazak. Jelen pillanatban amatőrnek számítok, miért, mert a kódom átláthatatlan, egyre több idő javítani, ha hiba van a kódban "nem az én hibám". Persze ez függ a főnök hozzáállásától is. Mikor kijelented, hogy a program ennyit bír, mert nem tudod tovább kalapálni, így sem bírja és kellene rá 1-2 hónap, hogy rendbe szedd, ő kijelenti, hogy erre nincs idő, te vagy a szakember, oldd meg rövid idő alatt. Mit tudsz tenni? Kókányolsz. Tudod, hogy a következő módosítás kiütheti a rendszered. Tudod, hogy annyiszor volt már kókányolva a kódod, hogy egy apróságot is 8 helyen kell átírni. És ilyenkor adod fel.

Én egy ilyen után mondtam fel. Jött a főnök, hogy miért ülök már a kódon 3 órája, mikor ez egy öt perces feladat (elvileg tudott programozni). Próbáltam neki elmagyarázni, hogy amit kértek, felülírja a tegnapi kérést, de az új dolog bevezetéséhez is 4 fájlt kell módosítani, mert hatnak egymásra. Ekkor jött a válasz, ha nincs kész 5 percen belül, kirúg. Megcsináltam, még jobban szétbombáztam a kódot, majd másnap bementem és felmondtam.

Leoamros

X

Üdv! Ha még személyesen nem ismerjük egymást, Smajda László vagyok, de szólíts csak egyszerűen Laccának vagy Leoamrosnak. Olyan netbúvároknak osztom az észt, akik szárnyaikat próbálgatják a PHP, MySQL, JavaScript világában, és elakadnak valamelyik folyamat során. Főleg a saját tapasztalatokat írom le, ettől függetlenül kérdezhetsz bátran, lehetőségeimhez mérten válaszolok.

Kategóriák
Címkék
Social Media
Eszközök