Korai optimalizáció, avagy minden gonosz forrása
A cím — bár a hasonlat Donald Knuthtól származik — talán kissé túlzás, de a korai optimalizáció (premature optimization) egy igen gyakori jelenség, legyen szó kezdő vagy tapasztalt fejlesztőkről. A tapasztalatok szerint, ha nem figyelünk, szinte szükségszerűen felüti a fejét, függetlenül attól, hogy milyen környezetről beszélünk, és attól is, hogy éppen mit próbálunk optimalizálni. Mivel ez egy nagyon fontos témakör, és akár egy egész projektet is alááshat, mai blogunkban ezt járjuk körbe.
Ha szigorúan a kódolásnál maradunk, korai optimalizációról beszélünk akkor, ha energiát fektetünk egy adott programrész optimalizációjába anélkül, hogy bármilyen benchmark kimutatná, hogy ez szükséges, vagy anélkül, hogy mérést végeztünk volna annak érdekében, hogy megállapítsuk a konkrét problémás pontokat. Akkor is korai optimalizációról beszélünk, ha az elképzelt hatékonyságnövelést a projekt jelenlegi szakaszához képest rossz absztrakciós szinten végezzük (pl. a kezdeti prototípus fázisban hosszú napokat töltünk egy apró részfeladat optimalizásával).
A legfőbb gond, hogy ez a gyakorlat a legtöbb esetben rengeteg pluszmunkát eredményez, ill. további mellékhatása, hogy a (felesleges) optimalizáció miatt a kód átláthatatlanabbá, kevésbé olvashatóvá válik.
Az, hogy a korai optimalizáció ennyire gyakori, valószínűleg összefügg a fejlesztők általános perfekcionizmusával ("végre itt a lehetőség, hogy igazán jól csináljam"). Ha egy csapatot vezetsz, esetleg még a tagoktól is elvárod, hogy törekedjenek arra, hogy lehetőleg már az első verzió a lehető leghatékonyabb legyen.
Miután már jobban értjük a problémát, nézzük meg, mit tehetünk, hogy ne essünk magunk is ebbe a hibába.
Egy sokkal jobb megközelítés az, ha először a lehető legegyszerűbb és legelegánsabb megoldást választjuk mindenhol, és a hatékonyság helyett a helyességre, átláthatóságra helyezzük a hangsúlyt. A későbbi profiling és benchmarkok készítése alapján aztán optimalizálhatunk, ha ugyan van mit. Ha bele is futunk performancia-problémákba, ezek sok esetben egyáltalán nem is ott jelentkeznek, ahol eredetileg számítottunk volna rájuk.
De még ha a méréseink alapján azonosítani is tudunk bizonyos problémákat, még mindig nem biztos, hogy valóban érdemes is változtatunk bármit. Egy adott kódrészlet optimalizálása előtt mindig figyelembe kell vennünk Amdahl törvényét: az adott kód hatása a teljes programra óriási mértékben függ attól, hogy az átlagosan mennyi időt tölt a program a kódnak kifejezetten ezen a részén. (Ezt statikus kódelemzéssel nem is igazán tudjuk megállapítani.)
Bizonyos esetekben a teljesítménnyel kapcsolatos problémákra a legegyszerűbb és legolcsóbb megoldás egyszerűen a jobb hardver beszerzése. (Jeff Attwood egyenesen odáig megy, hogy a "bizonyos esetekben" valójában az esetek többségét jelenti.)
Zárszóként érdemes megemlíteni, hogy bár a korai optimalizációt kifejezetten a kódolás kontextusában értelmeztük, kiterjeszthető egyfajta tágabb értelmezéssé is: érdemes átgondolni, nem követ-e el a cég, akinek dolgozunk (vagy akár saját cégünk) hasonló hibákat szervezeti szinten.