Még pár hónapja olvastam egy cikket valahol. A lényege a következő volt: adott két kód, X és Y.
X valahány kódsorból áll, és – természetszerűleg – tartalmaz is valamennyi hibát. Y sokkal több kódsorból áll, mint X. Ha feltételezzük, hogy az egy kódsorra eső hibák száma hasonló (remélhetőleg sokkal kisebb, mint 1 J), akkor statisztikai alapon azt várhatjuk, hogy Y sokkal több hibát fog tartalmazni, mint X. Mi ebből a tanulság?
Minél kevesebb kódot írunk, annál kevesebb hiba lesz a programban.
Miután ezt így elolvastam, egy jót röhögtem magamban: itt egy újabb okosság! Mit kezdjek vele?!
Beindult a szkepticizmusom. Elképzeltem, amint éppen fejlesztek egy funkciót: direkt nem emelek ki belső, bonyolult kifejezéseket lokális változókba vagy metódusokba, és majd úgy tördelem a sorokat is, hogy kevesebb kódsor legyen. A megfigyelés szerint akkor kevesebb is lesz a hiba, nem? Teljesen abszurd.
Aztán miután lehiggadtam, egyszercsak rájöttem, a valódi tanulságra. Hogyan lehet ténylegesen kevesebb kódot produkálni?
Több (jó) megoldás is van.
1. Ne fejlesszünk ki felesleges funkciókat!
Éppen ma tartottam egy prezit bent a cégnél, ahol arról meséltem, hogy a felesleges funkciók kifejlesztése az egyik legnagyobb pazarlás (Lean kifejezéssel élve: waste) a szoftverfejlesztésben.
Ennek az egyik – magától értetődő – oka, hogy ha felesleges funkciót fejlesztek, akkor azzal felesleges időt töltök el. Amibe viszont már kevesen gondolnak bele, hogy azáltal hogy felesleges funkciót fejlesztek, újabb hibalehetőségeket viszek be a rendszerbe. Mellesleg a kód komplexitása apránként nem kicsit növekszik a felesleges funkciók súlya alatt, és ez a komplexitásnövekedés is a hibák elburjánzását eredményezi.
Dehát hogyan lehet megelőzni a felesleges funkciók kifejlesztését?
Mint szoftverszállítók, alapvetően hibásak vagyunk abban, hogy felesleges funkciók kerülnek kifejlesztésre. Miért? Mert hagyjuk magunkat.
Szolgaian követjük az ügyfél által, az interjúkon lejegyzetelt követelmények kielégítését. A tanácsadó lejegyzeteli, követelményspecifikáció készül, azt meg megcsinálja a fejlesztő. Nem merjük azt mondani, hogy ne csináljunk meg valamit.
Meg kell győznünk az ügyfelet, hogy célszerű mindig egyszerű megoldással indulni. Ne tömjük tele az elején a rendszert mindenféle értelmetlen funkciókkal. A kevesebb több. Ebből könnyebb mindig a továbblépés, ha valóban szükséges.
Persze, nagyon sokszor nehéz ezt elmagyarázni az ügyfélnek. Merthát mi a realitás: van egy jó kis közbeszerzési eljárásunk (ami le van írva az ajánlatban azt kell megcsinálni), másrészt pedig – ha az államigazgatásnál maradok – a legtöbbször az ügyfélnek éppen most van pénze, ezért mindent bele akar zsúfolni a projektbe, amit csak tud. És az a jó fej szállítócég, aki minél több funkciót, minél kevesebbért beígér, az előnyben részesül a többiekkel szemben. És azt hiszik, hogy ez jó.
Csak sajnos, azt nem veszik figyelembe, hogy minél többet kérnek, annál rosszabb lesz a szoftver. Sokkal később készül el, mint készült volna (bár Parkinson törvénye más sugall
J), sokkal több hiba lesz benne (a sok felesleges funkció és a határidő miatti kapkodás miatt), és sokkal áttekinthetetlenebb és bonyolultabb lesz a felhasználói felület is. Soroljam még? Ja, még az oktatás is tovább tart.
De most egy kicsit elkanyarodtunk az eredeti témától: hogyan írjunk kevesebb kódot, hogy így a hibák száma is kevesebb legyen?
2. Fejezzük be az álmodozást!
Sokszor találkoztam azzal az attitűddel (magamat is bele értve), hogy lelkes fejlesztőként, aki az ügyfélnek a legjobbat akarja, kitalálják, hogy a kifejlesztendő funkcióba mindenféle kis apró okosságokat fejlesztenek. “Milyen jó lenne, ha a felhasználó még ezt is meg tudná csinálni!”
Hibás gondolat. Fogadjuk el, hogy alapvetően sötétben tapogatózunk. Nem tudjuk, hogy az ügyfél hogyan fogja használni az új szoftvert. Ahelyett, hogy az okosságok kifejlesztésével törődnénk, mutassuk be neki hamar az elkészült a szoftvert, hozzuk előre az éles telepítést, és nézzük meg, hogyan reagálnak, mik a valós tapasztalatok!
Kevesebb kód, kevesebb hiba!
3. Fejezzük be a komplikálást!
A túltervezett (over-engineered) kód. Ha nem olvastad volna, korábban írtam már róla.
4. Szüntessük meg a duplikációkat!
Ha egy kódrészlet többször is szerepel, akkor ha valahol hiba van benne, az még több helyen okozhat problémát a szoftverben. A duplikációk megszüntetése (vagy inkább: minimalizálása) fontos feladat.
Refaktor.
Konklúzió
Szóval ennyi. Törekedjünk arra, hogy minél kevesebb funkció legyen, de azok jól legyenek megcsinálva. Ne bonyolítsuk túl, mindig az egyszerűség legyen szem előtt.
Minél többet kódolunk, annál több a hiba.
