Verziószámaink felépítése a következő (x.y.z.w)

X: Főverzió száma, amely jelenleg 1. Nagy szoftver ugrást tervezünk jövő év közepén (bár eddig sem ugrottunk kicsiket), akkor fogjuk kettesre módosítani.

Y: Alverzió, amely a főverzión belüli újdonságokat tartalmazza. Azok a cégek, akik részt vesznek partnerprogramunkban és már a kiadás előtti verziókat is megkapják, általában kapnak páratlan verziót is, de a hivatalos verzióink mindig párosak (1.60, 1.62, 1.64 nemsokára)

Z: Adatbázis verziószáma. Amikor olyan jellegű változtatás történik (az utolsó egy évben gyakran), amikor szükség van új adatbázis működésre, a számot változtatva az adatbázis automatikusan frissül.

W: Ez a cikk fő témája, a 2001. jan.1 óta eltelt napok száma. Ez a szám egyértelműen azonosít egy program kiadást, azaz a kinyomtatott számla alján látható szám alapján tudjuk, hogy melyik napok adtuk ki azt a verziót, amivel a számlát nyomtatták.

4000 napja élünk a 21. században, a Symbol Ügyvitellel pedig lehetősége van arra, hogy 21. századi ügyviteli rendszert használjon.

Minden kérdésére készségesen válaszolt Balázs Csaba fejlesztési vezetőnk, aki talán a legkompetensebb a témában.

FP: Miért ilyen gyakran?
BCS: Röviden? Mert képesek vagyunk rá.

FP: És kicsit hosszabban?
BCS: Van mit és tudjuk, hogy hogyan. Általában 3-4 heti gyakorisággal gyűlik össze annyi újdonság, hogy érdemes legyen egy csomagként megjelentetni. Próbálkoztunk már kéthavi kiadással, de olyan mennyiségű volt az újdonság, hogy két nyílt napon tudtuk csak bemutatni a programot. Pontosítok, a program újdonságait.

FP: Ennyi javítanivaló van?
BCS: Újdonságokat említettem az előbb is. Újdonságok teszik ki a fejlesztés 75-80%-át. Van benne javítás is, ezek általában apróbb felhasználói visszajelzések, nem komoly hibák. És igen, több, mint 3/4-e újdonság. Ezek vagy a programunk újdonságai, vagy valóban ügyviteli újdonságok.

FP: Valóban folyamatos a fejlesztés?
BCS: A jó szoftver sosincs kész. Ahhoz a programhoz nem készülnek új fejlesztések, amelyet nem használnak. Nálunk, a folyamatos használatból adódóan mindig merülnek fel igények.

FP: És ezeket a programba beépítitek?
BCS: Mindig mosolyogni szoktam a felhasználói igényeken, persze nem gúnyosan. Elmondhatjuk, hogy nagyon ritka a valóban új igény. A programunk alapja egy négy generációt megélt ügyviteli rendszer, amelyet cégünk egy akvizíció során már magáénak tudhat. Ezen a négy verzión már nagyon sokat tapasztaltunk. Legyen szó általános igényekről vagy speciális üzleti folyamatról, a nagy részük már tervbe van véve nálunk. Azaz nemsokára a polcról tudjuk kiszolgálni az olyan igényeket is, mint a munkaruha kihordási idő nyilvántartása. Tavaly év végén 2011.decemberéig volt meg a fejlesztéi tervünk, van mit csinálni.

FP: És most?
BCS: 2012. Karácsonya is munkával fog telni (nevet)

FP: Érdemes akkor még várnom 24 hónapot?
BCS: Dehogy! A termékünk a maga nemében már megjelenése után jól állta a sarat, mert szükség volt valami modern rendszerre. Az akkori rendszerek 6-10 éve készültek, ebből adódóan legalább 7-11 éves technológiával. Felkevertük az állóvizet. A termék egy évvel a megjelenése után jól szerepel, számos funkciójában lekörözte versenytársait.

FP: De ha még nálatok is vannak fejlesztési tervek, akkor más, 6-8 éves termékekben ezek miért nem találhatóak meg?
BCS: Megtalálhatóak. A maguk módján. Minden rendes ügyviteli szoftver megvalósítja az évek során összegyűlt funkciókat, de azok vagy ügyfél igények alapján készültek – ügyviteli szakértelem nélkül – vagy csak fejlesztői gondolatokat figyelembe véve. Ez pedig a valóságtól messze van. De egy még fontosabbat kiemelnék, a precizitást. Minden dolgot több féle módon megvalósíthatunk, de kevés termék van, ami a felhasználói kényelmet és a legapróbb igényt is megvalósítja. Mi erre törekszünk, azaz hogy legyen élmény az ügyvitel!

FP: Mondasz erre egy példát?
BCS: Jó példa a gyári szám kezelés. Minden szoftverterméknek része, de vajon használható-e? Nálunk nem az a cél, hogy a gyári számok a számlán megjelenjenek, hanem valóban ki tudjam mutatni, hogy milyen gyári szám hányszor és mikor fordult meg nálam. És ezt még Symbol-osan megspékeljük azzal, hogy termékenként a gyári szám bevitele maszkolható. Azaz mobiltelefonoknál nem tudunk nem 15 jegyű IMEI számot beírni, nem tudjuk elgépelni.

FP: Azt hiszem, erre mondjátok, hogy innovatív
BCS: Meg az egészre, amit itt csinálunk. 80% gondolkodás, 20% munka.

FP: Elején említetted, hogy tudjátok a hogyant is. A konkurencia nem tudja?
BCS: Pontosítsunk. Nem szeretem a konkurencia szót. Azt sugallja, hogy egy van, aki a legjobb és a végén is csak egy maradhat. Inkább használjuk a versenytárs szót, hiszen verseny azért van.

FP: Szóval, a versenytársak nem ismerik a hogyant?
BCS: Mindenki ismeri a saját hogyanját. A miénk lehetővé teszi, hogy 3-4 hetente kiadjunk egy verziót, amely az ország több száz számítógépén tökéletesen frissül – még soha nem volt ezzel kapcsolatban hiba – és megoldást szállít a problémákra. Sokáig terveztük a saját rendszerünket, a cél pont az volt, hogy könnyen tudjunk hozzáilleszteni, könnyen lehessen bővíteni.

FP: Említetted, hogy problémák vannak…
BCS: Mindenkinek, Neked is, ha valami nem működik vagy nem elég hatékony, akkor az probléma. A remek ötleteidet rajtad kívül álló okok miatt nem tudod megvalósítani, a fránya számítógép vagy a számlatömb a szűk keresztmetszet. Ezek a problémák, amikre megoldást nyújtunk. Valódi megoldásokat.

FP: Mik a jövőbeni tervek?
BCS: Decemberben is marad a 3 heti gyakoriság, sőt egy kicsit bele is húzunk, két kiadás is lesz. Amíg a többiek pihennek, addig mi dolgozunk, mert az ügyvitel a szenvedélyünk. (nevet) Ismét 42 újdonságra jut 13 javítás, módosítás, lesz benne iparági újdonság is, mint amilyen a Symboogle volt. De erről többet majd a szoftverkiadáskor.

FP: 2012 decemberében folytatjuk a beszélgetést?
BCS: Ismételjük meg gyakrabban! Büszkék vagyunk a munkánkra, ezt kívánjuk továbbra is csinálni. Nagyon jó visszajelzések érkeznek. A kedvencem a: “Hol voltak maguk idáig???“

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:

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!