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 

 

 

 

 

 

 

 

2 válaszok
  1. NCode
    NCode says:

    Dolgoztam olyan cégeknél, ahol erre nem volt idő. Mindig csak a kiadás időpontja volt a lényeg és a gyorsjavítások megléte. Az, hogy a forráskód mennyire használhatatlan az egyszerű programozón kívűl senkit sem érdekelt. És még azt sem értették meg, hogy mennyire fontos ez, mert a hiba keresését nagyon le tudja rövidíteni. Főleg az olyan típusú hibáknál, amik az alkalmazás teljesítményére vonatkoznak.

  2. KPeti
    KPeti says:

    Neki is állok takarítani, nálunk is biztos számos dolog van a kódban. Mivel a szövegeink mind erőforrásban vannak, ezért a ” jelre való keresés talán kidob minden oda nem illő szöveget.

A hozzászólások nincsenek engedélyezve.