Van egy nagyon fontos dolog, amit egyszer sem említenek a programozásról és szoftverfejlesztésről szóló könyvek, és amiért néha félreértjük egymást. Te szoftverfejlesztő vagy. Én is. Ám nem biztos, hogy ugyanolyan céljaink és követelményeink vannak. Tulajdonképpen a szoftverfejlesztésből több fajta létezik, és mindegyik külön világra más és más szabályok érvényesek.

Ha egy UML-ről szóló könyvet olvasol, sehol sem találod meg benne, hogy az alkalmatlan eszközmeghajtók írásakor. Vagy olvashatsz egy olyan cikket, ami azt írja, hogy „A 20MB-s futtatókörnyezet (a .NET-hez) nem lehet akadály”, de nem mondja ki a nyílvánvalót: ha csak egy 32KB ROM-al rendelkező csipogóba írsz, akkor igenis van jelentősége!

Úgy gondolom, öt különálló világról beszélhetünk, amik néha átfedik egymást, de gyakran nem. Ezek:

1. dobozos
2. belső
3. beépített
4. játék
5. egyszer használatos

Ha a legújabb Extrém Programozásról szóló könyvet olvasol, vagy Steve McConnel remek könyveit, vagy akár a Joel on Software-t, esetleg a Software Development magazint, egy rakás olyan kijelentéssel találkozhatsz, hogy így vagy úgy fejlessz szoftvert, de arról nem szól a fáma, miféle fejlesztésről is beszélnek. Ez azért nem szerencsés, mert a különböző világokban lehetséges, hogy másképp kell csinálnod a dolgokat.

Nézzük át röviden a kategóriákat!

Dobozos az a szoftver, amit „a vadonban” használ nagy számú felhasználó. Talán még be is dobozolják, és a CompUSA-ban is árulják, de akár internetről letölthető is lehet. Lehet pénzes vagy shareware, nyílt forrású, GPL-es, akármi – a lényeg az, hogy akár ezrek vagy milliók használják.

A dobozos szoftvernek van néhány problémája, ami két különleges tulajdonságából adódik:

• mivel olyan sok felhasználó van, akiknek más megoldások is rendelkezésükre áll, a felhasználói felületnek az átlagosnál egyszerűbbnek kell lennie, hogy sikeres lehessen
• mivel olyan sok számítógépen kell futnia, a kódnak különösen rugalmasnak kell lennie, már ami a különböző konfigurációkat illeti. Múlt héten kaptam egy olyan hibát a CityDesk-re, ami csak lengyel Windows-nál fordul elő, mivel az operációs rendszerben a jobb Alt-ot kell használni a speciális karakterek beírásához. Kipróbáltuk Windows95-ön, 95OSR2-n, 98-an, 98SE-n, Me-n, NT 4.0-n, Win2000-en, és WinXP-n. Teszteltük IE 5.01-en, 5.5-ön, és 6.0-n. Teszteltük amerikai, spanyol, francia, héber, és kínai Windows-szal. Ám még nem foglalkoztunk lengyellel.

A dobozos szoftver három nagyobb fajtája létezik. A nyílt forrású szoftvert leggyakrabban úgy fejlesztik, hogy senki sem kap pénzt a fejlesztésért, ami a dinamikát nagyban befolyásolja. Például azokat a funkciókat, amik nem élvezetesek, nem készítik el a lelkesedésből fejlesztő csapat, és, ahogy Matthew Thomas ékesszólóan rámutat, ez a használhatóságot ronthatja. A fejlesztés valószínűleg nagy földrajzi távolságokat ölel át, ami a csapat kommunikációját radikálisan megváltoztathatja. A nyílt forrású világban elég ritka a személyes megbeszélés, ahol táblára dobozokat és nyilakat rajzolnak. Így a tervezési döntéseket, amik pont a dobozok és nyilak rajzolásából nyernék lényegüket, csak kis hatékonysággal hozzák meg. Végeredményben a földrajzilag szétszórt csapatok sokkal jobbak meglévő szoftverek lemásolásában, ahol elenyésző mennyiségű tervezés szükséges.

A tanácsadószoftver tulajdonképpen csak egy változata a dobozos szoftvernek, amit annyit kell finomhangolni és installálni, hogy egy sereg tanácsadóra van szükség a bevezetéshez, aranyárban. Többnyire a CRM és CMS csomagok esnek ebbe a kategóriába. Az ember könnyen úgy érezheti, hogy ezek valójában nem csinálnak semmit, és ez csak egy indok, hogy tanácsadók tucatjait szabadítsák rá, 300 dolláros órabérrel. Bár a tanácsadószoftver dobozos szoftvernek van álcázva, az implementáció magas költsége alapján inkább belső szoftvernek minősül.

A kereskedelmi webalapú szoftver, mint a Salesforce.com, vagy az eBay változatok még mindig igénylik a könnyű kezelhetőséget, és hogy minden böngészőn fussanak. Bár a fejlesztők megengedhetik maguknak azt a luxust, hogy (legalább egy kicsit) ellenőrizhessék a telepítési környezetet – a számítóközpontban levő gépeket –, kezelniük kell a böngészők széles skáláját, és a felhasználók nagy számát, így ezt én a dobozos szoftver kategóriájába sorolom.

A belső szoftvernek csak egy cég számítógépein kell futnia, ugyanolyan szituációban. Ezt lényegesen egyszerűbb fejleszteni. Számos olyat feltételezhetsz, ami a futási környezettel kapcsolatos. Megkövetelheted az Internet Explorer, a Microsoft Office, vagy akár a Windows egy verzióját. Ha grafikont akarsz csinálni, arra ott lesz az Excel. Nálunk mindenkinek van Excelje. (Ám próbálnád ugyanezt a dobozos szoftverednél, és már el is vesztetted a potenciális vásárlóid felét.)

A használhatóság kevésbé fontos, mivel csak meghatározott számú felhasználónak kell a programot használnia, és ők sem választhatnak másik szoftvert maguknak. A fejlesztési sebesség sokkal fontosabb. Mivel a fejlesztési költségek csak egy cégen belül oszlik el, az elosztható fejlesztési erőforrások is lényegesen kevesebbek. A Microsoft megengedheti magának, hogy ötszáz millió dollárt költsön egy operációs rendszer fejlesztésére, ami egy átlagembernek csak 80 dollárjába kerül. Ám amikor a Detroit Edison energiakereskedelmi szoftvert fejleszt, a befektetésnek ésszerűnek kell lennie az egész társaságnak. Értelmes ROI eléréséhez nem költhetsz annyit, amennyit egy dobozosra költenél. Így sajnos a belső szoftverek nagyon csúnyák.

A beépített szoftverek annyiban egyediek, hogy egy hardverbe kerülnek, és szinte sosem frissíthetők. Ez egy teljesen más világ. A minőségi követelmények itt sokkal magasabbak, mert nincs második lehetőség. Valószínűleg lényegesen lassabb processzorral kell dolgoznod, így sokkal több időt kell szánnod optimalizálásra. A gyorsaság lényegesebb, mint a kód szépsége. Kevesebb be- és kimeneti eszköz állhat rendelkezésre. A múlt héten bérelt autómban a GPS rendszer IO rendszere annyira szánalmas volt, ami szinte teljesen használhatatlanná tette. Próbáltál már ilyen ketyerén beírni egy címet? Megjelenik a képernyőn egy „billentyűzet”, és a nyilakkal kell kiválasztani az öt, egyenként 9 karaktert tartalmazó mátrixból a betűket (a link további illusztrációkat tartamaz a felhasználói felületről. A saját kocsimban levő GPS érintőképernyős, ami a felületet remekül feldobja. Ám elkalandoztam).

A játékok két okból kifolyólag egyediek. Előszöris a játékfejlesztések ökonómiája sikerorientált. Néhány játék sikeres lesz, de sokkal több van bukásra ítélve. Ha pénzt akarsz keresni a játékpiacon, jó, ha ezt felismered, és tartasz néhány sikeres játékot a portfóliódban, hogy a kirobbanó siker nyeresége fedezze a megbukott játékok veszteségeit. Ez inkább a filmszakmához hasonlít, mint szoftvereshez.

A játékfejlesztések nagyobb problémája az, hogy itt is csak egy verziód van. Ha már egy felhasználód végigjátszotta a Duke Nukem 3D-t, nem fog a Duke Nukem 3.1D-re frissíteni csak néhány hiba és pár új fegyver miatt. Néhány kivételtől eltekintve ha valaki már végigjátszott egy játékot, már unni fogja az újra játszást. Így a játékoknak ugyanolyan minőségi követelményeik vannak, mint a beépített szoftvereknek, és hihetetlen nagy pénzügyi szükséglet, hogy elsőre jó legyen. A dobozos szoftverek fejlesztőinek megadatott az a luxus, hogy ha az 1.0-ás verzió nem felelt meg az emberek igényeinek, a 2.0-s talán meg fog.

Végül az egyszer használatos kód az, amit csak azért ácsolsz össze ideiglenesen, hogy valami mást elérj, amit nagy valószínűséggel sosem kell többet használnod, miután azt a valamit elérted. Például írhatsz egy olyan kis shell szkriptet, ami egy bemeneti fájlt úgy masszíroz meg, hogy az olyan formátumba kerül, amit már valami más program már fel tud dolgozni.

Lehetnek még olyan szoftverfajták, amiket kifelejtettem.

Egy fontos dolgot tudnod kell: amikor olyan könyveket olvasol programozási metodológiákról, amiket egy teljes munkaidős szoftverfejlesztő guru / konzulens írt, szinte teljesen biztos, hogy belső céges szoftverfejlesztésről ír. Nem dobozos termékről, nem beépített szoftverről, és biztos, hogy nem játékról. Hogy miért? Mert a cégek bérlik fel ezeket a gurukat. Ők fizetik a számlát (hidd el, az id software nem fogja felvenni Ed Yourdon-t, hogy a struktúrált analízisről beszéljen).

Múlt héten Kent Beck azt állította, hogy valójában nincs is szükség hibakövető adatbázisokra, ha Extrém Programozást használsz, mert a páros programozás (folyamatos kódvizsgálattal) és a teszt-irányított fejlesztés (ami garantálja, hogy az automatikus tesztek 100%-osan lefedik a kódot) azt eredményezi, hogy nem lesz egy hibád sem. Ez valahogy nem tűnt igaznak a szememben. Bele is néztem a saját hibakövető adatbázisunkba, mi is az, ami elfoglal minket.

Na lám csak, azt vettem észre, hogy nagyon kevés hibát vettünk volna észre páros programozással, vagy teszt-irányított fejlesztéssel. A legtöbb „hibánk”, amit XP-ben történetnek hívnak tulajdonképpen fejlesztési kérések. A hibakövető rendszert egyszerűen arra használjuk, hogy ne felejtsük el, priorizáljuk, és menedzseljük azokat az apró csiszolásokat és nagy funkciókat, amiket ki akarunk fejleszteni.

Sok más hiba pedig csak akkor került a felszínre, amikor már a „mezőkön” régóta használták. A lengyel billentyűzet dolog. Ezt páros programozással lehetetlen észrevenni. Aztán azok a logikai tévedések, amik nálunk sosem jöttek elő úgy, ahogy a különböző funkciók együttműködnek. Minél nagyobb és bonyolultabb egy program, annál több a párbeszéd olyan funkciók között, amire nem is gondolsz. Egy bizonyos nem várt karaktersorozat (ha tudni akarod, a „{${?” az) összezavarja a lexert. Néhány ftp kiszolgáló hibát generál, ha egy olyan fájlt akarsz törölni, ami nem is létezik (a mi ftp kiszolgálónk nem kiabál, így ez elő sem fordult nálunk).

Figyelmesen végigtanulmányoztam az összes hibát. 106 hiba közül, amit a CityDesk szervízcsomag kiadásában megjavítottunk, pontosan ötöt tudtunk volna páros programozással, vagy teszt-vezérelt tervezéssel kivédeni. Sokkal több hibánk volt olyan, amikről tudtunk, amikről úgy gondoltuk, nem fontosak (kivéve persze a vásárlóinkat!), mint olyanok, amiket az XP módszerrel kivédhettünk volna.

Ám Kent-nek igaza van a másik fajta fejlesztésben. A legtöbb céges fejlesztésű alkalmazásnál ezek egyike sem lett volna hiba. A program lefagy érvénytelen bevitelkor? Futtasd újra, de ezúttal figyelj a {${?-kre! Aztán úgyis csak egy fajta ftp kiszolgáló lesz, és a cégben senki sem fog lengyel Windows-t használni.

A szoftverfejlesztés legnagyobb része ugyanaz, akármiféle projekten is dolgozol, de nem teljesen. Ha valaki metodológiáról beszél, gondolkodj el azon, hogy ez hogy hatna a te munkádra. Gondolkodj el azon, hogy milyen környezetben is van a másik. Steve McConnell, Steve Maguire, és jómagam egy nagyon szűk sarokból jövünk: a dobozos tömegcikk táblázatkezelő alkalmazások világából, amit Redmondban, Washington államban írtak. Nálunk magasabb a léc az egyszerű használatnál, és alacsonyabb a hibáknál. Az összes többi módszertan guru azzal keresi a betevőt, hogy konzultál saját céges fejlesztéseknél, és ők erről is beszélnek. Bárhogyis, mindannyian tudnunk kellene tanulni egymástól.

Forrás: http://js.hu/jos/

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!