Bejegyzés

Mi is követünk el hibákat – Verzió történet egyik bejegyzése önmagáról

Sajnos mi is követünk el hibákat. Egyik volt főnököm szerint csak az nem hibázik, aki nem dolgozik. Mi dolgozunk…

Nem fatális, banális hibát ejtettünk. A verzió történet azt a célt szolgálná, hogy minden felhasználó információt kapjon a változásokról. Sok partnerünknél a rendszergazda csak akkor telepíti az új verziót (pedig pofon egyszerű az upgrade), ha van benne valami fontos vagy súlyos javítás.

Legutolsó verziónkban a verzió történet ablak nem jelent meg. A működése pofon egyszerű, nem is tudtuk mire vélni a hibát, majd 4 perc alatt megláttuk a hiba okát: a kiadás előtt pár perccel, amikor a helyesírást még egyszer megnézzük végső lépésként, egy & jelet tettek a kollégák az XML fájlba (Drag&Drop), amely a changelog adatait tartalmazza. Az XML parser működése ismert, de nem programozók szerkesztik a changelog-ot. Fene gondolta volna…

Új verziónk első hibabejegyzése az lesz, hogy “Nem jelent meg a verzió történet”. Addig is partnereink megértését kérjük a hiba miatt – 🙂 és javasoljuk nekik a http://mit-hogyan.symboltech.hu/2011/01/1-66-48-4030-as-verzio-ujdonsagai/ linkeket, ahol ugyanazokat az információkat láthatják.

A fenti bejegyzés nem is készülhetett volna el, ha a Symbol Ügyvitel nem tartalmaz havi szinten 20-30 újdonságot, változást. Ennek ez az ára 🙂

Takarítás szoftverkiadás előtt

Szoftvertermék kiadása előtt mindenképp ajánlott a kódot revizionálni. Több hónapos, több fejlesztővel folyó fejlesztés során számos olyan dolog “marad” a forráskódban, amely nem maradhat benne a kiadás előtt.

Eddigi fejlesztési tapasztalataink alapján összeszedtük, hogy mikkel találkoztunk eddig. Nem titok és nem szégyen, velünk is előfordul, mi is mulasztottunk már:

wrongway

Direkt lassítás. Nem károkozás, sokkal inkább professzionális munkamódszer, amikor lassabb számítógépet emulálva szándékos lassításokat helyezünk el a kódban. Nem célszerű ezt a kiadott verzióban is benne felejteni.
Megoldás: #warning pragma használata

 

Felugró ablakok. Hibakeresési céllal sok programozó használ felugró ablakokat, sőt – bár nem illik, de néha az átlagosnál durvább verbális kifejezéseket is. Mivel ezek hibafelderítési célokat szolgálnak, általában ott maradnak benne a kódban, ahol csak alapos tesztelés során talál rá az ember/tesztelő. A végfelhasználónál megjelenő, nem értelmezhető, oda nem illő üzenetek presztízsrombolók.
Megoldás: Üzenet megjelenítése Debug.WriteLine()-nal.

 

A bűvös new Random(). A végfelhasználó nem veszi észre mindig, de számos helyen alkalmazunk véletlen tesztadatokkal való feltöltést. Nem szerencsés, ha a végfelhasználónál történő új vevő rögzítéskor a vevő neve és címe már kitöltésre került tipikusan “Kovács Géza” és “Kiss János” nevekkel.
Megoldás: new Random() konstruktorok megkeresése a forráskódokban.
Saját tapasztalat: Nem minden ilyen konstruktor kell, hogy megszűntetésre kerüljön. Legutolsó projektünk a tisztítás után 7 helyen használta a Random konstruktort.

 

Ideiglenes fájlok írása. XML vagy bármilyen más adatátvitel implementálása közben gyakran mentjük az átvitt adatokat átmeneti fájlokba. Sok esetben ez a C:tempfile.dat, amely azon kívül, hogy az ügyfél számítógépén furcsán mutat, rendes biztonsági házirendet tartalmazó környezetben (a fájlírás letiltása miatt) IOException-t eredményez.
Megoldás: if DEBUG direktíva használata fájl írásakor.

Takarításra fel! 

sweep