> Másról beszélünk.
Dehogy beszélünk másról.
> Engedd el azt, hogy a software-nek kell a specifikációt tudnia. Nem! A berendezésnek kell.
Nem mondod... És? Abban nincs software?
> Semmire nem mész egy hibátlan software-rel, amelyik nem veszi figyelembe - mert nem tapasztaltad meg valós környezetben - a fizikai valót, a hardware-t.
Egyrészt, az a software, ami nem azt csinálja, amit kell neki, az definíció szerint nem lehet hibátlan :) De ha ezen a kis logikai benézésen túllendülünk, akkor még mindig ott van, hogy senki nem mondta, hogy nem kell hardwaren is tesztelni.
> A software-t a hardware-hez kell igazítanod. Arra írod. Vedd úgy, hogy valami izgő-mozgó, szuszogó, csöpögő, melegedő, hűlő, világító, hangot adó és fogadó valamit kapsz a kezedbe, s ez a specifikáció. Ezzel kell valamit kezdened.
Megintcsak, igen, és? A szimulált adatos meg mockos teszt pont ugyanúgy használható, ahogy bárhol máshol. A szoftvernek az a dolga, hogy ha ez és ez történik, akkor ezt és ezt csinálja. Akkor is, ha egy ldap szervertől jövő választ kell feldolgozni, akkor is, ha egy stdinen érkező adatot kell olvasni, meg akkor is, ha egy pinről leolvasott jelszinttel kell valamit kezdeni. Teljesen mindegy, hogy szimulált ldap válasz, vagy szimulált tüske állapot van. Amit az ilyen tesztekben tudatosan megfogalmazol, hogy a vezérés ilyen is ilyen esetekben ezt és ezt csinálja, arról tudod belátni, hogy az valóban úgy van. Ha valóságban mégsem ez történik, akkor szar a modelled, meg kell értened mi történik valójában, mert valószínűleg szar a kódod is, hiszen nem értetted meg jól a speckót :)
> Az lényegtelen, milyen kódot írsz, az a fontos, hogy a berendezés legyen jó.
Dehogy mindegy. A kód minősége adja neked azt, hogy amikor majd hozzá kell nyúlni, akkor hozzá lehessen. Úgy, hogy ne cse
> A hardware-t éleszted a kódoddal, nem pedig ideális modellre írsz hibátlan programot.
Ki beszélt itt ideális modellről? Mármint rajtad kívül. Ráadásul mindig vicces látni, mikor az egyik oldalról azzal jönnek a villamosmérnökök, hogy itt rend van kérem, meg rendes speckója minden alkatrésznek, ahol jól le van írva pontosan, hogy mi lehet, a másik oldalról meg aztán előadjátok, hogy de ezeket a jó speckókat még csak véletlenül sem lehet ám a hardware helyett használni.
Az a baj, hogy láthatólag fogalmad sincs róla, hogy mennyit fejlődött a szofverfejlesztés módszertana az elmúlt 20 évben, ezért nem is érted, hogy miért kellenek reprodukálható tesztek, hogy mennyivel jobb szoftvert lehet írni, ha ilyeneket használsz, és inkább előadod, hogy ez a ti területeteken nem menne, mert az annyira speciális, meg ahhoz nem értenek a szofveresek úgysem. Rossz hírem van, lófaszt speciális.
További vicces, hogy kijelented: "Ez mérnöki feladat. Szerintem nagyon rossz az a megközelítés, amikor egy programozó felteszi a kezét, hogy ehhez már semmi köze, mert ebben áram folyik." Majd ezek után mikor a szoftveres elkezdené nem feltenni a kezét, akkor meg jössz azzal, hogy de azt úgy nem lehet. Mert te természetesen az ő területéhez is kiválóan értesz a magadén túl.
Azért pluszban különösen aranyos, mert a szoftveripar már régestelen rég felismerte (igazából szerintem mindig is tudta), hogy ő modellekkel dolgozik, amik olyan valós problémákat oldanak meg, amikhez a programozó nem ért, ezért viszonylag széles tárháza van annak, hogy hogyan lehet ezeket a domain specifikus információkat az ehhez értőkkel együtt dolgozva értelmezni, legyen az villamosmérnök vagy banki folyamatokat szabályozó jogász. Ennek meg elengedhetetlen része, hogy jól figyeljen arra, amit mondanak neki. Majd jössz te, és jól előadod, hogy de ők ezt úgyse értik. Aha, hát persze.