Pár száz soros szoftvert bárki tud tervezni, de mi a helyzet a több százezer soros rendszerekkel? Egy nagy rendszer felépítésekor és karbantartásakor teljesen új kihívásokkal kell szembenéznie a fejlesztőnek. Új elvekre van szükség, amelyeket nem tanítanak az egyetemen, de ezen múlik a szoftver sorsa: az, hogy egy életképtelen katyvasz vagy egy brilliáns mestermű válik belőle.

Íme pár szempont, amelyet célszerű figyelembe venni a nagy rendszerek fejlesztésekor:

1. Technológiák számának minimalizálása

2. Más gyártókkal való kapcsolatok minimalizálása

3. Komponensek függéseinek minimalizálása

4. Egységes felület

5. Általános funkcionalitás

6. Következetes és előrelátó kódolás

1. Technológiák számának minimalizálása

A technológiák összekapcsolása csábító dolog, mert megmutathatja a fejlesztő, milyen sok mindenhez ért. De mindegyiket ugyanolyan mélységben ismeri? A gondok akkor kezdődnek, amikor valamely alaprendszer frissítését követően nem az elvárt módon viselkedik, és ki kell deríteni a hiba okát. A különböző technológiák eleve különböző hibakezelést alkalmaznak, amelyek nehezen kapcsolhatók össze. Ráadásul minden technológiának vannak gyenge pontjai, és amikor ezek találkoznak, váratlan dolgok történnek: a problémák hirtelen megsokszorozódnak. Ezért ajánlott azt az egy technológiát használni, amelyben a legjobbak vagyunk, és minimálisra csökkenteni más technológiák alkalmazását.

A különböző technológiák különböző fejlesztőeszközöket és tesztelőeszközöket igényelnek, eltérő alaprendszert, és a programozás során más gondolkodásmódot. Ha a program egyes részeit Java-ban más részeit C#-ban megint más részét PHP-ban írjuk meg, és MySQL szervert használunk az adatok tárolására, nem csak magunkkal szúrunk ki, hanem a felhasználókkal is, ami végső soron egy életképtelen terméket eredményez. Ki az, aki szívesen használna egy olyan programot, amihez Java keretrendszert, Apache szervert és MySQL kiszolgálót is kell telepíteni és karbantartani? Mindegyik egy külön világot alkot. Helyette használjunk egyetlen alaprendszert, amit jól ismerünk.

A kód hordozhatósága szempontjából kritikus szempont, hogy az új fejlesztő irányába, aki átveszi a fejlesztést, ne legyen elvárás, hogy egy sor teljesen különböző programozási nyelvet ismerjen, hiszen mekkora az esélye, hogy találunk olyan programozót, aki pont azt az 5 nyelvet és 3 fejlesztőkörnyezetet ismeri, amire szükség van? Ha pedig nem találunk, mennyi pénzünkbe kerül a betanítása? Helyette használjunk egy programozási nyelvet és egy fejlesztőkörnyezetet.

2. Más gyártókkal való kapcsolatok minimalizálása

Szoftvereink és más gyártók szoftverei közötti kapcsolatok karbantartása nekünk hosszú távon egyre több és több plusz munkát, az ügyfelek számára pedig bosszúságot és anyagi veszteséget okoz, ami hosszú távon lehetetlenné teheti a szofverünk karbantartását és veszteségessé teheti a vállalkozásunkat. Ezért célszerű nem összeszűrni az adatokat idegen szoftverekkel, és nemet mondani az ügyfelek ilyen irányú kéréseinek. Gondolkodjunk hosszú távon és gondoljunk a felhasználók többségére. Sosem tudhatjuk, hogy a másik gyártó mikor változtat a rendszerén. Hacsak nem kötünk együttműködési szerződést, semmi sem kötelezi arra, hogy beszámoljon jövőbeli terveiről. A külső függőségek a legéletképesebb szoftver fejlesztését is képesek megbénítani.

Tegyük fel, hogy mi egy számlázó szoftvert fejlesztünk, és megkeres egy ügyfél, hogy részben finanszírozná a rendszerünk összekapcsolását egy másik gyártó által forgalmazott webshop-al. Egy ilyen kérést nehéz visszautasítani, hiszen ezáltal egyrészt megtarthatunk egy ügyfelet, másrészt újabb funkcióval bővül a rendszerünk, újabb ügyfeleket csalogatva. Kiszámoljuk, hogy mennyi időbe telne elkészíteni a megfelelő interfész-t, és pár hónap alatt lefejlesztjük. Az ügyfél elégedett, mi pedig reménykedünk, hogy megtérül a befektetés.

Hamarosan szembesülünk vele, hogy a partner cég szoftverének hiába van több ezer felhasználója, nehéz őket elérni és keveseknek van szükségük a mi rendszerünkre. A ráfordított marketigköltség éppen hogy csak visszajön, de a befektetett mérnökórák még mindig nem térültek meg. Eltelik fél év, és egyszer csak felhív minket több ügyfél, hogy nem működik megfelelően a kapcsolat a két program között. Kiderül, hogy teljesen újraírták a szoftverüket, és változtattak az interfészen. Épp egy újabb határidős projekten dolgozunk, de a munkát meg kell szakítanunk, mert több ügyfelünk nem tud dolgozni, minden óra késlekedés veszteséget okoz a számukra, követelik, hogy javítsuk ki a hibát. Egy hétbe kerül hozzáigazítani szoftverünket a változásokhoz, ami időbeli és így anyagi veszteséget okoz. A hasonló buktatókat érdemes figyelembe venni, ha alkalmazásunkat új interfészekkel tervezzük bővíteni.

3. Komponensek függéseinek minimalizálása

Talán ez az egyik legfontosabb szabály. E nélkül a programunk életképtelen lesz három okból is: egy modularitás nélküli kód fejlesztése gyötrelmes, tesztelése időigényes, és ami a legijesztőbb: használata során a felhasználók a legváratlanabb hibákkal szembesülnek a legváratlanabb helyzetekben.

Az első nagyobb szoftver, amit írtam, egy zsákutca volt. Ormótlan, fejlődésképtelen, kódok kusza halmaza. Egy rémálom volt fejleszteni, és a legapróbb módosítások is katasztrofális hibákat generáltak. Mint később kiderült, ennek az volt a fő oka, hogy a logikailag elkülönülő komponenseket ezernyi eldugott szál kapcsolta össze, és a hibák szabadon gyűrűztek ezeken a szálakon keresztül szerteszét a program legtávolabbi részeibe. Egyetlen kis hiba a program bármely részében galibát okozhatott, és ennek az lett a következménye, hogy a munkaidőm egyre nagyobb részét kellett hibakereséssel töltenem és egyre kevesebb idő jutott a továbbfejlesztésre. Ez volt az egyik legnagyobb lecke, amit kaptam. Eldöntöttem, hogy újratervezem az egészet. Egy évet csak tervezéssel töltöttem, megalkotva egy nagy mértékben moduláris rendszert, amely végül megalapozta a vállalkozásom sikerességét.

4. Egységes felület

A moduláris felépítés természetes módon segíti a munka cégen belüli felosztását és ennek köszönhetően a csapat miden tagja a saját egyéniségére formálhatja a saját modulját. Biztosan ezt akarjuk? A használhatóság szempontjából kritikus elvárás, hogy a modulok felülete és kezelése egységes legyen. Ha a rekord szerkesztés ikon minden modulban másképp néz ki és máshol helyezkedik el, a felhasználónak minden ikon képét és helyzetét memorizálnia kell, ami megnöveli a tanulási folyamatot és a felhasználók nagyobb eséllyel választják egy másik gyártó termékét, aki egységesebb felületet biztosít.

A felületet tehát kisebb funkcionális egységekre kell tördelni, olyan módon, hogy minden modulban ugyanazokat a felületelemeket és -csoportokat használjuk a hasonló funkciókhoz. Szoftverfejlesztési szempontból sem utolsó szempont az azonos felületek egységes módon történő megvalósítása, hiszen rengeteg munka spórolható meg a redundancia felszámolásával, és a fejlesztőknek is könnyebb lesz átlátni a kódot. A funkciók és felületek hierarchiába szervezése minimalizálja a kódismétléseket, könnyen újrafelhasználhatóvá teszi a kódot és rugalmassá a rendszert. Az egységes felépítésre egy jó példa a Joomla tartalomkezelő rendszer adminisztrációs felülete.

5. Általános funkcionalitás

Ha a rendszer specifikusságát nézzük, két szélsőséges eset létezik: lehet a szoftver teljesen egyedi, statikusan egyetlen cég igényeire szabva, vagy lehet teljesen általános, egyénre szabható. Hogy ki hol helyezi el a termékét a skálán, nagyon nem mindegy, és hosszútávon meghatározza a termék életét. A kérdés egyszerűen megfogalmazható: olyan terméket szeretnénk, amit néhány cég használ és nagyon drága, vagy olyat, amelyet sokan használnak és olcsó.

A kérdés sok szemszögből megközelíthető. Egy jó szoftver jogi és szakmai értelemben is egy műalkotás, felbecsülhetetlen eszmei értékkel bír és a használatával megtermelhető profit óriási gazdasági potenciált rejt magában. Kinek jó az, ha csak egy cég használhatja? Személy szerint szakmailag a legnagyobb bűnnek tartom azt, ha egy szoftvertermék gyártója bekorlátozza a termék használatát, elérhetetlenné teszi a termékét mások számára.

Akárhogy nézzük, teljesen egyedi szoftvert fejleszteni, egy teljességgel etikátlan és rossz lépés. Miért? A szoftver kifejlesztésének és karbantartásának a teljes költségét egyetlen megrendelőnek kell állnia, ami komoly összeget jelent, még egy nagyvállalat számára is. A szoftverben rejlő profitlehetőségek pedig kiaknázatlanok maradnak, hiszen csak egy cég profitál a termékből. De más hátrányok is léteznek. Mivel kevesen használják, a szoftver tele lesz rejtett hibákkal, és a gátlástalan módosítgatás következtében (a felhasználónak korlátlan hatalma van a funkciók felett) a kód kusza és átláthatatlanná válik. Végül a fejlesztő feladja és továbbál, a cég pedig még évekig szenved vele, mert nincs aki karbantartsa a rendszert. Végül keresnek egy másik fejesztőt, akit megkérnek, hogy fejlesszen egy új rendszer, és újra kezdődik az egész rémálom előről.

Ezzel szemben egy kellően általános és testreszabható "dobozos szoftver" kiküszöböli az imént felsorolt problémákat: nagyobb kezdeti befektetést igényel, de a kifejlesztés díja eloszlik a felhasználók között, miközben a használatából nagyon sokan profitálnak. A következő táblázatban összefoglalom a két megközelítés jellemzőit:

	Egyedi szoftver	Általános szoftver
Ár:	Magas	Alacsony
Felhasználók száma:	Kevés	Sok
A termék gazdasági haszna:	Alacsony	Magas
Hibák száma:	Magas	Alacsony
Testreszabható:	Nem	Igen

6. Következetes és előrelátó kódolás

Robert C. Martin Tiszta kód c. könyve alapmű, amelyet minden kódolónak többször is el kellene olvasnia. A szabályok vak követése azonban hasonlóan használhatatlan kódot eredményezhet, mintha kizárólag az intuíciónkra hallgatnánk. A szabályokat intelligens módon kell alkalmazni, a szabályalkotó szándéka a fontosabb, nem a konkrét képlet.

A lényeg, hogy következetesen és előrelátóan építsük fel a kódot: a hasonlóan működő részeket hasonló módon kódoljuk le, hogy ha valamikor a jövőben a kód egyszerűsítésére vagy újraírására kerül sor, minnél kevesebb dolgunk legyen. Nem baj, ha kezdetben nem látjuk át, hogyan általánosítható az aktuális probléma, könnyítsük meg a jövőbeli munkánkat azzal, hogy egységes módon oldjuk meg minden előfordulását.

 

• Szoftverfejlesztés

• Előző
• Következő

Kategória: Általános