( Chain-Q | 2018. 07. 16., h – 17:33 )

Én ugyanezt hallgattam fél évig egy hardver experttől, aki vadászta a bugokat az algoritmusában az igazi hardveren (szenzoradatok, analóg jelek digitalizálása és "real time" elemzése FFT-vel - helyesebben Goertzel-filterrel, mindegy).

Végül kilépett a cégtől. Megnyertem a feladatot, hogy fejezzem be a vackát és debugoljam ki. Sajnos én szoftveres vagyok, így nem hittem el hogy nagyon melós lenne a hardvert megfelelően szimulálni, ezért kigyomláltam az algoritmust a firmwareból, valamint nekiálltunk adatfolyamokat rögzíteni a valódi hardverrel, amit aztán beadagolthattunk az algoritmusnak egy tesztkörnyezetben.

Mivel a tesztkörnyezet innentől nem egy 48Mhz-s Cortex M0 volt, ami valós időben várt a bemenetre, hanem egy 3Ghz-s i7 ami egy tömbből olvasott be egy rakás számot, hirtelen az analízis futási és debug turnaround ideje lement húsz percről tíz másodpercre, ráadásul konzisztens bemeneti adatokkal hirtelen elkezdtük tudni reprodukálni azokat eseteket ahol az algoritmus szétesett, anélkül hogy fél napig futtatni kellett volna az egész teszthóbelevancot. Két nap múlva megvolt a bugfix arra, amit az eredeti írója a hardverhez ragaszkodva fél évig vadászott, ráadásul unit tesztelve, reprodukálhatóan. Aztán a meglévő rögzített adatblokkok alapján csináltunk még vagy további kétszázat némi randomizálással, ami további pár másik gyenge pontot is kidobott az algoritmusban.

No de mindegy. Nyilván ez csak egy elszigetelt eset volt, és amúgy az igazi hardveren tesztelni sokkal jobb...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-