Mitől jó egy
program? |
Érdekes kérdés, és ha így valaki hozzámszegezi, hát akkor nagyon nagy a
valószínűsége, hogy nagyot fogok nézni, és miután túljutottam a
legelső megrökönyödésen, hát (mivel még mindig nem jutok szóhoz a
csodálkozástól) legfeljebb megkérdem milyen programra gondolt. A kérdés
annyira tág fogalomkört ölel fel, hogy szinte lehetetlen egy általánost
választ adni rá. Miért van, hogy
egyes programok sikerkarriert futnak be, míg mások, melyek (szinte) ugyanazt
a szolgáltatást nyújtják, eltűnnek a süllyesztőben. És itt nem
feltétlenül gondolok arra, hogy az egyes programok szolgáltatásai jobban
vannak leprogramozva, míg másoknál a szolgáltatás színvonala nincs annyira
kidolgozva. Miért ragaszkodnak a felhasználók mégis körömszakadtukig egyes
programokhoz, annak ellenére, hogy más programok is nyújtják ugyanazokat a
szolgáltatásokat, sőt talán többet is. Ez a
cikksorozat a felhasználók szemszögéből fogja szemügyre venni, hogy
„mitől is jó egy program”. Remélhetőleg hasznos útmutató lesz a
programozó kollégáknak, hogy ne kövessenek el egyes hibákat, melyek az évek
során súlyos következményeket vontak maguk után egyes programok piacra dobása
esetén. A cikk tűzdelve lesz példákkal is, természetesen programnevet
nem fogok említeni, hogy cikkem senkit ne sértsen meg. |
A három futtatás szabálya és más
érdekességek |
Nagyon kevés programozó ír programot, melyet más programozók fognak
használni, ezért ha valaki igazán sikeres programot szándékszik készíteni,
akkor meg kell tanulnia egy felhasználó nézőpontjából tekinteni a
világra. A felhasználók más szemekkel tekintenek a programunkra mint ahogy mi
tesszük, hisz mi fejlesztjük, tudjuk, hogy mit miért raktunk oda, ahová
raktunk, előre tudjuk, hogy mi fog történni, ha megnyomunk egy bizonyos
gombot, hogy melyik rutinra fog ugrani. A felhasználónak meg kell tanulnia
használni a programunkat, és (ez már saját tapasztalat is) ha általában a
harmadik elindításkor még mindig gondjaim vannak egy programnak a
kezelésével, akkor harag ne legyen, de mást keresek, és nagy valószínűség
szerint találok is. Lehet, hogy szolgáltatásaiba nem lesz olyan mélyre
menő, mint előző programom, de ha a kezelhetőségben veri
azt, akkor nekem, mint felhasználónak megérte a váltást. Alkalmam nyílt
kipróbálni két Offline Browser programot (amelyek teljesen letöltenek
bizonyos honlapokat), és érdekességképen említem meg a következő esetet:
Mind a kettő úgynevezett projektet készített, amely általában a honlap
nevét tartalmazta, természetesen ez változtatható volt, de ez nem lényeg. Az
a program, amelyet először kipróbáltam rögtön az ismerős [Finish]
gomb megnyomása után kezdte el letölteni az oldalt. És én ezt nagyon
természetesnek vettem, hisz ezt is akartam: letölteni egy oldalt. A
programnak nem voltak szuper szolgáltatásai, egyszerűen letöltötte az
oldalt, és lementette egy könyvtárba. A második
program miután végigvezetett egy sor kérdésen, amelyeknek az én szempontomból
nem voltak jelentőségei (hogy miket töltsön le, link mélység, satöbbi)
azt mondta, hogy a projekt kész, és bezárta a Varázsló ablakot. Én meg csak
néztem, hogy mikor kezdi már el a letöltögetést, hisz nem volt időm a
végtelenségig várni, és nagyon kellet volna már az oldal. Majd lezártam a
programot, gondolván, hogy majd amikor indul, akkor fogja elindítani a
letöltéseket. Hát csalódtam. Végül nagy nehezen megtaláltam a rengeteg
kezelőszerv közt a letöltést elindító gombot. Mondanom se kell, hogy
első csalódottságomba messze hajítottam a második programot, és maradtam
az elsővel, amelynek szinte semmi szolgáltatása sincs pluszban, csak egyszerű
oldalletöltő. A felhasználók
azt várják el egy programtól, hogy azt csinálja, amit a neve ígér. Ha egy
program neve azt mondja a felhasználónak, hogy erre írtak akkor fő szolgáltatásként ezt kell nyújtania, és a felhasználónak ezt nem a szolgáltatások tömkelegében kell megtalálnia, hanem
rögtön az első lépéseknél kell tudatni vele, hogy igenis, ezt így és itt lehet megtenni. Egy
programot lehessen könnyen kezelni. Néha van, hogy
egy programot nem használunk többet, mert a harmadik futtatás után még mindig
nem világos számunkra, hogy milyen funkciói vannak, részletes segítséget nem
adtak mellé, hisz a programozónak nyilvánvaló volt, hogy mit fog tenni, ezért
csak sündisznófarknyi magyarázatot fűzött egyes kezelőszervek
működéséhez. Találkoztam egy
sakk programmal, amelynél a menüjébe ott volt a sokat sejtető „Delete
Tree” menüpont. Mivel az adatott meg, hogy ezt a programot nekem kellett
tovább fejlesztenem, hát írtam a régi fejlesztőnek, írja már meg
postafordultával, hogy mit jelent az ő szemszögéből ez. A válasz
valahogy így hangzott: a pRoot-ból kitörli a pCurItem utáni alfát. Ez neki
teljesen nyilvánvaló volt hogy a program ezt fogja csinálni, hisz ő
írta, viszont bennem csak sorakoztak a kérdőjelek. Miután mélyebbre
ástam a forrásba, megtaláltam, hogy a pRoot illetve pCurItem egy TMoveTree
osztályra mutató pointer. Miután ezzel se
lettem sokkal okosabb, hát elkezdtem tesztelgetni, hogy valójában mi is fog
történni a programmal, ha a játszma különböző fázisaiban kattintgatok
erre a menüpontra. És rájöttem, hogy n visszalépés (Undo) esetén törli az
aktuális lépés utáni lépéseket (vagyis a Redo lehetőséget), úgy, hogy a
játékos többé nem tud előre ugrálni a lépéssorozatban. A programozónak
teljesen nyilvánvaló volt, hogy mi fog történni, viszont egy felhasználónak
bizony gondjai akadtak a helyes értelmezésével. Egy felhasználónak nem
kötelessége ismernie adatstrukturáinkat, őt csak az érdekli, hogy tudja,
hogy a program működik, és lehetőleg minél kevesebb
energiaráfordítással a lehető legjobb eredményeket hozza ki a
lehető legrövidebb idő alatt. Egy program legyen érthető.
Mindenki számára. Megint
visszatérek az első példámhoz. Mindkét program Threadeket hozott létre a
letöltést felgyorsítandó, és mindkét programban volt egy mechanizmus, mely
kiírta, hogy az aktuális Thread éppen hol tart. Az egyik programban egymás
alatt, aránylag nagy képernyőterületet elfoglalva ott volt a nyolc darab
Thread, és látam, hogy az egyes Thread épen hozza az index.htm fájlt és ennyi
töltődött le ennyiből, ez meg ennyi százaléknak felel meg, a kettes
a background.gif-el küszködik, és így sorban. A másik program
az ablak Status Linejaba írta ki a letöltésről szóló információkat, ott
viszont csak egy sor van, és ezért aránylag gyorsan cserélődtek a nyolc
Thread fent említett adatai, és én egy idő múlva kezdtem elveszteni a
fonalat, és teljesen belezavarodtam, hogy hol is tart a letöltésem. A
felhasználók szeretnek egy összképet látni arról, hogy a program amit
használnak hol is tart, főleg ha időigényes munkával bízták meg a programot. Viszont vannak
esetek, hogy a programot könnyen is lehet kezelni, világos is minden
funkciója, és mégsem sikeres. Hiába vonogatja a programozó a vállát: hisz
szerintem nyilvánvaló. Ott van minden funkció a ToolBaron, mindig látja az
összes funkciót, ha meg akar nyitni valamit kattint az első gombra, ha
menteni akar a másodikra, ha be akarja állítani hogy a lementendő kép
színmélysége 24 vagy 32 bit legyen, akkor a tizenhetedik gombra, én igazán
nem tudom miért nem sikeres a program, hisz látjátok én mindent megtettem,
hogy tudják használni. A
következő részben a kezelőfelületeket vesszük szemügyre. |
Deák Ferenc |