írta: Sólyom-Nagy Péter
A dokumentum letölthető PDF formátumban.
Bevezetés
Szakmai munkám során sokféle módszertant kipróbáltam már, mindenből tanultam egy kicsit, a praktikus dolgokat átemeltem más környezetbe is. Ezek alapján összeállítottam egy rövid vázlatot arról, hogy hogyan érdemes egy komplex rendszer tervezésekor az alapokat elkészíteni.
Nincs tökéletes módszertan, ami minden fejlesztésnél egységesen meghozza a várt eredményt, ezért ennek az írásnak nem is célja az „aranycsinálás” definiálása. Ez a cikk egy a sok közül, ami támpontot nyújt azoknak, akik újak ezen a téren, vagy bővíteni szeretnék tudásukat.
Én ha elakadok, az internetet kezdem el böngészni segítségért. Ilyenkor jól jön, ha találok egy fórumot, vagy egy olyan írást, ami kifejezetten a problémámmal foglalkozik.
Mivel a munkáim során elsősorban adatbázis alapú, többfelhasználós rendszerekkel dolgoztam, ez az írás is ezt a vonalat fogja követni.
A feladat megfogalmazása
Az első legfontosabb feladat, hogy tisztán lássuk a rendszerrel szemben támasztott elvárásokat. Egy kis alkalmazásnál, amit magunknak készítünk talán ez a lépés nem olyan fontos, de egy összetettebb rendszernél ez már elengedhetetlen. Ez különösen igaz, ha a projekten többen dolgoznak.
Bővebben
Tervezés
Ha ismert a feladat, nekiláthatunk a tervezésnek. Tervet azért kell készíteni, hogy mindig legyen egy kapaszkodó, ami vezet a fejlesztés során. Ha nincs terv, az embernek menet közben sokminden eszébe jut és lehet, hogy másik irányba indul el, mint az eredeti cél. A tervvel ezt valamennyire kordában lehet tartani. Természetesen az új ötletek között hasznosak is lehetnek, de ilyenkor vissza kell térni a tervezéshez, és úgy kell beilleszteni az újítást, hogy a rendszer integritása minél kevésbé sérüljön.
Sokféle tervezési módszer van, ezekről sok írás található az interneten. A véleményem az, hogy mindenkinek ki kell alakítani a saját módszerét. A lényeg, hogy működjön.
Tervezés adatbázissal
Az én módszerem, hogy a feladat ismeretében elkezdem tervezni az adatbázist. Ezzel lehet vitatkozni, de a gyakorlatban bevált. Persze ehhez szükséges némi rutin abban, hogy egy-egy objektum a felhasználói paramétereken kívül milyen technikai paraméterekkel kell, hogy rendelkezzen. Ilyen például az egyedi azonosító, annak típusa, az objektumok közötti reláció jellege, vagy a szabályok érvényessége.
Néhány ökölszabály
Azzal, hogy elkezdem létrehozni a táblákat, egyben kialakul egy kép a rendszer működéséről is.
Fejlesztés
A terv birtokában neki lehet kezdeni a fejlesztésnek. A fejlesztés alatt íródik a kód, itt alakul ki maga a rendszer. Ha jó tervet készítettünk, a fejlesztés már csak egy forgatókönyvet hajt végre. A valóság persze nem mindig így van?
A lépések sorrendisége
A tapasztalatok azt mutatják, hogy a gyakrolatban a tervezés közben már elég sok kód íródhat, ami nem baj de figyelni kell arra, hogy ez ne korlátozzon. Ha menet közben kiderül, hogy a tervezett út nem járható, merjünk visszanyúlni az alapokig és teljesen újragondolni a tervet, ne akadályozzon, ha már kidolgoztunk néhány metódust.
Az alapos tervezés csökkenti a kompromisszumos megoldásokat, ami hatékonnyá teszi a rendszer működését.
Konvenciók
Mindenkinek megvan a saját fejlesztési stílusa. Ez értendő a kód elrendezésére, a logikai felépítésre, de a rendszer egészére is. A konvenciók abban segítenek, hogy egységes, átlátható legyen a forráskód és a rendszer működése.
Teljesen mindegy, hogy milyen alapszabályokat határozunk meg, de különösen csoportos fejlesztésnél, a szabályokat igyekezzünk mindig betartani. Konvenciók nélkül a kód utólag sokkal nehezebben értelmezhető, mert újból „meg kell tanulnunk”, hogy eredetileg mi szerint neveztük el a változókat.
A konvenciók a forráskódban vonatkozhatnak a változók elnevezésére, a definíciók, metódusok sorrendjére, vagy bármi egyébre, ami a rendezettséget segíti. Nem szabad azonban túlzásokba esni. A konvenciók a munka segítésére, nem a bonyolítására vannak kitalálva. Semmi értelme például annak, hogyha megkötjük, hogy a változók neve tartalmazza a létrehozás dátumát is.
Kommentelés, megjegyzések
Minden programnyelvben van lehetőség megjegyzés beszúrására a kódba. Ezt használjuk is ki.
Szakértők szerint akkor jó egy forráskód kommentelése, ha a kommentek a teljes forráskód 20-30 százalékát teszik ki. Gyakorlati tapasztalat, hogy nem lehet túlkommentezni egy kódot. Komplex metódusokban sokszor az is előfordul, hogy a forráskód minden második sora komment.
Bővebben
Tesztelés
Az elméleti fejlesztési szabályok szerint a fejlesztést követi a tesztelés, de a gyakorlatban a tesztelés már menet közben kell, hogy elinduljon. Én ha megírok egy metódust, azonnal látni akarom, hogy jó-e, amit írtam. Ha csak a végén tudom kipróbálni, már nem biztos, hogy emlékezni fogok, mit-miért írtam.
Persze egy összetett műveletsort, vagy feldolgozó folyamatot a legvégén is ellenőrizni kell. A tesztelésnek két fő változata van; a fejlesztői teszt és a felhasználói teszt.
A fejlesztői teszt elsősorban a fejlesztő szemszögéből kell, hogy történjen. A fejlesztő azt tudja, hogy a kódja milyen logikát követ, vagyis azt kell kipróbálnia, hogy az egyes elágazások mindegyike helyesen működik-e, a követelményeknek megfelel-e.
A felhasználó már csak akkor fog tesztelni, amikor a rendszer (vagy az adott modulja) összeállt és a felhasználó is tudja már rendeltetésszerűen kezelni. A felhasználó nem ismeri a rendszer logikáját, őt csak az érdekli, hogy az ő elképzelése szerinti eredményt hozza. Ő a napi gyakorlatot fogja követni, vagyis olyan adatokkal fog tesztelni, amik életszerűek.
Meglepő lehet, hogy néha a felhasználó képes olyan hibákat kihozni, amik a fejlesztőnek eszébe sem jutnak.
Én nem is ezt akartam...
Dokumentáció
Ahhoz, hogy a rendszer teljes legyen, dokumentálni kell. A dokumentáció készítését sokszor elhanyagolják, pedig nagyon hasznosak.
A dokumentáció részletességét, mennyiségét nem lehet általánosan megkövetelni, ez függ a cégen belüli szokásoktól, illetve az adott projekttől. Ha van egy jól bevált rendszer, nyugodtan kövessük!
A fejlesztés elején célszerű egy rövid dokumentumot írni arról, hogy milyen indíttatásból kezdünk bele egy fejlesztésbe. Ebben le kell írni, hogy kinek fejlesztünk, és mi a fő célja a rendszernek. A részletek itt nem fontosak, csak a fő irány.
A részleteket egy újabb dokumentumban kell összefoglalni. Ahhoz, hogy a feladat adott legyen, előbb fel kell mérni a jelenlegi állapotot. Nagyon leegyszerűsítve a felhasználónak vázolnia kell;
- Mik a kiinduló adatok
- Milyen eredményt várunk az új rendszertől
- Az eredményhez milyen algoritmussal juthatunk el
Ez persze egy igen durva megközelítés. A rendszer feladata sokféle lehet;
- a bemenő adatok transzformálása más rendszerek felé
- az adatok tárolása, kimutatások készítése
- rendszeres adatszolgáltatás
- ezek kombinációja
A fentieken kívül minden olyan információt rögzíteni kell, ami befolyásolhatja a fejlesztés menetét, vagy a rendszer üzleti logikáját. Rögzíteni kell a külső tényezőket is, mint például;
- milyen jelenlegi rendszert használnak, ha van
- a jelenlegi rendszerből kell-e adatot átvenni (migráció)
- kik fogják használni a rendszert
- hányan fogják használni a rendszert
- milyen környezetben kell a rendszert megvalósítani
- mekkora adatmennyiséggel kell számolni
A felmérés jegyzőkönyve az egyik legfontosabb dokumentum.
Tovább
Utószó
Az itt leírtak nem általános aranyszabályok, ezek az én gondolataim. A fejlesztési projektekben ezeket a módszereket követem és hasznosnak találom.
A célom az, hogy segítséget nyújtsak másoknak. Ha valakinek sikerült utat mutatni, már elértem a célom.
Habár körültekintően próbáltam fogalmazni, előfordulhatnak hibák a gondolatmenetben. Ha a kedves Olvasó úgy gondolja, hogy tévedtem, szívesen fogadom a kritikát.
2010. január
Ez a dokumentum elsősorban oktatási célokat szolgál. A dokumentum ilyen jellegű felhasználása a forrás megjelölésével megengedett. Üzleti célú felhasználása csak a szerző írásbeli hozzájárulásával lehetséges.
Copyright © Sólyom-Nagy Péter