Ma már egy egyszerű Hello World alkalmazás is jóval komplexebb mint annak idején volt. Nem maga az alkalmazás, hanem a köré szervezett környezet miatt. Jóval többet várunk el ugyanis egy fejlesztői környezettől, mint tettük ezt annak idején. Pontosan mik is ezek, mire kell készülnünk, ha egy új nyelvet, technológiát vagy technológián belül egy másik keretrendszert választunk? Erről szól ez a bejegyzés.

Réges régen, egy messzi-messzi galaxisban

Emlékszem gyerekként mennyire magába szippantott, amikor beírtam és futtattam az első programomat. Hihetetlenül gyors volt a feedback, az instant sikerélmény. Nem kellett napokat reszelgetnem, ragaszgatnom, pályát építenem mint amikor kisvasutazni akar az ember, vagy edzenem, gyakorolnom ha valamilyen sporttevékenységről volt szó. Csak beírtam, hogy:

10 PRINT "Hello Világ"
RUN

És ment. Azóta is ez az első amit egy új programozási nyelv elsajátításakor kipróbálok. A “Hello Világ” ugyanis nagyon jó arra, hogy a legalapabb programfejlesztési lépés jóságát, vagyis a fejlesztői környezet működését teszteljük. Azt a lépést, ami nélkül a programozás értelmetlen időtöltés csak csupán. Ugyanis ez a teszt tájékoztat arról, hogy a környezet amit használok, képes értelmezni az általam leírtakat (szintaktikai elemzés), azt képes lefordítani a gép nyelvére (fordítás vagy értelmezés) és képes azt az adott környezetben futtatni. Ez azonban a mai korban már nem elég.

Coding standards avagy Kódolási szabályok

Ma már nem egyedül kódolunk, hanem szinte mindig valamilyen csapatban. Azt szoktam mondani, hogy ha egyedül is kódolsz akkor is ott van egy szörnyen idegesítő csapattárs, akinek a kódjait majd túrnod kell, és szörnyülködni fogsz, hogy milyen béna megoldásokat használt. Ez a csapattárs pedig nem lesz más, mint Te egy fél évvel ezelőtt. Szóval, ha engem kérdezel, akkor mindig készülj fel a csapatmunkára.

Mindenképpen érdemes már az elején lefektetni kódolási szabályokat, amik betartásához érdemes valamilyen eszközt is használnod. Ez lehet a fejlesztői környezet (IDE) megfelelő beállítása. Minimum jelezze a hibákat, de a legjobb az, ha a megfelelő tagolást automatikusan segíti. Nagy segítséget jelent egy-egy ellenőrző eszköz használata, ilyen pl. a PHPCS, PHPStan PHP-ban vagy az Eslint a Node.js-ben. Ma már azonban minden modern integrált fejlesztői környezetben lehetőségünk van arra, hogy a megfelelő kódolási szabály ellenőrzését beállítsuk és a bevitel során támogatást kapjunk, hogy egyből jól formázott legyen a kódunk.

De nem csak a jól formázott kódot érdemes ellenőrizni. Vannak olyan statikus kódelemző eszközök, amelyekkel sebezhetőségi pontokat lehet találni, vagy tipikus hibás kódszervezés fedhető fel. Fontos eszköz lehet még valamilyen metrika gyűjtő eszköz is, ami egyfajta jelző lehet arra, ha nagyon nem jó irányba menne a fejlesztés. Talán az egyik legjobb statikus kódelemző eszköz a SonarQube(https://www.sonarqube.org/), mellyel azon túl, hogy az előbbieket képes nagyon szép grafikus formában is megjeleníteni, még egy fejlesztői napban mért technikai adósság értéket is ki tud nekünk írni.

Kódkiegészítés

Az is jól tud jönni, ha a fejlesztői környezet automatikusan kiegészíti a különböző azonosítónkat vagy ajánlásokat fogalmaz meg a lehetőségekről. Ezt statikus nyelveknél könnyedén megteszi a szerkesztőnk, de az olyan szkriptnyelven írt medzsikhalom esetében mint pl. a Laravel, már csak külön eszköz segítségével fogja tudni megtenni (https://github.com/barryvdh/laravel-ide-helper). Ez az eszköz pl. egy sehol nem használt fájlt generál, amibe belír számos sehol nem használt osztályt, ami aztán segíti a kódkiegészítést, mivel az IDE nem tudja, hogy ezt a fájlt sehol nem használjuk. Vannak olyan rendszerek, ahol még ez sincsen. Például, a Drupal rendszer által generált Entity-k mezőinek elérésére már nincs jól használható automatikus kiegészítő megoldás.

Automata tesztek futtatása

Efkettő-efkilenc-kontrolefkilenc, még ma is emlékszem erre a kombinációra. Ez nem valami játék örökélet kódja, hanem a mentés, fordítás, futtatás hármasé. Ha programoztál a Turbo C/C++/PASCAL/Assembly/stb segítségével, akkor ezeket használtuk. Ma már nem ezt teszem, hanem - pár nehezen tesztelhető dolgon kívül - mindig automata teszteket írok, és azokat futtatom elsősorban. Tehát maga a rendszer amit összerakok, az képes arra, hogy futtassa a tesztjeimet.

Debug avagy nyomkövetés

Valamikor nagyon régen még a Basic-es időkben, amikor még gyerek voltam, aztán később a korai JavaScript korában kellett úgy fejleszteni, hogy fejben nyomkövettük a kódot. Ezt csak bizonyos komplexitás alatt lehetséges hatékonyan kivitelezni. Ezért van az, hogy ma már elengedhetetlen, hogy egy fejlesztés során hatékony nyomkövető rendszerünk legyen. Tudjuk melyik sorban mi történik a változókkal, milyen az alkalmazásunk állapota és mi miért történik pontosan. Ez egy PHP-s alkalmazásnál külön érdekes, ahol a weben keresztül, vagy parancssorban is futtatni kell az alkalmazást adott esetben más-más értelmezők segítségével.

Profilozás, code coverage, monitorozás, mérés és logolás

Ha igazán professzionális fejlesztésben gondolkodunk, akkor már a fejlesztés során is monitorozzuk az alkalmazásunkat. Nézzük milyen felhasználói esetek milyen futási idővel és erőforrás felhasználásával futnak, mik azok a függvények ahol sok időt tölt el az alkalmazás és azt is ki tudjuk deríteni az összegyűjtött információkkal, hogy miért. Ezeket az információkat azután nem csak a teljesítmény hangoláshoz, optimalizáláshoz tudjuk felhasználni, hanem arra is, hogy megnézzük, hogy a tesztjeink a kód mely részeit fedik le. Mik azok a kódrészletek amikre teszteket kell még írnunk vagy mik azok a kódrészletek amiket nyugodtan törölhetünk.

Continuous Delivery, Deployment és Integration avagy folyamatos szállítás, telepítés és integráció

Ma már az első pillanattól kezdve folyamatosan szeretünk szállítani, ami azt jelenti, hogy a projekt elejétől fogva rendelkezésünkre áll az a dev, teszt és éles környezet, ahol az alkalmazásnak működnie kell, ahol a tesztek futnak, ahol a méréseket el lehet végezni és gyűlnek a profilozáshoz szükséges adatok. Gyakori kis lépésekben, folyamatosan járjuk végig az alkalmazás szállításának teljes folyamatát beleértve az előbbi környezetekre való telepítést. Természetesen mindezt automatán, mindenféle humán beavatkozás nélkül, hisz máshogy ez elképzelhetetlen lenne. Tudjuk, hogy minderre azért van szükség, mert minél előbb megtalálunk egy hibát annál olcsóbb lesz azt javítani, korrigálni. Hiba alatt az alkalmazás egészét értjük, ami magába foglalja a kódot és annak függőségeit valamint a kódot futtató infrastruktúrát is. Igen ez azt jelenti, hogy ha nálam működött, de a teszt vagy éles rendszeren nem, akkor is mielőbb javítom a hibát én mint fejlesztő és nem csinálok belőle MVP-t, vagyis más valaki problémáját.

Összefoglalás

Ma már nem csak az általunk fejlesztett alkalmazások lesznek komplexek, hanem a fejlesztéshez szükséges környezet is. Ha a fentiek közül valamit nem használsz, akkor azt meg kell tanulni, be kell vezetni a cégbe vagyis megtanítani a kollégáknak és automatizálni. Ez utóbbi talán a legnehezebb, de egyben a legfontosabb lépés is, hisz ettől lesz igazán használható a rendszered.

Ha nem szeretnéd a nulláról kezdeni és segítségre vágysz, vagy egy közösség tagja akarsz lenni, ahol az ezirányú tapasztalataidat megoszthatod, javaslom jelentkezz a Konténerizált Fejlesztői Környezet kialakítása képzésemre, ahol ezeket a témákat fogjuk körüljárni.

A felhasznált fotót Lukas Kloeppel készítette és a Pexels oldalról töltöttem le.