A rossz szoftverfejlesztők ellen nincs recept

Rögzítés dáruma: 2023.01.27.

Ebben a podcast epizódban Charaf Hassannal, a Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Karának dékánjával és Mester Sándorral beszélgettünk szoftverachitektúráról és minőségről. 

Résztvevők

Mester Sándor - Moderátor Mester Sándor
Charaf Hassan - BME Villamosmérnöki és Informatikai kar dékán Charaf Hassan
Tresch András - Quattrosoft ügyvezető Tresch András

Összefoglaló

A szoftverarchitektúráról és szoftverminőségről beszélgettünk Mester Sándorral és Dr. Charaf Hassannal, a BME dékánjával.

A podcast elején a szoftverarchitektúra fontosságáról beszélgettünk. Hassan kiemelte, hogy a szoftveriparban mintákkal dolgozunk - ezek működőképes, bizonyított módszerek. A jó architekt két szempontja van: egyrészt fejlesztői, másrészt az üzleti. Lényeges tulajdonságai a nyitottság, kommunikációs készség, hibák elfogadása és korrigálása.

Beszéltünk arról, hogy nincs "okleveles architekt" szak - ez a pozíció tapasztalattal érhető el. Egyetértettem azzal, hogy egy fejlesztőből lehet architekt, de nem automatikusan - tapasztalatra, affinitásra, és problémamegoldó képességre van szükség. Az architektnek nem elég csak tervezni, szükség esetén forráskód szinten is tudnia kell segíteni.

Hassan bemutatta a szoftverfejlesztés evolúcióját a monolitikus megközelítéstől a microservice-ig:

  • A kezdeti monolit szoftverek nehezen karbantarthatók voltak
  • Az objektumorientált szemlélet jobban lokalizálta a hibákat
  • A komponens-orientált megközelítés (Corba, Com) szorosan összekapcsolt rendszereket hozott
  • A 2000-es évek elején jöttek a lazán csatolt webszolgáltatások
  • Jelenleg a microservice architektúra dominál

A microservice-ek kapcsán elmondtam a véleményemet, hogy nem szabad túlzásba vinni a szétdarabolást. Egyetértek azzal a megközelítéssel, hogy egy microservice az, amit egy 6-8 fős csapat tud fejleszteni, és nem célszerű minden egyes hívási pontot külön szolgáltatásként kezelni, mert ez kezelhetetlenné válik.

Hassan hangsúlyozta, hogy nincs konszenzus az architektúra világában, és a feladattól függ a megfelelő megközelítés. Kiemeltem a tranzakciókezelés fontosságát is - láttam példát arra, hogy ennek hiánya komoly problémákat okoz. Egy konkrét esetben 800 millió forintos fejlesztés után az első évi üzemeltetési költség 1 milliárd forint volt, mert 30-40 ember állandóan az adatbázist javítgatta.

Hassan azt mondta erre: "a rossz szoftverfejlesztők ellen nincs recept", de kiemelte, hogy megfelelő konténerizációval és middleware szolgáltatásokkal sok probléma megelőzhető. Hangsúlyozta az adatbázis védelmének fontosságát - aki éles adatbázisban közvetlenül SQL-t futtat, annak "a diplomáját vissza kell vonni".

A tesztelés témájában egyetértettünk abban, hogy az automatizált tesztek nélkülözhetetlenek. Elmondtam, hogy a fejlesztők általában nem szeretik a tesztelést, és sokszor a tesztelő cégek anyagilag érdekeltek abban, hogy ne automatizáljanak. Megosztottam egy példát, amikor 90 nap alatt sikerült automatizálni azt, amit korábban 10 ember csinált manuálisan.

Hassan hozzátette, hogy az architektnek tudnia kell, milyen minőségű szoftvert ad ki a kezéből, és a tesztlefedettség kritikus tényező. A fejlesztési módszertanok kapcsán az iteratív megközelítést emelte ki, ami segít a hibák korai felismerésében.

Az IT biztonság témáját Hassan hozta fel, mint egyre fontosabb tervezési szempontot. Náluk az egyetemen közös kurzusokat tartanak, ahol IT biztonsági szakemberek és szoftverfejlesztők együtt tanulnak "biztonságra tervezni".

Hassan megemlítette az új szempontokat az architektúra tervezésekor:

  • Energiahatékonyság (zöld szoftverek)
  • Teljesítmény és válaszidő
  • IT biztonság

Említettem, hogy a hardverek exponenciálisan fejlődtek, ami kényelmessé tette a fejlesztőket - "úgyis elbírja a vas" szemlélet terjedt el. Ez pazarláshoz vezetett, amit nehéz utólag orvosolni.

Hassan hozzátette, hogy az architektnek a teljesítményparamétereket is figyelembe kell vennie, és döntésképesnek kell lennie. "Egy rossz döntés az architekt esetében sokkal jobb, mint az, hogy áll, és ez a pánikot kelt a fejlesztők körében."

A gyorstalpaló fejlesztői képzésekkel kapcsolatban határozott véleményt fogalmaztunk meg. Egyetértettem Hassan álláspontjával, hogy a valódi szakértelem nem szerezhető meg 6 hónap alatt. Mint cégvezető, nem hiszem, hogy valaki, akinek sosem volt hobbija a programozás, 6 hónapos képzés után értelmesen hozzá tudna járulni komolyabb projektekhez.

Hassan kimondta: "Ezekben a csodákban nem hiszek. Ezek pótcselekvések." Kiemelte, hogy az informatikában szükség lenne a szerepek világos kategorizálására és a hozzájuk tartozó képzettség meghatározására.

A beszélgetés végén a szoftverfejlesztő partnerek kiválasztásáról beszélgettünk. Hassan a referenciák fontosságát emelte ki, és azt tanácsolta, hogy a megrendelők részéről legyen műszaki szakember, aki nyomon követi a fejlesztést.

Egyetértettem, hogy nem elég a papíralapú referencia, hanem ténylegesen meg kell nézni a korábbi munkákat és a fejlesztő csapatot is. Kihangsúlyoztam, hogy "nem nyilatkozat kell, ki kell menni, és meg kell nézni" - sajnos az utóbbi években ezt a megközelítést kevesen alkalmazzák, pedig sok félresiklott projektet meg lehetne így előzni.

Összefoglalva: a jó szoftverarchitektúra a tapasztalaton alapul, figyelembe veszi mind a technológiai, mind az üzleti szempontokat. Megfelelő teszteléssel, biztonsági megfontolásokkal és teljesítmény-optimalizálással párosítva stabil, megbízható rendszereket eredményez, amelyek nem csak működnek, hanem fenntarthatók és bővíthetők hosszú távon is.