A héten találtam egy cikket, aminek egy része nagyon feltolta az agyvizem: Korai optimalizáció, avagy minden gonosz forrása

Röviden, nem szakmázva túlzottan, az első fele arról szól, hogy a fejlesztőnek nem érdemes a korai szakaszban optimalizálni a kódot, mert még úgy is alakul, akkor pedig problémát okozhat. Oké, ebben van ráció, bár én azt gondolom, hogy ha egy kód első körben is jó közelítéssel van megtervezve és megírva, rugalmasan, akkor később ritkán lesz szükség külön optimalizálásra. Ebben benne van az is, hogy sokszor előfordul a kényszerű optimalizálás, amikor vissza kell térni egy-egy kritikus ponthoz, mert nem jó teljesítménnyel fut.

Igen, ez nettóban időveszteségnek számíthat, hiszen megrendelői oldalról nem látszik túl könnyen, hogy miért is kell az adott részt többször átdolgozni - bár sokszor az is belejátszik, hogy a megrendelő egy utólagosan felmerült igénye miatt kell az egész optimalizálást újragondolni. De gondoljunk csak a TDD megoldásra: ott először csak a teszteknek megfelelő kód megírásra a cél, gyorsan, és utána lehet refaktorálni, amíg el nem érjük az optimálist közelítő működést. Első körben ez is pazarlásnak tűnik, viszont ha számszerűsítjük a tesztek használatával megspórolt manuális tesztek költségét, akkor máris más a gyerek fekvése - ennek külön irodalma van.

De ami kiütötte a biztosítékot az a végső megállapítás, hogy nem kell annyira erőltetni ezt az optimalizálás dolgot, majd tolunk alá erősebb vasat. Meg az anyátok******t! Pont ez az a szemlélet, ami miatt két évente le kell cserélni az eszközöket, mert a slendrián és fos minőségű alkalmazások és rendszerek egyszerűen nem képesek működni a két évvel azelőtti hardver teljesítményével. Értem, hogy ez a kapitalista megközelítés tökéletes példája, mert így a paraszt még többet lesz kénytelen fogyasztani, de bakker, így annyi szemetet termelünk, hogy nagyon hamar bele fogunk dögleni.