A perfekt kód vajon lehetséges?

#31

Egyszer, ha lehetőséged adódik, kérdezz meg valakit, hogy az olyan játékprogramokat, mint pl. a GTA, hogyan fejlesztik és akkor majd képbe kerülsz magával a tervezés folyamatával. Azzal is olyan szinten, ahogy annak lennie kellene, szinte mindenhol.

Dióhéjban, nagyjából úgy történik ez, hogy meghatározzák az igényeket, azok kivitelezhetőségét. Ezután dekompozícionálják a feladatot, tehát részekre bontják és súlyozzák a tennivalókat. Kiszámolják a dolog hozzávetőleges hardverigényét és ebből meghatározzák a céhardvert. Azt az eszközt, vagy eszközök együttesét, amin a produktumnak futnia kell.

Ez adott esetben egy fix kombó (konzol), más esetekben (PC gaming, CAD, stb.) ennek csak egy minimuma.

Az eredmény meghatározza, hogy milyen számítási teljesítményű processzort és milyen kapacitású operatív tárat (egyebeket (pl, ROM mérete, sebessége, GPU, LAN tipusa, topológiája, átviteli keresztmetszete)) igényel a tervezés (mármint a tervező csoport).

Ha ez megvan, akkor erre osztják ki a feladatokat, ami annyit tesz, hogy minden fejlesztői alcsoport kap a saját feladatához bizonyos mennyiségű memóriát, bizonyos mennyiségű számítási kapacitást és ha a feladat igényli, akkor az ahhoz szükséges perifériális támogatást. Ez az erőforrás kiosztás általában kevés szokott lenni és emiatt megy a harc az alcsoportok között, hogy ki tudjanak a tervezőktől lobbizni maguknak még egy kis pluszt.

A válasz általában elutasító, vagy ledegradáló, hogy azért kell nekik a plusz, mert szakmailag kevesek a feladathoz, ami arra ösztönzi a fejlesztőket, hogy jobban odategyék magukat, de ha a határidő szorít, akkor előfordul, hogy megkapnak az igényelt erőforrásokból valamennyit, pláne, ha van is honnan elvenni. Az egészet nem, mert az annak beismerése lenne, hogy hibás volt a tervezés. Olyan is megtörténik, hogy a kényes részt maga a tervező csoport fejleszti le.

Nagy adatforgalmú rendszerekben, ahol várható, hogy bizonyos adatok esetén megnő a hozzáfordulás esélye, minden további nélkül lehet valami puffer, cache. Rendezett listák állításánál hétköznapi dolog az ilyen. Ki lenne olyan hülye, hogy napi százezres látogatószámnál újra és újra generáltatja az ár szerint emelkedő sorrendet? Senki. Ezzel, hogy cache, nincs semmi baj. Magával a hozzáállással van baj. Azzal, hogy ki lett jelentve, ha így, akkor így optimális, ha úgy, akkor meg úgy. Idézem:

"Mi az optimális? Ha csak a műveletigény és memóriahasználat vonalon mozgunk, akkor is elmondható, hogy egy bizonyos szint után ezek egymás rovására fejleszthetőek csak. Példa: elcachelsz adatokat, hogy megússzad, hogy később újra ki kelljen számítani, így a programod gyorsabb lesz, de nagyobb lesz a memóriaigénye)"

Ilyen nincs. Ilyen nem lehet. Ilyen dilemmába nem eshet senki.

Ha épül egy rendszer, amiben adattömböket kell majd szortolni, akkor igenis el kell dönteni, hogy a felhasználás során mi lesz az optimális. Tudni kell, hogy milyen adatokon fognak a szortoló műveletek futni és mifélék legyenek azok a műveletek, ergo, milyen legyen a szort rutin.

Ha idővel az adatok megváltoznak és emiatt az implementált szort rutin deficites lesz, akkor annak az oka egy külső körülmény és nem a program megfelelőségének a hiánya.

Na de csak emiatt (hogy majd egyszer, talán lehet valami változás és akkor milyen jól jön), cache-t, puffert beépíteni a fejlesztésbe nem érdemes és nem is szabad.

Ehhez a prime numberes példához azért nem szólok hozzá, mert kissé pongyolán vannak meghatározva a keresővel szemben támasztott elvárások. Vitaalapot meg nincs kedvem generálni.