A kódkonvenciók (amelyek kódmásolás vagy másolás-beillesztéses programozás eredményei) hosszú távon veszélyt jelenthetnek a forráskód karbantarthatóságára. Elsőre ártalmatlannak tűnhetnek, de néhány fejlesztési iteráció után már károkat okozhatnak – pont akkor, amikor már túl késő a könnyű javításra. Ha egy hiba javítása vagy egy funkció fejlesztése során nem kezeljük együtt a klón példányokat, az nagy valószínűséggel a forráskód inkonzisztenciájához vezet.

A forráskód klónozása, más néven másolás és beillesztés alapú programozás komoly veszélyt jelent a szoftverrendszerekre, különösen azokra, amelyek még a megvalósítási fázisban vannak. A problémát gyakran figyelmen kívül hagyják, mivel az igazi veszély a klónok hosszú távú fennállásában rejlik, különösen a felügyelet nélküli fejlődésükben – emiatt a közvetlen negatív hatás nem érzékelhető. Ha egy adott metódus klónpéldányát karban kell tartani (például hibajavítás miatt), vagy tovább kell fejleszteni, akkor az esetek többségében ugyanezeket a feladatokat a többi klónpéldány esetében is el kell végezni a konzisztencia fenntartása érdekében.

A fejlesztési költségek becslése problémás feladat lehet. Számos olyan részlet van, amelyet figyelembe kell venni a számítás során, amelyek közül a legfontosabb valószínűleg a forráskód karbantarthatósága. A karbantarthatóság közvetlen hatással van a fejlesztési költségekre, hiszen minél kevésbé karbantartható a szoftverrendszer, annál több költségre van szükség a fejlesztéséhez.

A szoftver karbantarthatóságát befolyásoló tényezők

Dr. Vanya Ádám

Bevezetés

Előző blogbejegyzésünkben, melynek a címe „Mi a szoftver karbantarthatósága?”, bemutattuk a karbantarthatóság fogalmát, és érveltünk amellett, hogy ez egy olyan tulajdonság, amit irányítani szükséges. Az irányítás azonban csak akkor lehetséges, ha tudjuk, milyen tényezők hatnak rá. Ezen tényezők bemutatása a jelen blogbejegyzés célja. Ha ezeket a tényezőket mérjük és befolyásoljuk, a karbantarthatóság is irányíthatóvá válik.

A befolyásoló tényezők

Az, hogy egy szoftver mennyire könnyen módosítható, alapvetően két nagy tényezőtől függ: a módosítandó forráskód állapotától, illetve a módosítást végző fejlesztőktől. Először nézzük meg a forráskódot. A karbantartási folyamat során a fejlesztők elolvassák a kódot, hogy megértsék, hol és mit szükséges módosítani. Ez a legtöbbször azt jelenti, hogy más fejlesztők által írt kódot kell értelmezni. Ennek hatékonyságát számos forráskód tulajdonság befolyásolja. Egy jól strukturált szoftver, amely kis metódusokat tartalmaz és ezek metódusok kevés döntési pontot tartalmaznak, gyors és hatékony vizsgálatot tesz lehetővé. Ezzel szemben egy rosszul strukturált, hatalmas metódusokkal teletűzdelt monolit jelentősen lassítja a munkát. A forráskód elemzése után a fejlesztők bevezetik a szükséges módosításokat. Ebben a fázisban is meghatározó szerepet játszanak a forráskód jellemzői. Vegyünk például egy olyan helyzetet, ahol egy kódrészlet módosításával együtt egy másik, duplikált szakaszt is módosítani kell a konzisztens változtatás érdekében. Ez a többletmunka csökkenti a karbantartás hatékonyságát. Ráadásul az ilyen szituációk elkerülhetők lennének, ha nem lennének duplikációk: az azonos kódrészek többnyire kiszervezhetők külön metódusokba, amelyek több helyről is meghívhatók. Ha azonban ez elmarad, további problémák lépnek fel. Ha például a fejlesztő elfelejti az összes példányt módosítani, akkor inkonzisztens viselkedés jelenhet meg, hibákhoz vezetve. Ezek javítása többletidőt és extra karbantartási erőfeszítést igényel. Amikor a fejlesztő elkészül egy adott funkcionalitás megvalósításával, elérkezik az idő a tesztelésre. A megfelelő tesztelés lefedi a forráskód összes futási útvonalát, hogy minden lehetőség ellenőrzött legyen a követelmények szerint. Az, hogy egy kódrészlet mennyire tesztelhető és milyen mértékben, szorosan összefügg azzal, hogyan írták azt. A döntési pontok (mint például az if utasítások) növelik a lehetséges futási útvonalak számát. Azokra a metódusokra, amelyek sok döntési pontot tartalmaznak, sok teszteset írása szükséges, így azok tesztelése időigényes. Ebből fakad annak a veszélye, hogy időnyomás miatt csak a legfontosabb útvonalakat fedik le teszttel, és sok más kimarad, növelve annak kockázatát, hogy hibák kerüljenek éles környezetbe, ami elérhetőségi problémákhoz vagy nem kívánt viselkedéshez vezethet. Bizonyos esetekben, a kód felépítése miatt egyes részek nem is tesztelhetők egységként. Vegyünk például egy hosszú metódus fontos részét vagy egy beágyazott SQL utasítást. Az ilyen korlátokat elkerülendő, a metódusok legyenek rövidek, a beágyazott SQL-t pedig ha lehet, kerüljük. E szabályok figyelmen kívül hagyása teszteletlen részeket, kódduplikációt okoz a már korábban ismertetett kockázatokkal. A fent említett karbantartási tevékenységeket részletesebben is tárgyalja az ISO/IEC 14764:2022 szabvány, lásd [1]. A forráskód szintű tulajdonságokat (más néven metrikákat) Zou és Kontogiannis rendszerezetten írja le a [2] publikációban. Most nézzük meg a második fő tényezőt, a fejlesztőt. Ha ugyanazt a feladatot ugyanazon a kódon egy junior és egy senior fejlesztő hajtja végre, azok eltérő idő alatt fognak végezni. Ennek oka az, hogy a senior fejlesztő több szakmai tudással és tapasztalattal rendelkezik. Továbbá nagyobb eséllyel úgy módosítja a kódot, hogy az később könnyebben karbantartható legyen más fejlesztők számára is. A szaktudástól függetlenül, a fejlesztők rendelkeznek bizonyos szintű kognitív képességekkel is. Például: hány dolgot képesek egy időben fejben tartani. Az ilyen képességek hatással vannak arra, mennyi idő szükséges egy hosszú metódus megértéséhez, miközben azt fel-le görgetik a képernyőn. Azoknak a fejlesztőknek, akik kevesebb dolgot tudnak egyszerre fejben tartani, több időbe telik a kód értelmezése és módosítása. Akkor is, ha a fejlesztők rendelkeznek a szükséges képességekkel, hogy jól módosítható kódot írjanak, két további ok miatt ez mégsem mindig történik meg és a karbantarthatóság romlik. Az első ok a motiváció hiánya. Ahogy minden más ember, a fejlesztők is motivációval hajtják végre feladataikat. Egy tapasztalt, önmagára igényes fejlesztő belső motivációval bír, hogy jól strukturált kódot alkosson. Másoknak külső motivációra lehet szükségük: büntetések vagy jutalmak formájában. A büntetés lehet például bónusz csökkentése vagy elbocsátás, míg a jutalom lehet fizetésemelés, előléptetés vagy nagyobb elismerés. A második ok a lehetőség hiánya. Előfordulhat, hogy a fejlesztő képzett, motivált és tapasztalt, de nem kapja meg a szükséges erőforrásokat – például extrém időnyomás alá kerül. Ilyenkor szükségszerűen rövidít utakon halad. Mivel a funkcionalitás a legtöbb cég számára prioritást élvez, így kevesebb energia jut a karbantarthatóságra. Ez a gyors megoldás hosszútávon viszont többletmunkát eredményez, mert a kialakuló karbantarthatósági problémák kompenzálása sok időbe kerül. Nincs menekvés: a technikai adósságot vissza kell fizetni, kamatostul. A technikai adósság fogalmát Ward Cunningham vezette be [3]-ban, amely azóta egyre nagyobb figyelmet kap.

Összefoglalás és következtetések

A szoftver karbantarthatósága valamilyen módon hatással lesz rád. Ha szoftverfejlesztéssel foglalkozol, akkor a karbantarthatóság a karrieredre is jelentős hatással lehet, és ugyanúgy számít, ha egy software cégbe szeretnél befektetni, vagy saját testreszabott szoftvert vásárolsz. Ezért úgy gondoljuk, hogy a karbantarthatóságot meg kell érteni és tudatosan irányítani kell a céljaid elérése érdekében. Az irányítás segítésére ebben a bejegyzésben bemutattuk és megvitattuk a két legfontosabb tényezőt a szoftver karbantarthatóságát illetően: a forráskód állapotát és a fejlesztőket. Azt állítjuk, hogy a megfelelően megírt forráskód és a kellően képzett, kognitívan alkalmas, motivált és lehetőségekkel rendelkező fejlesztők nélkül nem lehet elfogadható szintű karbantarthatóságot elérni. Sorozatunk következő blogbejegyzése a karbantarthatóság lehetséges hatásait tárgyalja bővebben. Célunk ezekkel az írásokkal, hogy növeljük a szoftver karbantarthatóság kapcsán a tudatosságot, segítséget nyújtsunk a kontrollálásában, és elősegítsük a konstruktív párbeszéd kialakulását. Amennyiben e bejegyzés tartalmával kapcsolatban bármilyen észrevételed, kritikai megjegyzésed van, vagy úgy érzed, valamilyen módon tovább lehetne bővíteni, kérlek, vedd fel velünk a kapcsolatot és oszd meg ötleteidet: [email protected]

Hivatkozások [1] ISO/IEC 14764 (2022). ISO/IEC 14764:2022, Szoftvertechnika – Szoftveréletciklus-folyamatok – Karbantartás [2] Zou, Y., & Kontogiannis, K. (2002). Migration to object oriented platforms: a state transformation approach. International Conference on Software Maintenance, 2002. Proceedings., 530–539. [3] Cunningham, W. (1992, December). The WyCash portfolio management system. In Addendum to the proceedings on Object-oriented programming systems, languages, and applications (Addendum) (pp. 29-30).

A forráskódminőség-biztosítással kapcsolatos szolgáltatásainkról az alábbi kiadványból tudhat meg többet.

Ebben az esettanulmányban bemutatjuk, hogyan határozta meg a nemzetközi piacon jelen lévő szoftverfejlesztő cég, a Qualysoft egy szoftverprojekt jövőbeli fejlesztési és fenntartási költségeit a QualityGate használatával.

Az alábbi esettanulmány bemutatja, hogyan nyújt a QualityGate egy objektív, fontos minőségi jellemzőt, amelyet korábban ritkán számoltak. Ez a jellemző segíti az ügyfelet abban, hogy az igényeinek leginkább megfelelő fejlesztőcéget válassza. Az esettanulmány azt is bemutatja, hogyan befolyásolta az ügyfél döntését ez az újonnan bevezetett jellemző. Ajánljuk mindenkinek, aki úgy gondolja, hogy a legjobb fejlesztők kiválasztása kulcsfontosságú.

A következő esettanulmány bemutatja, hogyan vezették be a QualityGate forráskód elemző és menedzsment rendszert egy banki környezetbe SLA mérőeszközként – valamint a telepítési folyamatot és a bevezetés, illetve a pilot időszak legfontosabb tapasztalatait.

Ebben az esettanulmányban bemutatjuk, hogyan határozta meg a nemzetközi piacon jelenlévő szoftverfejlesztő cég, a Qualysoft, egy szoftverprojekt jövőbeli fejlesztési és karbantartási költségeit a QualityGate használatával.

Az Apache – Shardingsphere-elasticjob GitHub projekt (https://github.com/apache/shardingsphere-elasticjob/tree/master) 2020. május 28-án vált az Apache ShardingSphere alprojektjévé. Rugalmas ütemezés, erőforrás-kezelés és feladatkezelés funkciói révén olyan elosztott ütemezési megoldást kínál, amely alkalmas internetes környezetekben való használatra, és nyílt architektúrájának köszönhetően sokrétű feladatökoszisztémát biztosít. Minden projekthez egységes feladat API-t használ. A fejlesztőknek csak egyszer kell kódolniuk, és tetszőlegesen telepíthetik azt.

Az Iluwatar – Java Design Patterns GitHub projekt egy Java tervezési minták implementációit tartalmazó kódbázist biztosít. Az implementációkat tapasztalt programozók és architektok fejlesztették a nyílt forráskódú közösségből. A forráskód példák programozási oktatóanyagként szolgálnak arra, hogyan valósítsunk meg egy adott mintát. A tervezési minták implementációja mellett ez a nyílt forráskódú projekt szöveges leírásokkal is segíti a fejlesztőket a minták megértésében.

A TechEmpower – FrameworkBenchmarks GitHub projekt reprezentatív teljesítménymutatókat biztosít a webalkalmazás-keretrendszerek széles körében. A projekt jelenleg számos nyelven írt keretrendszert tartalmaz, beleértve a Go, Python, Java, Ruby, PHP, C#, F#, Clojure, Groovy, Dart, JavaScript, Erlang, Haskell, Scala, Perl, Lua, C és más nyelveket. A jelenlegi tesztek lefedik a szöveges válaszokat, a JSON szerializációt, az adatbázis olvasási és írási műveleteket az objektum-relációs leképezőn (ORM) keresztül, a gyűjteményeket, a rendezést, a szerveroldali sablonokat és az XSS elleni védekezést.

A CTrip – XPipe GitHub projekt (https://github.com/ctripcorp/x-pipe/tree/master) Redis több adatközpont közötti replikációkezelést biztosít. Megvalósítja az alacsony késleltetésű, magas rendelkezésre állású Redis több adatközpont közötti replikációt, valamint egygombos gépterem-átkapcsolást, replikációfigyelést és rendellenességi riasztásokat kínál.

Ez a nyílt forráskódú GitHub projekt több mint 1400 csillaggal (amely azt jelzi, hányan kedvelik ezt a projektet), valamint több mint 432 fork-kal (amely azt mutatja, milyen gyakran használták a kódbázist) rendelkezik.

A Google – Auto GitHub projekt (https://github.com/google/auto/tree/master) Java-hoz készült forráskód-generátorok gyűjteményét kínálja. Egy Java-megvalósítás gyakran tele van mechanikus, ismétlődő, általában nem tesztelt kódokkal, amelyek néha finom hibák forrásai lehetnek. Az Auto alprojektek olyan kódegenerátorok gyűjteményei, amelyek automatizálják ezen kódok hibamentes létrehozását.

Az Alibaba – Sentinel GitHub projekt (https://github.com/alibaba/Sentinel/tree/master) hatékony forgalomszabályozást biztosít a disztribuált rendszerek szolgáltatásai közötti megbízhatóság növeléséhez. A „forgalmat” tekinti kiindulási pontnak, és több területet lefed, beleértve a forgalomszabályozást, párhuzamosság korlátozását, áramkörmegszakítást és adaptív rendszervédelmet, hogy garantálja a mikroszolgáltatások megbízhatóságát. Ennek a nyílt forráskódú GitHub projektnek a népszerűségét több mint 16200 csillag (jelzi hány ember kedveli a projektet) és több mint 5600 fork (jelzi hányszor használták fel a kódbázist) mutatja.

Akár egy szoftvercég tulajdonosa, vezetője vagy fejlesztője vagy, a rövid és hosszú távú szakmai céljaid elérésének sikere nagymértékben függ attól, hogy a fejlesztett szoftver mennyire karbantartható.

Mivel a szoftver karbantarthatóság egy ilyen jelentőségteljes fogalom, erősen hisszük, hogy mindenkinek tiszta képe kell legyen arról, hogy pontosan mit jelent, mely tényezők befolyásolják, és hogyan hat a kitűzött célokra. Ahhoz, hogy minimalizálni lehessen egy rosszul karbantartható rendszer negatív hatásait, tudni kell annak aktuális karbantarthatósági szintjét, értékelni kell, hogy ez a szint elegendő-e, és meg kell tenni a szükséges korrekciós lépéseket.

Egy blogsorozat keretében szeretnénk minden releváns információval ellátni a szoftver karbantarthatóságáról, amely szükséges annak megértéséhez és ellenőrzéséhez. Ez az első blogbejegyzés bevezetést nyújt a szoftver karbantarthatóság témájába.

Remélhetőleg az olvasó az előző blogbejegyzések alapján meggyőződött arról, hogy a szoftver karbantarthatósága egy releváns téma, amely gondos figyelmet és cselekvést igényel. Korábbi, „A szoftver karbantarthatóságának javítása” című bejegyzésünkben azokra a lépésekre összpontosítottunk, amelyek révén növelhető a szoftver karbantarthatósági szintje. E lépések végrehajtása jelentős erőfeszítést igényel. Ennek a blogbejegyzésnek a fő témája az, hogy mire kell gondolnunk, amikor ezekbe a befektetésekbe kezdünk.

A kódsorok száma az egyik legvitatottabb forráskód-metrika a szoftvermérnöki gyakorlatban. Viszonylag könnyen kiszámítható, érthető és különböző érdekelt felek által sokféle célra felhasználható – ezért ez a leggyakrabban alkalmazott mérőszám a szoftverbecslésben, minőségbiztosításban és sok más területen. Ugyanakkor a metrika definíciója és számítási módszerei nagy változatosságot mutatnak, ami megnehezíti, hogy fontos döntések alapjául szolgáljon. Ezen túlmenően vannak esetek, amikor használata erősen megkérdőjelezhető – például a programozók közvetlen termelékenységének értékelése esetén.

Előző blogbejegyzésünkben, amelynek címe „A szoftver karbantarthatóságának megfelelő szintje” volt, megvizsgáltuk azokat a különböző megközelítéseket, amelyek segítségével meghatározható, mikor elegendő a karbantarthatóság szintje. Amennyiben ez a szint még nem került elérésre, intézkedéseket kell hozni. A szoftver karbantarthatóságának közvetlen és közvetett méréseinek eredményei alapján eldönthető, hogy érdemes-e beruházni a karbantarthatóság javításába. Ez a blogbejegyzés bemutatja, hogyan lehet ezt megvalósítani.

Előző blogbejegyzésünkben, amelynek címe „A szoftver karbantarthatóságát befolyásoló tényezők” volt, elemeztük a karbantarthatóságra ható főbb tényezőket. Ez segített felsorolni azokat a dolgokat, amelyeket figyelemmel kísérhetünk és megváltoztathatunk a kontroll érdekében. Annak érdekében, hogy megfelelően megértsük az ilyen jellegű kontroll fontosságát, tudnunk kell, hogy a szoftver karbantarthatóságának szintje mit és hogyan befolyásol. Ez a blogbejegyzésünk témája.

Előző blogbejegyzésünkben, amelynek címe „A szoftver fenntarthatóságának mérése” volt, elmagyaráztuk, miért fontos mérni a szoftverrendszerek fenntarthatóságát, és hogyan lehet ezt megtenni. A mérési eredmények alapján azonban további kérdések merülnek fel. Például: Elegendő-e a mért fenntarthatósági szint? Milyen fenntarthatósági szintet kellene célul kitűzni? Mennyire van távol a mért szint a kitűzött céltól? Mikorra szeretnénk elérni a kívánt fenntarthatósági szintet? Az ilyen jellegű kérdések megválaszolása kulcsfontosságú, mivel az ezekre adott válaszok határozzák meg, milyen döntéseket és intézkedéseket kell hozni a fenntarthatóság megfelelő irányításához. Ha érdeklik a válaszok, kérjük, olvassa tovább ezt a blogbejegyzést.

Előző blogbejegyzésünkben, amelynek címe „A szoftver karbantarthatóságának hatásai” volt, áttekintettük, hogy a karbantarthatóság milyen lehetséges hatásokkal bírhat. Ahhoz, hogy kezelni tudjuk ezek tényleges következményeit, képesnek kell lennünk magát a karbantarthatóságot is kontrollálni. Ez döntéshozatalt és minden támogató lépés végrehajtását igényli. A döntéshozatali folyamat lehet megérzésen vagy tényeken alapuló. Ebben a blogbejegyzésben azt tanuljuk meg, hogyan lehet mérni a szoftverrendszerek karbantarthatóságát annak érdekében, hogy megalapozott és megbízható döntésekhez szükséges tényeket nyerjünk ki.

Előző blogbejegyzésünkben, amelynek címe „A szoftver karbantarthatóságának hatásai” volt, áttekintettük, hogy a karbantarthatóság milyen tényezőkre lehet hatással. A tényleges következmények kezelése érdekében képesnek kell lennünk magát a karbantarthatóságot is kontrollálni. Ehhez döntéshozatalra és az azt támogató intézkedések végrehajtására van szükség. A döntéshozatali folyamat lehet megérzéseken vagy tényeken alapuló. Ebben a bejegyzésben azt vizsgáljuk meg, hogyan mérhető a szoftverrendszerek karbantarthatósága annak érdekében, hogy megbízható és jól megalapozott döntéseket hozhassunk.

Előző blogbejegyzésünkben, melynek címe „Mi a szoftver karbantarthatósága?” volt, bemutattuk a szoftver karbantarthatóságának fogalmát, és érveltünk amellett, hogy ezt fontos kézben tartani. A szükséges ellenőrzési lépések végrehajtása csak akkor lehetséges, ha ismerjük a befolyásoló tényezőket. Ezeknek a tényezőknek a bemutatása jelen blogbejegyzés témája. E tényezők figyelésével és befolyásolásával a szoftver karbantarthatósága szabályozható.

A szoftver karbantarthatóságának hatásai

szerző: Ádám Vanya

Előző blogbejegyzésünkben, amelynek címe „A szoftver karbantarthatóságát befolyásoló tényezők” volt, elemeztük azokat a főbb tényezőket, amelyek hatással vannak a szoftverek karbantarthatóságára. Ez segített abban, hogy felsoroljuk azokat a dolgokat, amelyeket figyelemmel kísérhetünk és megváltoztathatunk annak érdekében, hogy ellenőrzésünk alatt tartsuk őket. Ahhoz azonban, hogy megfelelően megértsük e kontroll jelentőségét, tudnunk kell, hogy a szoftver karbantarthatósági szintje mit és hogyan befolyásol. Ezt a témát vizsgáljuk meg ebben a blogbejegyzésben.