Jó pap holtáig tanul, a jó programozó pedig a következő Unhandled Exception-ig, tartja az ősi dakota közmondás. A napokban visszatekintettem 1-2 projektemre, és rá kellett döbbennem, hogy bizony baromira túltervezettek lettek. Mi is ez? Hogyan estem ebbe a csapdába? Milyen veszélyeket rejt? Hogyan kerülhetjük el?
Mi a túltervezettség?
Túltervezettségről, angolul over-engineering, akkor beszélünk, ha valamilyen eszköz bőven az elvárt követelményeken túl teljesít, teszi mindezt teljesen feleslegesen.
Ilyen lehet egy híd, ami a szabványokban meghatározott paramétereknél jóval nagyobb terhelést is elbír. Bár nagy valószínűséggel az elkövetkező 50 évben nem jelentkezik rajta akkora terhelés, mint amekkorára méretezték. Értelemszerűen a hídba került építőanyag nagyon megdrágította az építkezést, miközben a számtalan speciális megoldása miatt a karbantartása nehézkesebb, mint hagyományosabb társaié.
Fagner Brack a túltervezett kódot úgy jellemzi, mint a kód, ami olyan problémádat oldja meg, ami valójában nincs is. A fenti híd-analógiát folytatva, ilyenkor lényegében olyan képzeletbeli, jövőbeni problémák megoldását implementálod a kódodba, amiket senki nem kért.
A megoldás bár lehet, hogy tökéletes lesz, mégis elnyújtja a fejlesztés idejét, és felesleges komplexitást visz a rendszerbe. Gyakori, hogy az ilyen kódok, olyan szinten absztraktak, hogy a készítőjén kívül senki sem érti a pontos működésüket, éppen ezért nem is mernek hozzányúlni hibajavítás vagy fejlesztés céljából.
De túltervezett lehet egy szoftver vagy weboldal akkor is, ha olyan funkciókat építesz bele, amiket az ügyfél nem kért, de te ezekről mégis úgy gondolod, hogy milyen jól fog jönni neki. Aztán persze hamar kiderül, hogy soha életében nem fogja használni.
Hogyan estem ebbe a csapdába?
Mindig is volt egy olyan tervem, hogy szeretnék egy webshop motort összehozni, amit bármikor, bármelyik megrendelő számára feltelepíthetek, és hogy az majd milyen jó lesz a sok-sok funkcióval. El is kezdtem egy ilyenen dolgozni, de ilyen webshopos megkeresések végül nem igazán akartak beesni. Ezért a mindig beeső kisebb weboldalak mögé húztam fel ezt a webshopos lázálmot, és úgy fejlesztgettem folyamatosan. Tudjátok, mögé raktam az adminisztrációs felületet, kvázi az volt a webshop lelke, a látogatók által nézhető részt meg személyre szabtam. Ez így ment megbízóról, megbízóra, projektről, projektre.
Aztán rá kellett jönnöm, hogy igazából teljesen feleslegesen, hiszen mindig volt valami egyedi igény, az egyiknek nem kellett annyira szofisztikált nyitvatartási idő, a másiknál nem kellett a megrendelésekkel bajlódni, mert csak ajánlatkérés volt az oldalon. A harmadiknál nem kellett annyira részletes jogosultság kezelés. Arról nem is beszélve, hogy teljesen eltérő termékeket kellett árulni, így különböző tulajdonságokat kellett rögzíteni bennük.
Mégis lefejlesztettem ezeket, sok-sok munkaórával, és most ott tartunk, hogy sokkal egyszerűbben is kivitelezhető lett volna ugyanez az eredmény, ha eleve különálló munkaként állok ezekhez, nem pedig úgy, hogy ezeken keresztülgörgetem a webshop motor fejlesztésemet.
Beleestem abba a hibába, hogy úgy gondoltam, hogy most aztán megírom a tuti kódot, és technológiailag nagyon az élen fogok járni ezzel. Olyan kódot fogok írni amire sokáig büszke lehetek. Nem mértem fel megfelelően a képességeimet, és a tudásomat, aminek az lett a vége, hogy bár szépen indult a projekt, a végére mindenféle shortcutokat, hackeket és túlbonyolított megoldásokat alkalmaztam.
Így utólag már látom, hogy hol követtem el a hibát, és ebből mindenképpen tanulok.
Milyen veszélyeket rejt a túltervezettség?
Felesleges komplexitás a kódban
Ahogy fentebb említettem ilyen veszély lehet az, hogy olyan szinten elvont és általános a megoldás, hogy a készítőjén kívül senki sem érti a pontos működését. Ezzel feleslegesen megnövelve a komplexitást, lassítva a tesztelést, fejlesztést és hibajavítást. Ráadásul, ha a készítő otthagyja a céget, senki sem fogja érteni az adott kódrészlet működését. Mivel azonban túl általános a megoldás, ezért az egész rendszerbe mélyen beágyazódott. Komolyabb refaktorálás és tesztelés nélkül egyszerűen már nem lehet eltávolítani a kódbázisból.
Sebezhetőség
A felesleges, nem használt funkciók mindig hibalehetőségeket és sebezhetőségeket rejtenek magukban. Hiszen ezek nincsenek fókuszban sem a felhasználók sem a programozók által. Éppen ezért elég, ha valaki rátalál erre az elfeledett funkcióra, mondjuk egy menüpontra, amiben olyan súlyos biztonsági rés tátong, hogy a teljes rendszer felett átveheti az uralmat. Nyilván túlzásnak tűnhet, de elég ha csak azon keresztül hibás adatok kerülnek be az adatbázisba, amelyek elrontanak mondjuk egy pénzügyi jelentést. Valószínűleg a pénzügynél nem fognak pezsgőt bontani a hiba hallatán.
Megnövekedett fejlesztési idő
Értelemszerűen a feleslegesen beépített új funkciók, a túlságosan általános , vagy a jövő problémáit megoldó megoldások mind-mind növelik a fejlesztési időt. Eközben az üzletileg fontos funkciók elől azonban veszik el az erőforrást. A megnövekedett fejlesztési idő, megnövekedett költségeket is jelent, amit az üzlet vagy a megrendelő nem biztos, hogy jó néven vesz.
Hogyan kerülhetjük el a túltervezettséget?
Néhány egyszerű szabály betartásával könnyen elejét vehetjük a túltervezettségnek. Ha saját projekten dolgozol, addig ne kezdj bele egy új funkcióba, míg az előző nincs kész! Érdemes átgondolni a pontos működést, ha kell Trello-ban vagy egyéb helyen vezesd fel az egyes funkciókat és aszerint haladj! Így biztosan nem lesz semmi kihagyva, és nem fogsz semmi olyat belefejleszteni amit nem kell.
Kicsit olyan ez, mint a bevásárló lista. Bizonyított tény, hogy bevásárló lista nélkül többet költünk a boltban, és olyan dolgokat is megvásárolunk, amiket nem lenne szükséges. Itt is erről van szó: a feladatlista segít abban, hogy lásd mit csinálsz éppen, mi a következő lépés. Előbb vagy utóbb a végére fogsz érni.
Nem kell feltalálni újra a kereket! Ha hiszed, ha nem, kevés az olyan probléma amibe mások már nem futottak bele, és ne lenne rá kész megoldás. Érdemes átgondolni és szétnézni a neten, hogy milyen kész könyvtárak, szoftverek vannak a problémádra. Elképzelhető, hogy programozás nélkül is meg tudod oldani a felmerült problémákat.
Fókuszáljunk az adott problémára, és ne feltétlenül merüljünk el az esetlegesen felbukkanó jövőbeni problémák tengerében. Természetesen nem probléma, ha ezek felmerülnek, de először gondolkodjunk és utána programozzunk. Nézzük meg, hogy az a probléma mennyire lehet reális? Érdemes-e egyáltalán foglalkozni vele?
Egy nagyon egyszerű példa a túltervezettségre: van egy adatbázis táblád, amiben terméktípusok vannak, ezeknek van egy azonosítója és egy neve. Az azonosító mezőre azért állítasz integert, mert mi van, ha majd a jövőben annyi terméktípus lesz, hogy nem fog beleférni mondjuk a tinyint-be? Aztán persze kiderül, hogy a megrendelő, jó ha 10 terméktípust használ.
Ha úgy érezzük, hogy egy megoldásunk nem elegáns, túlburjánoznak benne a paraméterek és az if-ek, akkor lépjünk egyet hátra, lassítsunk le és nézzük meg, hogy az a megoldásunk tényleg jó-e. Ha úgy látjuk, hogy nem a megfelelő megoldást találtuk meg, akkor refaktoráljunk bátran.
Természetesen időnként mind beleesünk ebbe a hibába, sajnos én is, ennek apropóján született a bejegyzés, de törekednünk kell arra, hogy ennek tudatában legyünk, és tegyünk ellene. A hiba felismerése, már egy lépés a tanulás és az újabb hibák megelőzésének irányába.