Amikor egy idő után atomtudós kell az alkalmazás üzemeltetéséhez.

Amikor egy idő után atomtudós kell az alkalmazás üzemeltetéséhez.

Üzleti alkalmazások fejlesztésénél hajlamosak vagyunk beleesni abba a csapdába, hogy minden megoldás azonnal kell, mindegy bármi áron. És vannak fejlesztők, akik elég ötletesek ahhoz, hogy minden kérésre tudnak megoldást adni. Ez így rövid távon nagyon win-win (az ügyfél megkapja amit akar, a fejlesztő pénztárcája pedig vastag lesz), ám hosszú távon gondok lépnek fel, az alkalmazást egyre nehezebb üzemeltetni és továbbfejleszteni.

Nyilván ez általános probléma a szoftverfejlesztés teljes spektrumában, valahogy mégis MS technológián alapuló fejlesztéseknél láttam igazán látványos meghökkenéseket.

Ahhoz nem kell MS technológia, hogy valaki rossz kódot írjon. Rossz kódot bármilyen nyelven, bármilyen eszközzel lehet írni. A kód-cowboy-ok bárhol képesek spagetti kódot írni, a dokumentáltság és a konvenciók teljes mellőzésével. Csakhogy úgy egyébként a játéktér (mármint amin belül garázdálkodni lehet) eléggé limitált.

Ha webes alkalmazást írunk (mondjuk PHP-ban), akkor sokféle eszköz áll a rendelkezésünkre, de ezek mind a web szerveren belül vannak. Ha nem működik az alkalmazás, akkor elég webes területen belül szétnézni, mert a hiba forrása ott lesz. Ha telepíteni kell az alkalmazást, akkor csak vinni kell azokat a fájlokat, konfigurálni a web szervert, és kész.

Ezzel szemben amikor MS alkalmazást írunk, akkor nem csak a web szerveren és/vagy az adatbázison belül dolgozunk, hanem egy komplett ökoszisztémával dolgozunk (operációs rendszer). Például registry bejegyzéseket módosítunk, Scheduled Tasks segítségségével futtatunk programokat, a web szerveren keresztül hívunk meg OS szinten telepített programokat. (Például a felhasználó elküld egy formulát, a web szerver szerver oldalon létrehoz egy Excel példányt, kiszámolja a formulát, és visszaadja a web oldalon az eredményt)

Ezzel gyakorlatilag olyan függőségek alakulnak ki, amiket átlagos fejlesztő nem fog tudni egyszerűen átlátni. Természetesen egy idő után igen, de az új fejlesztő kinevelési költsége az egekbe fog kúszni.

Másrészt pedig ha hiba lép fel az alkalmazásban (például az Excel-es példában a kérdéses web oldal az 1. lépésben elszáll), akkor az átlagos rendszermérnök nem fogja tudni azt megoldani. Mert az átlagos rendszermérnök megnézi a webszervert (OK működik), az oprendszert (az is OK), és innentől kezdve nem érti.

Egy idő után a fejlesztő úgy fogja érezni, hogy egyszerűbb ha ő maga javít hibákat és ő telepít, mert sokkal hosszabb leírni/elmagyarázni mintha maga csinálná. És ezután az a szoftver nem lesz karbantartható. A fejlesztő előbb-utóbb úgyis elmegy a cégtől, vagy kinevezik valahová, és összeomlik a rendszer.

Miért van ez így?
Habár a Microsoftot említettem a címben, alapvetően nem ők okozzák ezeket  a problémákat, hanem azok a fejlesztők, akik túlságosan zseniális megoldásokat találnak ki.
Mert amikor megoldás kell, és valakinek van egy „ötlete”, akkor senki nem fogadja el a „túlságosan bonyolult” vagy „nem szabványos” ellenérveket.

Aztán eltelik 5 év, 3-4 fejlesztő, és az alkalmazás telepítéséhez 10 DLL-t és 30 registry változtatást kell vinni, de igazából senki sem tudja mi hogy működik, csak ha valami nem jó akkor visszakövetik a kódban hogy ki kit próbál meghívni.

Igazából senki sem kényszeríti a fejlesztőket, hogy átláthatatlan, fenntarthatatlan kódot írjanak. A lehetőség ott van, és egy képzett Microsoft-os fejlesztő nagyobb kárt tud okozni, mint egy JAVA-s, mainframe-es vagy adatbázisos kollégája. Valahogy az ilyen jellegű problémák nagyobb eséllyel fordulnak elő MS alkalmazásoknál.

Pedig a határvonalakat a Microsoft is meghúzta. A C# például kimondottan arra törekszik, hogy átlátható legyen a kód és az, hogy milyen eszközöket használunk. De persze lehet trükközni, hiszen vannak esetek, amikor nincs más mint közvetlenül a biztonságos környezeten kívülre merészkedni. (Most nem is említem azt az esetet, amikor az oprendszer vagy a fejlesztőeszköz „known issue”-ja miatt kell egy workaround-ot villantani)

A jó fejlesztői környezet, a sok dokumentáció és a RAD-os támogatás nagyon jó – hiszen csökkenti a fejlesztésre fordítani időt, hamarabb lesz megoldás, stb stb. Viszont ezáltal túlságosan a time-to-market-re helyeződik a hangsúly a minőség helyett. Ha könnyű programot írni, akkor jönnek a szakmunkás kódvetők, akik kezében a rendszer kalapács lesz, és mindent szögnek néznek.

Van valami jó abban, hogy az MS-es fejlesztők olcsóbbak a többieknél, mert biztosan fogunk találni elég embert ha MS fejlesztést indítunk. De a drága JAVA-s fejlesztők valahogy hozzák a minőséget és kevésbé hajlamosak az öngyilkos kódolásra. Valahogy jó lenne a kettőt ötvözni és kialakítani a gyors, de fenntartható szoftverfejlesztés irányelveit.

Ugyanis amikor ezen módszerek és eszközök alapelveit meghatározták, akkor még megszokott volt a sűrű verzióváltás, a max 4 évig élő szoftver. Manapság már 10+ évről beszélünk. Valami különös ok miatt az IT ipar nem követi az ügyfeleket, és a múltban él. A múlt nem fog visszatérni. Ez itt az új norma.