Az elmúlt egy-két évben jelentős változást tapasztaltam a szoftverfejlesztés világában, különösen a pull requestek számának szokatlan növekedésében. Egy mérnökvezetőként, aki több mint egy tucatnyi emberből álló csapatot irányított, ebből a tapasztalatból született ez az összefoglaló.
A pull requestek számának robbanásszerű növekedése
Az egyik legszembetűnőbb változás az volt, hogy a pull requestek mennyisége az elmúlt időszakban rendkívüli módon megnőtt. Csapatomban több mint fele alvállalkozóként dolgozott, akik másodlagos mérnökként éjszaka és hétvégén, főállásuk után végezték munkájukat. Különösen a péntek estétől vasárnap estig tartó időszakban egyszerre hatalmas mennyiségű pull érkezett be.
Egyetlen alvállalkozó gyakran több tárolón (repository) is dolgozott párhuzamosan, így a hét végére gyakran eluralkodott rajtuk az érzés: „Hol is kezdjem?” A hétvégi napokon felgyülemlő több tucatnyi pull request teljesen megszokott jelenséggé vált.
A mikroservice architektúra és a merge folyamat bonyolultsága
Bár a termék mikroservice konfigurációra épül, maga az összeolvasztási (merge) folyamat korántsem mikro méretű. A valóságban az üzleti logika összetett, és átfogja az egyes szolgáltatásokat. Ha a merge-t kontextus nélkül hajtják végre, az egész rendszer integritása azonnal sérülhet.
Első pillantásra úgy tűnhet, hogy nő a termelékenység, hiszen több kód kerül be a rendszerbe rövidebb idő alatt. Azonban összességében a termék instabilabbá válik, ami hosszú távon komoly problémákat okozhat.
A pihenés hiánya és annak következményei
Ebben a helyzetben nehéz pihenni vagy szünetet tartani. Ha például szombat és vasárnap pull requestjeit nem ellenőrzik megfelelően, hétfő reggel könnyen előfordulhat, hogy valami elromlik valahol a rendszerben. Ez pedig egy olyan „struktúrát” eredményez, amely nem képes megállni vagy pihenni – mind menedzserek, mind fejlesztők számára.
Termelékenység vagy kontextusvesztés?
Kívülről nézve ezt akár „termelékenységnövekedésként” is lehet értelmezni. Valójában azonban egyre inkább nő a kontextusvesztés. A termelékenység nem pusztán arról szól, hogy gyorsabban írunk kódot; sokkal inkább azon múlik, hogy azok az emberek, akik értik a kontextust, képesek legyenek helyes döntéseket hozni és megfelelően összeolvasztani a változtatásokat.
Az AI szerepe és korlátai
Bár mesterséges intelligencia bizonyos területeken segíthet – például backend logika feldolgozásában –, korlátai is jól láthatóak. Különösen az UX és front-end fejlesztés területén, ahol „szemre” és „fülekre” van szükség, az AI még nem tudja teljes mértékben kiegészíteni az emberi érzékelést.
Az AI használatának növekedésével paradox módon gyakran csökken a termelékenység – ez az úgynevezett „fordított termelékenységi csapda”. Minél többet használjuk az AI-t, annál kevésbé érjük el azt a hatékonyságot, amit várnánk.
A nagyobb fejlesztési szervezetek speciális kihívásai
Ezek a problémák különösen akkor válnak nyilvánvalóvá, amikor egy fejlesztési szervezet túllép egy tucatnyi főnél nagyobb létszámot. Nem egyszerű prototípusokról vagy kisebb projektek kódjáról beszélünk ilyenkor, hanem olyan termékekről, amelyek már éles környezetben működnek és karbantartást igényelnek.
Már most is látható, hogy mind az AI, mind az emberek elérték kapacitásuk határait. Ennek ellenére nincs garancia arra, hogy ezek a termékek ne omoljanak össze időről időre.
Összegzés
- A pull requestek számának növekedése jelentős terhelést ró a fejlesztési folyamatokra.
- A mikroservice architektúra komplexitása megnehezíti az összeolvasztási műveletek biztonságos végrehajtását.
- A kontextusvesztés komoly veszélyt jelent a termék stabilitására nézve.
- Az AI támogatása hasznos lehet bizonyos területeken, de nem helyettesítheti teljesen az emberi érzékelést és döntéshozatalt.
- Nagyobb csapatok esetén ezek a problémák felerősödnek és komoly szervezeti kihívásokat jelentenek.
A jövőben kulcsfontosságú lesz megtalálni azt az egyensúlyt, amely lehetővé teszi a hatékony munkavégzést anélkül, hogy feláldoznánk a rendszer integritását vagy csapataink mentális egészségét.