2020-óta retardáltak a programozók?

Kérdező: Azt csinálják, ami az üzleti igény volt. Ha az üzlet azt mondta, legyen piros az ég akkor piros lesz. A felhasználók majd háborognak, hogy kék kell. Lehet, hogy egy frissítéssel kék lesz, de lehet nem.

" közöttük lévő hézag túl nagy" Lehet, hogy rajtad kívül 10ezer felhasználónak épp ez tetszik.

13: Nincs ilyen, és megintcsak az üzlet dönti el. Ez egy iparág. Valahogy így néz ki:

"xy játékot tovább optimalizáljuk az 2 hónapnyi fejlesztési idő, x darab programozó 2 hónapnyi bére vajon megtérül -e ha annak a 300-600-5000 vásárlónak el tudjuk adni adott időn belül akinek jelenleg kicsi a hardvere a futtatáshoz". Ha ez nem térül meg, nem lesz megvalósítva. Profit a lényeg, mint minden más iparban a világon.

Kérdező 15 (2023.02.23. 19:05). Milyen tanfolyamon mondták? Erre tényleg kíváncsi vagyok. Miután az egyik hobbym az IT történelem, több nagyon régi tankönyvet elolvastam, amikor még valójában sokat számított az optimalizálás, mert alig volt memória a gépekben, és lassuak is voltak. Ezek a régi könyvek részletesen írják az optimalizálás problematikáját. Eleve ott kezdődött a dolog (és ez ma is igaz), hogy olyan nem létezik, hogy "minél alacsonyabb erőforrású program" (vö.: Kérdező 13 2023.02.22. 21:09). Még amikor ennek lényegesen több jelentősége volt akkor is leírták nem egy helyen, hogy alapvetően két (egymással szemben álló) erőforrásra lehet optimalizálni az egyik a memória a másik a futásidő (azaz a CPU igény). Lehet olyan programot készíteni (most itt nem a játékprogramokról beszélek, mert az egy egészen más kategória) ami kevés memóriát fogyaszt /mert pl. nem volt elég memória a gépben/, és lehet olyat ami gyorsan lefut. Általában igaz, hogy a kettő egymást üti. Ld. pl. az egyik klasszikus példa egy rendezés (és nem véletlenül van ennyi féle rendező eljárás), voltak olyan megoldások, hogy szinte 0 memória volt a gépben és 3 db. mágnesszalagon rendezték az adatokat (1. szalagon volt a rendezendő "fájl"; 2. szalag volt az átmeneti tároló, 3. szalagra került az eredmény). Jó sokáig tartott de egy olyan gépben amiben volt 8 kByte memória lehetett rendezni több száz kByte adatot. Szerencsére ez az idő elmúlt. A másik ilyen példa (ezt végig is csináltuk annak idején) keresd meg az első 10 000 db. prím számot. egy ideig lehet gyorsítani az eljárást, de van egy pont amikor már az jön, hogy a további gyorsításhoz sok memória kell, mert elkell tárolni az addig megtalált prímeket.

Ma egy érdekes helyzet alakult ki (ennek előfutára az volt, hogy a hardver ára a többihez képest elenyésző lett, és szinte korlátlan CPU és memória van a gépben), hogy az ún. TCO-ra optimalizálnak. Azaz a teljes életciklus összes költségére. Ez itt azt jelenti, hogy veszik sorra a költségelemeket az ötlet megszületésétől egészen addig amíg a szoftver életciklusa befejeződik (kb. megszűník a támogatás), beleértve a hardver igényt (szintén nem a játékprogramokról beszélek). Ennek a költségnek a legjelentősebb tétele ma már a programozói munka. És az optimalizáció azt jelenti, hogy a programozónak legyen a legkevesebb munkája (és nem véletlenül jönnek pl. az automatizált tesztek, és egyéb nyalánkságok) mert a programozói munka esetén is a tényleges fejlesztés és a tesztelés az ami irtózatosan nagy költség. (és jelentős költség a szoftver dokumentálása is, látjuk, hogy ezen is spórolnak ma már, mert hajmeresztő dokumentációk kerülnek ki). Nyilván ennek a történetnek vannak olyan vonzatai, hogy az egyszerű (és gyors) fejlesztést támogató - ámde a hardver erőforrásokkal pazarló - megoldások kerülnek előtérbe (pl. OOP model). De lehet, hogy felhasználói szemmel is jobban megéri, hogy ma veszek egy nagyobb gépet (pl. 64GB RAM és erős proci) de kevesebbet fizetek a szoftverért.