Skip to content

Óvatosan az optimalizálással!

Miért?
Az optimalizálás mindig sok ráfordítást igényel. Aki ezzel óvatosan bánik, gyakran értékes erőforrásokat kímél annak érdekében, ami a megrendelőnek valóban hasznos.


M.A. Jackson:
Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

Mindig a kód érthetősége áll az előtérben. Az optimalizált kód azonban gyakran több, mint olvashatatlan. Amennyiben az abszolút szükségesre, a legrövidebb formában van egyszerűsítve, lehet, hogy kielégíti a megrendelő funkcionális és nem funkcionális követelményeit – de általában már nem tükrözi őket érthetően. Ez viszont kontraproduktív a szoftver leggyakrabban kívánt hosszú élettartama szempontjából. Donald Knuth már 1974-ben megírta: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

A cserkészszabályt tehát nem úgy kell érteni, hogy egyre csak újabb kódoptimalizálsra kell törekedni. Sokkal inkább az ellenkezőjére vonatkozik: Érthetőség és továbbfejleszthetőség.

Ha tehát a Clean Code fejlesztőnek bizseregnek az ujjai, mert azt hiszi, hogy még egy picike kis performanciát tudna kihozni egy kis optimalizálással, akkor legalább kétszer gondolja át azt. Egyik oldalon rontana az olvashatóságon, másik oldalon valószínű, hogy az ilyen optimalizálásra több ok miatt sincsen szükség. Amennyiben a performanciagond nem csak egy pontban észlelhető és nem egy különleges eset, akkor a következő refaktorálás valószínűleg úgyis gondoskodni fog erről, hiszen akkor egy alapvető strukturális gond az oka. Vagy a következő hardvergeneráció majd kiegyenesíti a performanciatörést. Vagy a megrendelőt nem is zavarja ez. Mindenképpen a megrendelőnek kell jeleznie az igényét az optimalizálásra. Ne hajtsunk végre kódváltoztatást anélkül, hogy a megrendelő ettől hasznot várna. Mert csak az olyat lesz majd hajlandó kifizetni.

Tehát annak a szabálynak, hogy kétség esetén az optimalizálás ellen kell dönteni, egy ennél még alapvetőbb szabály az alapja: YAGNI – You ain’t gonna need it. Ez azonban teljes mivoltában csak a kék fokozat eleme lesz.

PS: Amennyiben minden figyelmeztetés és megfontolás ellenére egy performanciaoptimalizálás éppen elengedhetetlenné válik, akkor mindig csak egy részletes (Profiler-rel történő) elemzés után kezdjünk hozzá. Mert csak az tudja egy optimalizálás alatt és után ellenőrizni, hogyan és mennyire sikeres az, aki előzőleg a Profiler-rel reprodukálható szűk keresztmetszetek helyét megállapította.

Published inElvek