A könyvtáros

Említettem, hogy a mi (programozási) feladatunk a webkiszolgáló szoftverének elkészítése, amihez nagyon sok támogatást kapunk (operációs rendszer, Java, Spring…). 

Külön, a szoftvernek is van a korábbi, rendszerarchitektúra részben tárgyalthoz hasonló felépítése (architektúrája), ami lehetővé teszi, hogy

• a szoftver ellássa a feladatát (funkcionális követelmények – ha a rendszer egy jegyfoglaló rendszer, akkor a szabad helyek lekérdezése a rendszer egyik funkciója),
• a megfelelő válaszidő betartása mellett (nemfunkcionális követelmények),
• úgy, hogy az lehetőleg kevés idő, energia (azaz pénz) ráfordításával karbantartható legyen

Mit jelent a karbantarthatóság? A fizikai világ tárgyai esetében a karbantartás a bekövetkező meghibásodások javítását, a különböző (kopó)alkatrészek cseréjét jelenti. Szoftverek esetében nem beszélhetünk kopóalkatrészekből vagy olyan részegységekről, amelyek a használat miatt előbb-utóbb elromlanak. Amit a szoftverben egyszer jól megírtunk, az nem romlik el. A szoftver esetében a karbantartás:

1. a korábban is meglévő, de eddig ki nem derült hibák javítását
2. a későbbi felhasználói igények miatti változtatások végrehajtását

jelenti.

A könnyebb karbantarthatóságot segíti egyrészt a különböző szintű automatikus tesztek megléte, valamint a program jó felépítése, olvashatósága.

Az automatikus tesztek olyan programok, amelyek futtatásuk közben azt ellenőrzik, hogy a „fő” program működése mennyire megfelelő. (Pl. olyan program, ami elindítja a böngészőt (ez lesz a „fő” program), és megpróbál megnyitni egy új fület, és aztán megnézi, hogy megnyílt-e az új fül).

Ha a „fő” programunk minden részére készítünk automatikus teszteket, akkor ha elindítjuk a tesztjeink összességét, és az hibátlanul végigfut, akkor biztosak lehetünk benne, hogy a szoftver jó.

(Ez az ideális állapot, ami nincs, mert a tesztekből is maradhatnak ki részek, azt is elhibázhatjuk, és a pénzügyi vezető is dönthet úgy, hogy a további tesztírások helyett másra koncentrálunk…)

Ha pedig a feladatunk a böngésző fejlesztése, és szeretnénk egy új menüpontot betenni egy nagyon szuper új funkcióval, akkor akár úgy is eljárhatunk, hogy előbb elkészítjük a teszteket a menüponthoz, utána megírjuk a menüpontot, majd lefuttatjuk az összes tesztet. Azért az összes tesztet, mert az új funkció fejlesztése közben bevihettünk új hibákat, ami valahol máshol okoz galibát. Ha az összes teszt jól lefut, akkor biztosak lehetünk abban, hogy semmi más olyat nem rontottunk el, amire már írtunk tesztet.

Az automatizált tesztek alkalmazásával magabiztosabban nyúlhatunk hozzá a szoftverhez.

A program jó felépítésével kapcsolatosan képzeljük el azt, hogy egy regényt vagy novellát írunk. Már majdnem készen vagyunk vele, amikor eszünkbe jut, hogy a drámai fordulat kedvéért a végkifejletben a főgonosz megragadja a főhősünk hosszú haját, és úgy vonszolja el, hogy kikösse az oszlophoz, ahol utána válogatott kínzásoknak veti alá. Csak a probléma az, hogy a főhősünk eddig a pillanatig rövid hajú volt… ráadásul számtalan alkalommal leírtuk a történet során, hogy így borzolja rövid haját vagy úgy. Ha a hajmegragadós drámai eseményt akarjuk, akkor bizony végig kell nézni a teljes történetet, mindenhol átírni az összes rövid hajas részt, mert ha bárhol is bennemarad, az probléma.

A szoftverekben is lehet „hajborzolós” probléma. Viszont ezek elkerülése részben könnyebb, részben nehezebb. Azért könnyebb, mert a programban lehet részeket hivatkozni. Ez esetben kb. úgy, hogy „{itt jön az, amit a főhős a hajával csinál}”, ami utána be tud helyettesítődni a borzolással, vagy azzal, hogy „megrázza a haját a szélben”, attól függően, hogy rövid hajat, vagy hosszút akarunk-e neki. Csak átírjuk azt, hogy az „{itt jön az, amit a főhős a hajával csinál}” éppen melyiket jelenti, és a megfelelő helyeken azt olvassuk majd.

… És azért nehezebb a programok esetében, mert sokkal több ilyen helyzet lehet. 

Sőt, az is előfordulhat, hogy a hajborzolásra gondoltunk, megoldottuk ezzel a behelyettesítős módszerrel, de a „tengerkék szemében megcsillan a nap” részt nem így oldottuk meg, abból továbbra sem lesz egyszerűen „éjfekete szemében eltűnik a nap fénye”… (Az informatikában van erre betűszó is: DRY, azaz Don’t Repeat Yourself, ne ismételd magad – azaz ha valamit két helyen használsz, akkor ne lemásold, hanem hivatkozd be az összes helyről a közös részt).

A program jó olvashatósága is nagyon fontos. A keretes részben leírtak szerint a szoftver forráskódja is egy szöveges dokumentum, amit a hozzáértők el tudnak olvasni. Ennek eredeti célja az, hogy a számítógépnek megmondjuk, hogy mit csináljon. Nem túl régen átalakult ez arra, hogy könnyebbé tegyük az utánunk következő programozó dolgát, hogy ha valamit módosítania kell, akkor azt lehetőleg minél könnyebben el tudja végezni. Jelenleg az a célunk a forráskóddal, hogy egy másik programozó számára kristálytisztává tegyük a céljainkat.

Lehet ezt jobban és rosszabban csinálni. Ha rosszabbul csináljuk, akkor az olyan, mintha egy fordulatos történetben minden szereplőt és minden helyszínt egy számmal vagy betűvel jelölnénk: „Az 18-as számú karakter belépett a G helyszínre, ahol találkozott a 25-ös és a 28-as számú szereplővel, majd együtt kinyitották a Zs tárgyat, amiből kiesett egy F, majd együtt átmentek az Y helyszínre.” Anélkül, hogy kijegyzetelnénk a történet korábbi részét egy lapra leírva, hogy ki kicsoda és mi mit jelent, nem nagyon értjük, és nem is élvezetes az olvasás.

 De ha úgy írjuk, hogy „Mr. Handsome belépett a könyvtárba, ahol találkozott Buddal és Terence-szel, majd együtt kinyitották az asztalon heverő könyvet, amiből kiesett egy arany könyvjelző, majd együtt átmentek a tárgyalóba.”, az sokkal jobban érthető, A Mr. Handsome utal is arra, hogy milyen attribútumai vannak ennek a szereplőnek.

A program jó olvashatóságára is vannak ajánlások: olyan szerkezetre vagy a részek elnevezésére vonatkozó javaslatok, amik betartásával javítható a program olvashatósága, ezáltal gyorsabb a megértése, gyorsabb a módosítások beépítése is. (SOLID-elvek, clean code elvek)

(És amúgy vicces, de az egyik ilyen jó tanács az, hogy ne úgy nevezd a szereplőket, hogy A, B, C, hanem írd bele a névbe, hogy mi a szerepe/fő jellemzője: Mr. Big, Mr. Small, Ms. Clever).

 Itt persze felmerülhet, hogy minek is foglalkozzunk a kód karbantarthatóságával, mert azt majd úgyis az AI fogja megírni. Amit jelenleg látni lehet, az az, hogy várhatóan programkódot olvasni továbbra is fog kelleni (mert az AI által generált megoldásokat meg kell érteni és ellenőrizni vagy javítani kell), ha pedig olvassuk, akkor már fontos az, hogy könnyen megértsük, akkor meg fontos az olvashatóság, illetve a módosítás miatt a karbantarthatóság. Ezekben pedig az AI jelenleg nem túl erős, sőt, olvastam egy-két cikket arról, hogy amióta AI megoldásokat használnak, romlik az új kódok minősége (azaz pl. karbantarthatósága, olvashatósága), ergo megint oda lyukadunk ki, hogy nemhogy kevésbé kell majd tudnunk a szakmánk fogásait, hanem még jobban, mint azelőtt. Ezt a készségszintű tudást pedig meg kell szerezni, ráadásul előzetes tudás nélkül még az interneten fenn lévő információk megszűrése, az információk kiválogatása is szinte lehetetlen. Milliónyi óra anyag van fenn az interneten, csak hát honnan tudod, hogy mi a jó? Ha nem ismered az alapokat, úgy jársz mint Rachel a Hálaadás desszerttel. (Jóbarátok, 6. évad, 9. epizód Friends: Rachel’s English Trifle (Clip) | TBS) 

Mi a tanfolyamainkkal már nagyon sok kompetens fejlesztőt adtunk a szakmának, akikkel elégedettek voltak a munkatársak, vezetők.