A Programozás Világa fejlesztés programming szoftver IT enginieer tool

Fejlesztés idegen szerveren, avagy ha a kőműves más szerszámát használja!?

2020-06-09

Az idegen szerverre való fejlesztés nagyjából hasonló effektuson alapul, mint amikor a kőműves mester, más szerszámával építi fel a házat… Nézzük, hogy a szoftverfejlesztés területén milyen nehézségeket okozhat ez a helyzet.

Talán nem árulok el nagy titkot azzal, ha azt mondom, hogy akár egy 7 számjegyből álló szoftveres fejlesztés során a megrendelő, akkor érez kellemetlenséget, ha a fejlesztő csapat ragaszkodik a saját tárhelyes környezetéhez és „szerszámaihoz” éves 10 ezer forintos plusz költségért.

Ennek alapvető oka az, hogy a megrendelői szféra tévesen értelmezi a programozásban használt szerszámokat, munkaasztalokat, mérőeszközöket és még számos olyan berendezést, ami egy stabilan megírt szoftverhez szükséges és amivel a kivitelező rugalmasan tud haladni. 
Sajnos a szoftverfejlesztési területnek van egy rossz pszichológiája, hiszen a megrendelő a produktumot nem tudja a kezébe venni, nem tudja megtapogatni, és számos olyan dolgot nem tud megtenni vele, ami azt az életérzést kelti, amit egy áruház polcáról levett termék megadhat.

A szoftver talán olyasmi lehet, mint a telefonban a hang, vagy a Petőfi rádió befogásához szükséges rádióhullám. Azaz kicsit megfoghatatlan…

Mi is az a szoftver?

A szoftver egy olyan adathalmaz sokaságából álló eredmény, ami előre megírt, hajszálpontos lépésekből áll, logikai ellentmondások nélkül. Egy szoftvert több 10.000 soros programkódból, akár sok millió karakterből álló produktum. Egy szoftveren belül egyetlen karakter hiánya vagy egy helytelenül leírt szó, már végzetes hibát eredményezhet. Lásd példaként: https://www.kovacsmuvekkft.hu/blog-napi-gondolatok/Meglevo-PDF-re-tanusitvany-elhelyezese-letoltheto-forraskoddal

Mi is az a szerver?

A szerver egy olyan számítógép, ami a célszoftver üzemeltetéséhez szükséges. A programkódok 0-ák és 1-esek sorozatában számos rétegen haladnak keresztül, hogy a produktum fusson. Ha a programmal csak annyit szeretnénk megcsináltatni, hogy számolja ki az 1+1 értékét, akkor az értelmezéshez a programsoroknak keresztül kell mennie elektronikai áramkörök logikai sokaságán, operációs rendszer értelmezésén, programnyelvet értelmező rendszeren és az összes réteg konfigurációs beállításain és még sok minden máson.

Mi is az a konfigurációs beállítás?

Függetlenül attól, hogy az Ön számítógépén lévő Windows pont olyan mint a szomszédé, a szoftvereknek van egy testreszabhatóságuk.

Nézzünk erre egy nagyon egyszerű példát: az Ön számítógépén lévő háttérkép, a számítógép márkája, processzora, mikrofonjának engedélyezése, fiókjának neve minden bizonnyal más, mint a szomszédé. Ez nincs másképp a szerverkonfigurációkkal kapcsolatban sem és a helyzetet még tovább rontja a bank szintű biztonsági elvárás, miszerint a szerver konfigurációs beállítást csak az ismerheti 100%-ban, aki a szerverszoftvereket gyártotta, 90%-ban aki a szervert konfigurálta,~50%-ban, aki a fejlesztő és ~0.0001%-ban a szoftvert használó. Ezen számok roppant fontosak a biztonsági követelmények betartása céljából.

Tehát, kezdjük érteni, hogy miért is nem jó más szerszámaival házat építeni. De nézzük, hogy mi a különbség egy fúrógép és pl. egy levélküldő szerver beállítása között.

A fúrógépen van 3 sebességállás, 2 fúrási típus és 1 fordulatirány szabályzó és fontos, hogy ezek a kapcsolók egymástól függetlenül működnek.

Egy levélküldő szerverre való fejlesztés során pontosan szükséges ismerni a levélküldő szerver típusát, aminek konfigurációs beállítása akár 500 db kapcsolóból is állhat. Sok esetben kapcsolónként akár 15 db váltási típusból és rengeteg esetben a kapcsoló egymástól függésétől. A szakember a kapcsolókat sokszor súlypontozás alapján kezeli vagy újabb technológiák bevezetésével, biztonsági frissítések következtében, sokszor részben vagy teljes egészében újra konfigurálja. A levélküldő magprogram kapcsolatban áll külső szolgáltatókkal is. Hiszen a levélküldésnél vírusellenőrzés is történhet valamint a címzett emailcímének SPAM elővizsgálata is megtörténhet. Szükséges továbbá a levél formátumának vizsgálata, a mellékletek átvilágítása stb… Egy „jól” bekonfigurált szervernél a levélküldés esetén az ügyfél csak annyit lát, hogy a levél elment a címzettnek és nem többet.

A szoftverfejlesztés során miért fontos a megfelelő konfiguráció?

Most már ismerjük, hogy milyen összefüggés van a fúró és levélküldő között, még mindig nem esett szó arról, hogy a szoftver konfigurációjára miért van szükség.

Ha valami életszerűbb dologhoz kellene hasonlítani, akkor nagyjából olyan lehet, mint a fúrószár típusa, fúrás szöge és a fúrandó lyuk mélysége.

Ez a programozás során sincs másképp, hiszen ha a megbízó részére egy levélküldés esetén indokolt a levél naplózása, levél feladó címének autentikálása, levelek titkosítása, máris eljutunk oda, hogy exponenciálisan növekvő mennyiségben kell használni a „szerszámokat” és ezek konfigurációs beállítása is szükséges. Mivel egy külső fejlesztő normál esetben mondjuk csak 50%-ban ismeri a szervert, ez nagyjából olyan, mintha a lyukat fúró mester nem látná, hogy milyen fúró szárat használ. Beletörik, kicsorbul, elkopik, elég a vídia, nagyobb lesz a lyuk, mint a tipli és még sok-sok problémával szembesülhet. Ez a szoftverfejlesztésnél sincs másképp.

De a fejlesztő miért nem kérdezi meg az üzemeltetőt, hogy mi a beállítás?

Ez egy nagyon jogosan feltett kérdés, nézzük a válaszokat:

  1. Ha a rendszergazda megfelelő biztonságot követ, akkor minimum kötelezi a fejlesztőt a titoktartásra egy nyilatkozattal, aminek az átfutási ideje 1-2 nap. Ez a fejlesztés során időkiesést jelent és így tolódnak feladatok.
  2. A rendszergazda ideje is pénz, amit az információ kiadására fordít. Sok esetben ez az idő, nem konvertálható át pénzé, tehát az egyeztetést teljesen jogosan a kedvtelenség követi, amit a fejlesztőnek kell „lezongoráznia” a rendszergazdával.
  3. Rengeteg esetben nagyon nehéz megtalálni azt a mezsgyét, hogy a fejlesztő mikor tegye fel a kérdést vagy mikor jusson el oda, hogy alternatív megoldást keres. Ennek a helyzetkezelésére nem létezik bejáratott logika, hiszen eleve nincs kettő ugyan olyan feladat.
  4. Ha a fejlesztő felhívja telefonon a rendszergazdát, mert „csak egy kérdés”, nem csak kizökkenti a rendszergazdát a pillanatnyi munkájából, hanem a rendszergazda elsődlegesen próbákra ösztönzi a fejlesztőt. Ez fejlesztési szempontból is időrablás és időkiesés.
  5. Ha a probléma nem oldódna meg, valószínűleg a szervergazda oda fog eljutni, hogy „Bocs, nálam a hiba!”.

Teljesen véletlenszerűen kiválasztottunk egy egyszerűnek mondható weboldalt, hogy néhány tényszámmal is szolgáljunk:

A rendszer:

~ 2004 db fájlból áll
~ 35 db szerverszoftvert használ
~ 1.200 db konfigurációs beállításból a megfelelők kiválasztása
~ 3 db technológia szolgáltatóból áll
~ 7.300 db parancskezelési lehetőség
~ 5 db belső szerződés szükséges az üzemeltetéshez
~ 20 db napi automatizált feladat fut

És ebből az ügyfél annyit lát, hogy a weboldal betöltődik.

Végszóként!

Mindig kérdezze meg a fejlesztőt a szerver adta lehetőségekről, felmerülő költségekről, utánajárás vagy harmadik féllel való egyeztetésről. Egy rendszer üzemeltetés szempontjából elengedhetetlen tudni, hogy a konfigurációs beállítások sokszor közösek, a szabályok felrúgása pedig a rendszerüzemeltető részéről, akár jogi következményekkel is járhat. Tehát, a szoftverfejlesztés messze sem annyiból áll, hogy beverünk egy szöget a falba és felakasztjuk a képet. Rengeteg technológia közül kell megválasztani a megfelelőt, rengeteg beállítás vonatkozik a szoftverre és ezeket a beállításokat mindig felelősségteljesen szükséges a fejlesztőnek elvégeznie, megfelelő felelősségvállalással.

írta: Kovács Ernő