Dolgozat formájában volt számon kérés de kettö kérdésre keresve se találtam választ , lehet én vagyok a béna?

Első kérdésre a redundánst mondanám: ha bármilyen hibával kiesne egy elem a rendszerből, egy másik átveszi a helyét, így a rendelkezésre állás biztosított vagy folyamatos, és nincs leállási idő (pl. adatbiztonság oldaláról RAID, energiaellátás esetén szünetmentes táp vagy egyéb másodlagos rendszerek). A "hosszabb üzemidő" értelmetlenül hangzik onnantól kezdve, hogy egy informatikai rendszer általában 0-24-ben működik és mindig elérhetőnek kellene lennie, ott nincs eleje és vége aminek az idejét tologathatod.

A másik kérdést nem értem, bocs.

2-esre szerintem igen a válasz.

Egységtesztelés pont erre való, hogy futtatás nélkül tesztelni lehessen hogy x ill. y feltétel hogyan kerül kiértékelésre.

Az első kérdésedre a válasz alapja a vertikális és horizontális skálázás fogalmai lesznek. Konyhanyelven, ha egy rendszer terhelése megnő, mert mondjuk az egyetemen tárgyfelvétel van, kétféleképp lehet reagálni rá, és ennek módja attól függ, hogy a rendszered állapotfüggő (stateful) vagy állapotfüggetlen (stateless). Stateful-nak akkor nevezünk egy szoftvert, ha a működése nem függ memóriában tárolt információtól. Ez a gyakorlatban azt jelenti, hogyha a stateful alkalmazásból két külön számítógépen elindítasz egy-egy példányt, és a felhasználó kéréseit az A számítógép kezdi el kiszolgálni, de hirtelen a terheléselosztó úgy dönt, hogy az A gépet már nem kellene tovább terhelni, a B gépnek továbbítja. Viszont a B gép nem tud olyan információt, amit az A tud (hiába ugyanarról a szoftverről van szó, a memóriabeli állapota a kettőnek különbözik), így a B gép a felhasználó kérését nem tudja kiszolgálni. Viszont ha az alkalmazásodat stateless módon írod meg, minden futó példány ugyanazt fogja tudni, tehát A és B gép is ki tudja szolgálni a felhasználó kérését.

A stateful alkalmazást könnyebb leprogramozni, de nehezebb üzemeltetni. Ha nagyobb terhelést kell elviselnie, akkor az egyetlen módja az, hogy erősebb gépet teszel alá (ezt hívják vertikális skálázásnak), ami akár leállással is járhat. Hiba esetén pedig általában van egy master és egy slave példány, amik között nem a világ legegyszerűbb dolga szinkronizálni az adatot, így egy átállás esetén adatvesztés fordulhat elő. Így oldható meg a redundancia ezen rendszerek esetében.

A stateless alkalmazás fejlesztése során külön oda kell figyelni arra is, hogy horizontálisan skálázható legyen. Ez azt jelenti, hogy egyrészt kritikus információkat ne a memóriában tároljunk, másrészt ha kiesik egy példány vagy megnövekszik a terhelés, nagyon egyszerűen egy új gépen egy új példányt indítok el belőle, ééés ennyi. Amint az új példány elindul, már készen is áll olyan kérések fogadására, amit eddig más példányok szolgáltak ki, hiszen ez az új példány azonnal be tud szerezni más szoftverektől (adatbázis, gyorsítótár) olyan információkat, amiket a többi példányok is tudnak. A redundancia ezeknél a rendszereknél "gyárilag" biztosítva van. A legjobb rendelkezésre állási mutatók az ilyen rendszereknél érhetőek el.

===

A második kérdésed konkrétan arra vonatkozik, hogyha egy kerekasztalnál több ember egyszerre bámulja a kódot, észreveszik-e azt, hogy egy if-else szerkezetben el van-e rontva a logikai feltétel. Hát, én ezt nem látom annyira egyértelműen megválaszolható kérdésnek, mert emberből vagyunk és hibázunk. Ráadásul van valaki, aki magyarázza a kódot, és sajnos hajlamosak vagyunk hinni neki, hogy igaz az, amit mond, tehát elfogultak vagyunk, főleg, ha egy vérprofi kollégáról van szó. Egy fokkal hatékonyabb módszer az automata statikus elemzés, amit pl. a SonarQube tud végezni a kódon. Ennek pedig az a hátránya, hogy az ilyen szoftvereknek halvány gőzük nincs arról, hogy mire gondolt a költő, azaz mi volt az üzleti igény, amit a fejlesztő lefejlesztett. Vannak olyan fejlesztői benézések, amiket egy ilyen automata szoftver nagyon könnyen kiszúr, de mondjuk egy fejlesztő figyelmét elkerüli. Például ez (PHP kód):

if ($_GET["article_id"] = 6) {...}

else {...}

De olyan problémákat nem fog tudni kiszűrni, ha azt szeretnéd, hogy pl. egy nemzetközileg használt szoftverben egy timestamp összehasonlításnál a vásárlónak megfelelő időzónát vetted-e alapul, mondjuk egy olyan vizsgálatban, hogy megkaphatja-e még a limitált idejű 20%-os kedvezményét. Erre az embereknek több esélye van, de még így sem biztos, hogy egy átvizsgálás a felszínre hoz egy ilyen problémát.

Felsőre: redundáns, ami több példányt takat ugyanabból. Így működik a RAID diszkek esetén egy NAS-ban például. RAID1 tükrözést használ azaz 1TB+1TB esetén 1TB-nyi helyed van, mert mind2re ugyanazt írja. Ha egyik elromlott, akkor is rendelkezésre áll az adat, mert ott a másik diszk. De szerverekre is igaz, hogy 3 szerveren ugyanaz az alkalmazás fut, de ha egyik elfüstől, akkor is kettő van. Egy esetén, persze fennakadás lenne, mert nincs mivel helyettesíteni

Második esetben szerintem az 3 a jó, mert egy szemantikai hibát szemmel nem biztos, hogy kiszursz. Ha vanndk autómatizált tesztek amiket rá futtatsz, az is kiadhatja a hibát.

Pl. Össze szeretnék szorozni 2 számot, és véletlenül összeadást írtam (tegyük fel) és senkise vette észre, mivel bizzosítod a helyes működést? Nyilván tesztekkel. Ráfuttatsz egy (2,2) ami összedva és szorozva is ugyanannyi. Ez persze jónak mondja. De egy (3,4) esetén 12 vársz, de 7-et kapsz, akkor ott van valami.