Egy ma olvasott bejegyzés adta az apropóját ennek a cikknek. Ahogy a technológiai híreket böngésztem, szembejött egy írás a rossz szoftvertervezés klasszikus tüneteiről. Elgondolkodtatott: egy olyan korszakban, ahol az AI már szinte magától írja a kódot, vajon ezek a régi “szagok” eltűnnek, vagy éppen ellenkezőleg – csak még gyorsabban termeljük őket?
A szoftverfejlesztés új korszakba lépett. Az AI-alapú segédekkel (GitHub Copilot, Cursor) a kódírás fizikai része nagyságrendekkel gyorsabb lett. Amire régen órák kellettek, az ma másodpercek műve. Van azonban egy bökkenő: az AI kódot generál, de nem rendszert tervez.
Hiába készül el a kód rekordidő alatt, ha a mögöttes architektúra hibás, ugyanúgy “legacy” kódot gyártunk – csak éppen ipari mennyiségben és fénysebességgel. A szoftvertervezés továbbra is a mi felelősségünk. Nézzük azt a 7 intő jelet, ami arra utal, hogy a gyorsaság a minőség rovására ment.
1. Merevség (Rigidity) – A kártyavár-effektus
A merev szoftver olyan, mint egy kártyavár: ha egy ponton hozzáérsz, az egész megmozdul. A merevség jele, ha egy apró változtatáshoz rengeteg kapcsolódó modult is módosítanod kell.
- AI-kockázat: Az AI gyakran generál olyan kódokat, amik lokálisan működnek, de szorosan “bele vannak drótozva” a környezetükbe. Ha nem figyelsz a laza kapcsolatra (loose coupling), a rendszered egy betonömbé válik.
2. Törékenység (Fragility) – A váratlan dominó
A törékenység az, amikor megjavítod a bejelentkezési modult, és hirtelen elromlik a számlázás. Olyan részek hibásodnak meg, amiknek logikailag semmi közük a módosításhoz.
- A tünet: Megrendül a bizalom a kódban. A fejlesztők minden release előtt rettegnek, hogy mi fog “elszállni”.
3. Mozdíthatatlanság (Immobility) – Az újrahasznosítás halála
Akkor beszélünk erről, ha egy funkciót szeretnél egy másik projektben is használni, de az annyira összefonódott a jelenlegi környezetével, hogy egyszerűbb újraírni az egészet.
- Tanulság: Az AI imádja a specifikus megoldásokat. Ha nem instruálod kifejezetten generikus kódra, akkor eldobható, egyszer használatos modulokat fogsz kapni.
4. Viszkozitás (Viscosity) – A szoftver ellenállása
Ez az ellenállás, amivel a rendszer a helyes irányba történő fejlesztéssel szemben fellép. Ha sokkal könnyebb egy “hack”-et alkalmazni, mint követni az eredeti tervezési elveket, a rendszer viszkózus. A bonyolult környezet (lassú tesztek, nehézkes deploy) szintén ebbe az irányba tolja a fejlesztőt.
5. Szükségtelen összetettség (Needless Complexity)
Ezt hívjuk túltervezésnek (over-engineering). Megjelenik a “hátha kelleni fog még” mentalitás, és olyan absztrakciós rétegek épülnek be, amikre jelenleg semmi szükség.
YAGNI elv: You Ain’t Gonna Need It – Ne írj meg semmit előre, amire nincs most szükséged, mert csak a zajt növeled vele.
6. Szükségtelen ismétlés (Needless Repetition)
A Copy-Paste a leggyorsabb módszernek tűnhet, de a rossz design jele. Ha ugyanaz a logika több helyen is szerepel apró módosításokkal, a hibajavítás rémálommá válik: egy bugot 5 különböző fájlban kell majd átírnod.
7. Átláthatatlanság (Opacity)
Az átláthatatlan kód nehezen érthető, nem fejezi ki világosan a fejlesztő szándékát. Az AI gyakran generál “túl okos” vagy tömör megoldásokat, amik elsőre működnek, de emberi szemmel (vagy egy hónap múlva) olvashatatlanok.
Te vagy a pilóta, az AI csak a hajtómű
Az AI-val való fejlesztés olyan, mintha egy szuperszonikus repülőt vezetnél: elképesztő sebességre vagy képes, de ha rossz az irány, sokkal hamarabb ütközöl falnak.
A szoftvertervezés alapelvei – mint a SOLID vagy a KISS – nem váltak elavulttá. Sőt, most fontosabbak, mint valaha. A kódírás ígérete a gyorsaság, de a tervezés a garancia arra, hogy a szoftvered jövőre is működni fog.