IRF: kikerült a HF2 eredménye

Kikerültek a portálra a második házi feladat értékelései, ezzel kapcsolatban pár megjegyzés:

• Az értékelések átlaga 12,26 (~80% a maximum pontnak), az egyes javítások átlaga az átlagtól +-0,75 ponttal tértek el, így most eléggé egyenletes volt [a pontokat a végén néztük csak össze]. A legszigorúbb most én voltam (E csoport).
• A 140-ből 11 darab házi feladatot nem fogadtunk el: volt olyan, ami nem futott le; volt, ami a feladat lényegi részét nem implementálta; és volt olyan, ahol a dokumentáció volt elégtelen.
• Ahol nem futott le a megoldás: részben pont az ilyenek miatt is lesz az utolsó héten a két előadás időpontjában házi feladat védés, ott be lehet még mutatni, hogy a leadott szkript a kiadott környezetben a specifikáció paraméterezésével le tud mégis futni.
• Az értékelésekben vegyesen vannak nagyobb hibák (kód nem fut le adott esetre; nem teljesíti a specifikációt), kisebb hibák (elírások; nem elég robusztus a kód) és jó tanácsok (hogy célszerűbb inkább hibaüzenetet szövegezni), ezeket remélhetőleg mindenki érzi, hogy különböző súlyúak.

Tipikus szakmai hibák

• Ez is ugyanolyan kód, mint bármi más programozási nyelven írt kód. Ennek megfelelően a helyes behúzásokra ügyeljünk, ez nagyban megkönnyíti a kód olvasását. Sok helyen a while / if után nem volt bentebb kezdve a kód, és így nagyon nehéz átlátni a struktúrát.
• Sokan nem figyeltek a kód alapvető hatékonyságára: enumerate műveletet használtak, amikor tulajdonképpen csak egy konkrét vagy néhány példányra volt szükség. A másik tipikus hiba, hogy ugyanazt a lekérdezést a kódban akár háromszor is lefuttatták egymás után közvetlen, holott ugyanazt az eredményt adta vissza mind, és így elég lett volna az első eredményét eltárolni, majd kiszedni belőle a szükséges információt. Ha ilyen éles kódot fogsz majd később írni, akkor nem lesz belőle túl jó fejlesztő.
• Hibakezelés: távoli lekérdezést/beavatkozást használó kód esetén egy esetre biztos fel kell készülni, ez pedig az, amikor a művelet sikertelen lesz. Sok kódban nem volt ellenőrzés az első kérés előtt/után, így pl. ha valami miatt nem volt elérhető a távoli gép, akkor is megcsinálta a szkript az 5 felesleges lekérdezést. Ráadásul a távoli lekérdezés nagyon sok minden miatt meghibásodhat (nem létezik a távoli gép, nem feloldható DNS névvel volt megadva, nem figyel az adott porton, nem volt jó a jelszó, a távoli CIMOM hibát adott vissza...), kevés olyan megoldás volt, ahol ezek a részletes esetek legalább végig voltak gondolva/próbálva.
• Hibakezelés2: az alap dolgokon kívül elvileg egy jó programnak bármilyen bemeneti és környezeti hibát kezelnie kéne. Pl. a feladatokban a CSV fájl is bemenet volt, ha az rossz szerkezetű volt, azt hiába a felhasználó adta meg, de a végén a programunk fog elszállni division by zero vagy array error hibával, tehát nekünk kell kezdeni vele valamit. Legalább annyit, hogy kipróbáljuk, és a tesztelés résznél a dokumentációban leírjuk, hogy ez egy ismert hiányossága a programnak. [Nyilván a hibás CSV kezelését nem vettük szigorúan, de aki igazán profi akar lenni, az figyel az ilyenekre is.]
• Századszor is kiemelem: bemeneti paraméterek kezelésére PowerShell esetén a param kulcsszót, Bash esetén a getops parancsot használjuk. Ha mi próbáljuk meg a paraméter sztringet feldolgozni kézzel, akkor biztos el fogunk rontani benne valamit.

Dokumentáció

• A dokumentációnak az a szerepe, hogy kiegészítse a kódot. Ebben az esetben tipikusan a környezet beállítása, a szükséges előkövetelmények, a tesztkörnyezet volt lényegi plusz információ.
• A működés leírása nem attól lesz részletes, hogy darabokban a teljes kód ott van. Próbáljatok inkább a lényeget kiemelni: az elején legyen egy áttekintés, hogy milyen részfeladatai vannak a programnak, milyen technológiákat használ. A kód bemutatásánál koncentráljatok arra a részekre, ami Nektek nehéz volt, valószínűleg ez lesz az érdekes az Olvasónak is (egy sima switch a bemenetek kigyűjtésére nem izgalmas, ellenben a távoli szűrőkifejezés összeállítása vagy mi az elve a visszakapott XML üzenetek feldolgozásának egy visszakapott XML darabolása awk/sed/grep segítségével már nehezebben érthető). A fő értékelési szempont: ad-e valami pluszt a dokumentáció, könnyebb-e megérteni a programom működését ebből, mint a forráskód olvasásából?
• A tesztelés dokumentációjánál a legfontosabb szempont a reprodukálhatóság legyen: olvasd el a végén a leírtakat, és kérdezd meg magadtól, hogy ez alapján végre tudnám-e hajtani pontosan ezeket a teszteket és meg tudnám-e nézni, hogy én is ezeket az eredményeket kapom. Ha nem, akkor még valami hiányzik belőle. Tipikusan a teszt célja, teszt bemenete (bemeneti fájlok, pontos paraméterezés), kapott kimenet kell valami jól strukturált formában. Ezen kívül kell még egy fontos rész, a teszt értékelése: ezt vártuk / nem ezt vártuk, helyes a program / hibás.

Ezek a hibák szerintem nem csak IRF-specifikusak, érdemes később is figyelni rá bármilyen kód készítése esetén.

Ha valaki nem ért valamit az értékelésében (pontosan mi volt a hibája, miért jobb az általunk javasolt megoldás stb.), akkor nyugodtan keressen meg előadás szünetében vagy utána.