Grafikus C# – Windows Forms tanfolyam › 15.7 lecke Tanfolyamzáró · 15.7 lecke · saját projekt Eljutottál a tanfolyam végére. A tanultak igazi próbája nem egy újabb gyakorlat, hanem egy saját projekt: olyan program, amelyet te találsz ki, tervezel meg, építesz fel, tesztelsz, és kiadsz. Itt kezdődik az igazi programozás: nincs megoldókulcs, te hozod a döntéseket, és te felelsz az eredményért. Ebben az utolsó leckében segítek a választásban (ötletkatalógus három szinten), a tervezésben (követelmények, felület, rétegek, ütemterv), az értékelésben (100 pontos rubrika) és a munkamódszerben (verziókezelés, mérföldkövek, tesztelés, kiadás). A „mini projekt” ezúttal a projekttervedet kéri: egy jó terv a projekt felét megnyeri.Önálló záróprojekt ötletek
A lecke végére
- kiválasztasz egy megvalósítható projektötletet a saját szintedhez;
- megírod a követelményeket (kötelező, kívánatos, később), és meghatározod, mi nem része a projektnek;
- megtervezed a felületet, a rétegeket és az adatokat;
- ütemtervet és mérföldköveket készítesz, és verziókezelővel dolgozol;
- ismered az értékelési szempontokat, és ahhoz igazítod a munkádat;
- megtervezed a tesztelést, a kiadást és a bemutatót;
- tudod, merre tanulj tovább.
Mielőtt elkezded
Ehhez a leckéhez a teljes tanfolyam anyaga szükséges, leginkább a 12. fejezet (tervezés, rétegek), a 13. fejezet (hibakeresés, tesztelés) és a 14. fejezet (kiadás).
Hogyan válassz projektet?
Jó projekt ismérvei
- Érdekel: hetekig fogsz vele foglalkozni; a lelkesedés a legjobb lendület.
- Valós igény van rá: te, egy barátod, az osztály vagy egy tanár tényleg használná.
- Kicsiben kezdődik: az első változat 2–3 hét alatt működik, és utána bővíthető.
- Használja a tanultakat: űrlapok, események, osztályok, fájl- vagy adatkezelés, hibakezelés.
- Mérhető: egyértelmű, mikor kész („ha ez a hét dolog működik, kész”).
- Kicsit kihívás: legyen benne valami új, amit még nem csináltál.
Gyakori csapdák
- Túl nagy ötlet: „saját játékmotor”, „közösségi oldal”: nem fejezhető be.
- Másolás: egy kész program lemásolása nem tanít: építs rá saját ötletet, vagy kicsinyítsd le.
- Funkció-halmozás: sok félkész funkció helyett kevés, de jó.
- Adat nélküli ötlet: ha nincs adat, amit kezel, gyakran nincs mit tervezni.
- Külső függőség a végén: a kulcsok, hálózat, engedélyek a legkockázatosabb részek: ezeket vizsgáld meg először.
- A felület utolsó napra hagyása: a használhatóság a program fele.
Ötletkatalógus három szinten
Az ötletek kiindulópontok: válassz egyet, és szabd a saját érdeklődésedre és szintedre. Az „alap funkciók” az első, használható változat; a „bővítés” a továbbfejlesztés.
| Ötlet | Alap funkciók | Bővítés | Fő témák |
|---|---|---|---|
| 🟢 Alap szint (3–4 hét) | |||
| Jegyzetfüzet | Több jegyzet, cím és szöveg, mentés fájlba, keresés a jegyzetekben. | Kategóriák, színek, exportálás, jelszóval védett jegyzet. | Vezérlők, fájlkezelés, JSON, események |
| Tanulókártya (flashcard) program | Kártyapakli létrehozása (kérdés–válasz), kikérdezés, jó/rossz számlálás. | Ismétlési rendszer (a rosszul tudott gyakrabban), statisztika diagramon. | Osztályok, gyűjtemények, JSON, diagram |
| Házipénztár / költségvetés | Bevételek és kiadások felvétele kategóriával, egyenleg, havi összesítés. | Diagram kategóriánként, CSV-export, költségkeret-figyelmeztetés. | DataGridView, LINQ, CSV, grafikon |
| Teendőlista emlékeztetővel | Feladatok határidővel, késés jelzése, kész/nem kész. | Értesítés (NotifyIcon), ismétlődő feladat, tálca-ikon. | Timer, NotifyIcon, DateTime, fájlkezelés |
| 🟡 Közepes szint (4–5 hét) | |||
| Osztálynapló / jelenléti ív | Osztályok, diákok, jelenlét naponta, hiányzási statisztika (adatbázissal). | Jegyek, átlag, nyomtatható jelentés, import névsorból. | SQLite, rétegek, bevitel-ellenőrzés, jelentés |
| Játék (memória, akasztófa, kígyó, 2048) | Játékszabály, kirajzolás, billentyű- vagy egérvezérlés, pontszám. | Ranglista fájlban, szintek, hang, mentett állás. | GDI+ rajzolás, Timer, billentyűkezelés, OOP |
| Receptkönyv | Receptek hozzávalókkal, keresés, kedvencek, adag-átszámolás. | Bevásárlólista-generálás, kép a recepthez, import/export. | Adatbázis vagy JSON, LINQ, keresés, ListView |
| Edzés- vagy tanulásnapló grafikonnal | Napi bejegyzés (időtartam, típus), heti/havi összesítés, grafikon. | Célok, sorozat (streak) számlálás, jelentés exportja. | Diagram, DateTime, adatkezelés, statisztika |
| Mini képszerkesztő | Kép megnyitása, szűrők (szürkeárnyalat, fényerő), mentés. | Visszavonás (undo), rajzeszközök, vágás. | Bitmap, GDI+, parancs-minta, teljesítmény |
| 🔴 Haladó szint (5–6 hét) | |||
| Készletnyilvántartó (WPF, MVVM) | Termékek, mennyiség, bevételezés/kiadás, alacsony készlet jelzése. | Vonalkód-beolvasás, szerepkörök, CSV/PDF jelentés. | WPF, MVVM, adatkötés, adatbázis |
| Webszolgáltatást használó kliens | Nyilvános adat (árfolyam, időjárás, könyvadatbázis) lekérése, megjelenítése, gyorsítótár. | Értesítések, kedvencek, előzmények diagramon. | HttpClient, JSON, async, hibatűrés, titkok kezelése |
| Kliens–szerver nyilvántartó | Saját ASP.NET Core API (15.5) és Windows Forms kliens (15.6) közös adattal. | Hitelesítés, több felhasználó, szinkronizálás. | API, HttpClient, rétegek, biztonság, kiadás |
| Bővíthető (plugin) program | Alapprogram + betölthető kiegészítők közös interface-szel (például több fájlformátum-importáló). | Kiegészítők dinamikus betöltése, beállítófelület. | Interface, tükrözés, DI, tesztelés |
Tervezési útmutató: a követelménytől az ütemtervig
A tervezés hat lépése
- Cél és felhasználó: egy mondatos cél; kinek készül; mi a probléma.
- Követelmények (MoSCoW): Must, Should, Could, Won't lista; legfeljebb 7–10 Must.
- Felületterv: a főablak és a fontos ablakok vázlata (papíron vagy a Designerben); navigáció; üzenetek.
- Adatok: milyen adatot kezelsz, hol tárolod (fájl, adatbázis: 14.7 lecke), milyen formában.
- Szerkezet: osztálytérkép (modell, szolgáltatás, tároló, felület: 12. fejezet), a rétegek közti interface-ek.
- Ütemterv és tesztterv: heti mérföldkövek; mit teszteltek; mikor és hogyan adod ki.
Egy jó követelmény
- Egyértelmű: „A felhasználó új kártyát vehet fel kérdéssel és válasszal”, nem „kényelmes legyen”.
- Ellenőrizhető: el lehet dönteni, hogy teljesül-e (tesztelhető).
- Egyetlen dolgot ír le (nem „felvesz és töröl és keres”).
- Felhasználói szemszögű: mit tehet a felhasználó, nem hogyan csinálod.
- Számmal és példával pontosítva: „legfeljebb 40 karakter”, „1–5 jegy”.
CÉL: A program a nyelvtanulóknak segít szókártyákat kezelni és gyakorolni.
KINEK: Saját magam és az osztálytársaim.
KÖVETELMÉNYEK
MUST: M1 pakli létrehozása névvel
M2 kártya felvétele (kérdés, válasz; legfeljebb 100 karakter)
M3 kikérdezés: a kérdés látszik, kattintásra a válasz, majd Tudtam / Nem tudtam
M4 a pakli mentése fájlba, újraindításkor betöltés
M5 hibás bevitel esetén érthető üzenet
SHOULD: S1 statisztika (hány kártyát tudtam), S2 keverés
COULD: C1 diagram a haladásról, C2 export CSV-be
WON'T: W1 online szinkron, W2 hang
FELÜLET: főablak (paklilista, gombok), szerkesztő ablak, kikérdező ablak (vázlat mellékelve)
ADATOK: JSON fájl a %AppData%\Tanulokartya mappában (14.7 lecke)
SZERKEZET: Models (Kartya, Pakli) · Services (PakliTarolo: Mentes/Betoltes, Kikerdezo) · App (Form-ok)
ÜTEMTERV: 1. hét terv + váz · 2. hét modell és tároló · 3. hét felület · 4. hét hibakezelés, teszt · 5. hét kiadás, dokumentáció
TESZT: tesztterv 20 esettel (13.8 lecke): üres pakli, hosszú kérdés, sérült fájl, ...
KIADÁS: ZIP + telepítő, README, Névjegy, verzió 1.0.0 (14. fejezet)Jósolj!
A projekt tervezésekor 25 „Must” követelményt írsz fel, mert „mind fontos”. Mi lesz a 3. hét végén?
Jóslat ellenőrzése
Sok félkész funkció, egyik sem teljesen jó, és nincs idő a hibakezelésre és a kiadásra. A Must lista a legkisebb használható program: legfeljebb 7–10 elem. Ami nem létfontosságú, Should vagy Could: az maradjon a végére, ha van idő.
Értékelési rubrika (100 pont)
| Szempont | Pont | Mit nézünk? |
|---|---|---|
| Terv és követelmények | 10 | Egyértelmű cél, MoSCoW lista, felületterv, osztálytérkép, ütemterv, tesztterv; a terv és a kész program összhangja. |
| Funkcionalitás | 20 | A Must funkciók hiba nélkül működnek; a Should/Could bővítések minősége. |
| Felület és használhatóság | 10 | Átlátható, következetes felület; billentyűzetes használat; érthető üzenetek; méretezhetőség; akadálymentesség (6. fejezet). |
| Kódminőség és szerkezet | 15 | Felelősségek szétválasztása (12. fejezet), jó nevek, rövid metódusok, nincs ismétlődő kód, megfelelő hozzáférési szintek. |
| Hibakezelés és bevitel-ellenőrzés | 10 | Érvénytelen, üres, szélsőérték bevitel; fájl- és hálózati hibák; globális hibakezelő (13. fejezet). |
| Adatkezelés | 10 | Megfelelő tárolás és hely (14.7 lecke), biztonságos mentés, séma-kezelés, nincs adatvesztés. |
| Tesztelés és hibakeresés | 10 | Tesztterv és eredmények, hibajegyek, naplózás, regressziós futtatás, a talált hibák javítása (13. fejezet). |
| Kiadás és dokumentáció | 10 | Működő csomag vagy telepítő, README, Névjegy és verzió, licenc, tiszta gépes próba (14. fejezet). |
| Bemutató és reflexió | 5 | Világos bemutató, élő demó vagy videó, őszinte értékelés: mi sikerült, mi nem, mit tanultál. |
Munkamódszer: verziókezelés, mérföldkövek, bemutató
git init (a mappa verziókezelt tárolóvá válik)
dotnet new gitignore (.gitignore: a bin, obj és a generált fájlok kimaradnak)
git add .
git commit -m "Kezdő váz: solution, Core és App projekt"
git status (mi változott?)
git diff (mi a pontos változás?)
git log --oneline (a történet röviden)
git switch -c kartya-szerkeszto (új ág egy új funkcióhoz)
git switch main (vissza a fő ágra)
git merge kartya-szerkeszto (az ág beolvasztása)Mit ad a verziókezelés?
- Biztonsági háló: bármikor visszatérhetsz egy működő állapothoz.
- Történet: látod, mikor és miért változott a kód; a hibák okát is könnyebben megtalálod.
- Bátor kísérletezés: új ágon próbálsz, és ha nem jó, eldobod.
- Együttműködés: páros munkánál a változások egyesíthetők.
- Kiadás-címke: a kiadott verzió pontos forrása megmarad (14.9 lecke).
Jó commit-szokások
- Kis, önmagában működő lépések (nem a hét végén egyetlen óriási commit).
- Érthető üzenet: mit és miért („Üres név ellenőrzése a pakli-szerkesztőben”).
- Nem commitolsz titkot (kulcs, jelszó), generált fájlt (
bin,obj) és személyes adatot. - Minden mérföldkőnél címke vagy külön commit: „2. hét: modell és tároló kész”.
- Rendszeresen (naponta) mentsd távoli tárolóba is (felhőalapú Git-szolgáltatás): a gép meghibásodása ellen.
Jósolj!
A projekt utolsó napján egy nagy változtatás tönkreteszi a programot, és nincs verziókezelés, sem mentés. Mi lesz a bemutatóval?
Jóslat ellenőrzése
A bemutatóra egy törött program vagy az előző napok elvesztett munkája marad. Verziókezelővel egy paranccsal visszatérsz az utolsó működő állapothoz. Ezért: kis lépések, gyakori commit, és kiadás előtt „fagyasztott” (címkézett) működő változat.
Hibakeresés: te vagy a hibadetektív (a projekt hibái)
Mi a baj, és hogyan javítod?
Gondold végig az okot, és csak utána nyisd le a megoldást.
1. „Majdnem kész” funkciók a határidő előtt
A 4. héten nyolc félkész funkciód van. Túl sok Must, és párhuzamos kezdés. Vágd vissza a Must listát; egyszerre egy funkciót vigyél végig (működik, ellenőrzött, tesztelt, commitolt); a többit tedd a Could listára.Ok és javítás
2. A kész program nem fut másik gépen
A bemutató gépén hibát ad. A kiadást nem próbáltad tiszta környezetben (14. fejezet): hiányzó futtatókörnyezet, fix elérési út, hiányzó fájl. A tiszta gépes próba legyen a 4–5. hét feladata, nem az utolsó napé.Ok és javítás
3. A kód egyetlen óriási Form
Háromezer soros Nincs rétegezés (12. fejezet). Vedd ki a logikát modell- és szolgáltatás-osztályokba; a Form csak a felületet kezelje. Ez a tesztelhetőség feltétele is.Form1.cs, amelyet senki nem ért.Ok és javítás
4. Az utolsó napon derül ki a hiba
A bemutató előtt találsz egy súlyos hibát. Hiányzik a folyamatos tesztelés. A hibákat a megírásuk után azonnal teszteld (13. fejezet), és a Must funkciókhoz írj tesztet, amelyet minden változtatás után lefuttatsz (regresszió).Ok és javítás
5. Nincs miről beszélni a reflexióban
Nem emlékszel, mi történt a hetekben. Nincs munkanapló és commit-történet. Vezess rövid heti naplót, és a commit üzenetekben írd le a döntéseket.Ok és javítás
6. A program kész, de senki nem érti, hogyan kell használni
A felhasználó nem találja a fontos funkciót. A felületet nem próbálta ki valódi felhasználó. Már a 3. héten adj a programot valakinek, figyeld meg (hallgass, ne magyarázz), és javítsd a zavaró részeket; írj rövid használati útmutatót.Ok és javítás
Mini projekt: a saját projekttervem
Ebben a leckében nem programot, hanem tervet készítesz: egy 2–3 oldalas projekttervet, amellyel megkezdheted a záróprojektedet. A kész terv a követelménytábla első sorához is tartozik.
- Ötlet-válogatás: írj fel 3 lehetséges ötletet (a katalógusból vagy saját), és mindegyiket pontozd 1–5 között a 6 ismérv szerint (érdekel, valós igény, kicsiben kezdődik, tanultakat használ, mérhető, kicsit kihívás); válaszd a legtöbb pontot.
- Egy mondatos cél és a felhasználó (név szerint: kinek készül, és megkérdezted-e).
- Követelmények: MoSCoW lista (Must legfeljebb 7–10, Should, Could, Won't); minden követelmény egyértelmű és ellenőrizhető.
- Felületterv: a főablak és legalább egy másik ablak vázlata (papír vagy Designer), a navigációval.
- Adatok és szerkezet: milyen adatot kezel; hol tárolod; osztálytérkép (legalább 4 osztály, a rétegekkel és az interface-ekkel).
- Kockázatok: legalább 3 kockázat (például ismeretlen API, nyomtatás, időhiány) és az első kísérlet, amely csökkenti őket.
- Ütemterv: 5–6 heti mérföldkő, tartalékidővel és kiadási héttel.
- Tesztterv-vázlat: minden Must-hoz legalább egy teszteset, és legalább 5 hibás/szélsőséges eset.
- Kiadási terv: milyen csomag (ZIP, telepítő), milyen futtatókörnyezet, hol vannak az adatok, milyen README.
- Önértékelés és visszajelzés: pontozd a tervedet a rubrika „Terv és követelmények” sora szerint, és mutasd meg a tervet egy leendő felhasználónak vagy a tanárnak; a visszajelzés alapján módosítsd.
Mintamegoldás: egy kitöltött tervlap (Osztálynapló) és kockázati tábla
# Osztálynapló – projektterv
## Cél és felhasználó
A program az osztályfőnöknek segít a jelenlét és a hiányzások nyilvántartásában.
Felhasználó: az osztályfőnököm (megkérdezve, a 3. héten kipróbálja).
## Követelmények
MUST: M1 osztály és diákok felvétele · M2 jelenlét rögzítése naponta (jelen/hiányzik/igazolt)
M3 diák hiányzásainak összesítése · M4 adatok mentése SQLite adatbázisba
M5 hibás bevitel és hibás adatbázis érthető üzenettel · M6 adatok törlése megerősítéssel
SHOULD: S1 havi jelentés megjelenítése · S2 keresés névre
COULD: C1 export CSV-be · C2 nyomtatható jelentés
WON'T: W1 több felhasználó · W2 hálózati szinkron
## Szerkezet
Models (Diak, Osztaly, Jelenlet) · Services (NaploSzolgaltatas, IAdatTarolo) · Data (SqliteAdatTarolo) · App (FoForm, JelenletForm)
Az IAdatTarolo mögött a tároló cserélhető (teszthez memóriás megvalósítás).
## Kockázatok
| Kockázat | Hatás | Csökkentés |
|---|---|---|
| SQLite használata új számomra | késés | az 1. héten kis kísérlet: tábla, mentés, olvasás |
| Valós diákadat kezelése | adatvédelem | csak kitalált adat a fejlesztéshez; az adat a felhasználó gépén marad |
| Időhiány a jelentésnél | a Should kimarad | a Must elkészül előbb; a jelentés a 4. héten |
## Ütemterv
1. hét: terv, váz, SQLite-kísérlet · 2. hét: modell, tároló, egységtesztek · 3. hét: felület (M1–M3), első kipróbáltatás
4. hét: M4–M6, hibakezelés, napló, jelentés · 5. hét: tesztek, javítások, dokumentáció · 6. hét: kiadás, tiszta gépes próba, bemutató
## Tesztterv (vázlat)
T1 üres osztálynév · T2 azonos nevű diák · T3 jelenlét rögzítése és újraindítás · T4 sérült adatbázisfájl · T5 csak olvasható adatmappa · T6 1000 diák betöltése
## Kiadás
Önálló ZIP és telepítő (14.5–14.6 lecke); README (követelmény, telepítés, adatok helye, eltávolítás); Névjegy; verzió 1.0.0.Értékelési szempontok a tervhez: a cél egy mondatban megfogalmazható; a Must lista rövid (6 elem) és ellenőrizhető; a szerkezet felületfüggetlen modell és tároló interface-szel; a kockázatok konkrétak és van első lépés; az ütemterv tartalmaz tartalék és kiadási hetet; a tesztterv a követelményekből és a hibás esetekből következik. Ez csak egy lehetséges terv: a sajátod más szerkezetű is lehet.
Mit tegyél ide: a felületterv fényképe vagy a Designer-vázlat a főablakról, és a PROJEKTTERV.md első oldala.Javasolt fájlnév: winforms-15-7-terv.webp · Alt szöveg: A projektterv és a felületvázlat
Három önálló gyakorlófeladat
Egyszerre csak egyet csinálj: tervezd meg, írd meg, futtasd, ellenőrizd, és csak utána nyisd ki a megoldást.
1. Követelmények élesítése
Írd át a homályos követelményeket ellenőrizhetővé: (a) „a program legyen gyors”; (b) „a felület legyen szép”; (c) „kezelje a hibákat”. (a) „A 1000 elemű lista betöltése 2 másodpercnél rövidebb ideig tart.” (b) „Minden ablak ugyanazt a színkészletet és betűméretet használja; a vezérlők igazítottak; 125%-os nagyításon sem takarják egymást.” (c) „Üres, túl hosszú vagy hibás bevitelre a program érthető üzenetet ad, és nem omlik össze; sérült adatfájl esetén biztonságos alapállapotból indul.”Egy lehetséges megoldás
2. MoSCoW-besorolás
Egy játékprogramhoz: pontszám, hang, mentett állás, ranglista, szintek, többjátékos mód. Osszd el a négy csoportba. Must: a játék szabálya, pontszám. Should: mentett állás, ranglista fájlban. Could: szintek, hang. Won't: többjátékos mód (hálózat, nagy kockázat). A beosztás indoka: a legkisebb játszható és befejezhető változat a Must.Egy lehetséges megoldás
3. Kockázat és kísérlet
A projekted egy nyilvános időjárás-API-t használna. Milyen kockázat van, és mi az első kísérlet? Kockázat: kulcs és kvóta, hálózati hiba, az API megváltozása, adatformátum. Első kísérlet (az 1. héten): egy konzolos vagy egyablakos kis program, amely egyetlen kérést küld, kiírja a választ, és kezeli a hibát (15.6 lecke); a kulcs beállításból, nem a kódból.Egy lehetséges megoldás
Gyakorlótár: 6 további feladat
Három szinten gyakorolhatsz: alap, közepes és kihívás. Csak a próbálkozás után nyisd le a megoldást.
Alap szint
1. Mi a MoSCoW?
Mit jelent a négy betű? Must (kell), Should (kellene), Could (jó lenne), Won't (most nem): a követelmények fontossági sorrendje.Megoldás megnyitása
2. Hány Must?
Hány Must követelményt érdemes felvenni? Legfeljebb 7–10 elemet: a legkisebb használható program követelményeit.Megoldás megnyitása
Közepes szint
3. Mérföldkő
Mi egy jó heti mérföldkő? Kézzelfogható, ellenőrizhető eredmény („a modell és a tároló egységtesztekkel fut”), nem általános „dolgozom a programon”.Megoldás megnyitása
4. Commit-üzenet
Melyik jobb: „javítás” vagy „Üres név ellenőrzése a pakli-szerkesztőben”? A második: megmondja, mit és hol változott; a történet így hasznos a hibakeresésben és a reflexióban.Megoldás megnyitása
Kihívás szint
5. A kockázatos rész
Miért érdemes a kockázatos részt az elején kipróbálni? Ha nem megy, még van idő váltani vagy egyszerűsíteni; a végére hagyva megbuktathatja a projektet.Megoldás megnyitása
6. Önértékelés
Miért pontozod magad a beadás előtt? A hiányokat még időben észreveszed és javítod; az eltérés a tanári értékeléstől is tanulságos.Megoldás megnyitása
Gyors önellenőrzés
Válaszolj fejben, és csak utána nyisd le a választ. Érdekel, valós igény van rá, kicsiben kezdődik, használja a tanultakat, mérhető, és kicsit kihívás. El lehet dönteni, hogy teljesül-e: konkrét, számokkal és példával pontosított. Cél, felhasználó, követelmények, felületterv, adatok és szerkezet, kockázatok, ütemterv, tesztterv, kiadási terv. Biztonsági háló, történet, kísérletezés ágon, együttműködés, a kiadás forrásának megőrzése. Terv, funkcionalitás, felület, kódminőség, hibakezelés, adatkezelés, tesztelés, kiadás, bemutató. A kiadott csomag kipróbálása fejlesztői környezet nélküli gépen (14. fejezet). Lekicsinyíted: a Must listát a legkisebb használható programra vágod, a többi Should, Could vagy Won't.1. Mi egy jó projekt ismérve?
2. Mi a követelmény ellenőrizhetősége?
3. Mit tartalmaz a tervlap?
4. Miért kell verziókezelés?
5. Mit nézünk a rubrikában?
6. Mi a tiszta gépes próba?
7. Mit teszel, ha túl nagy az ötlet?
Merre tovább?
Mélyíts
- C# és .NET: a nyelv újabb elemei, a LINQ és az
asyncmélyebben, a tesztelés (xUnit/MSTest), a tervezési minták. - Adatbázisok: SQL alapok, Entity Framework.
- Felületek: WPF és MVVM (15.2–15.3 lecke), majd egy többplatformos technológia (15.4 lecke).
- Web: ASP.NET Core és Blazor (15.5 lecke), HTML/CSS/JavaScript alapok.
Hogyan tanulj tovább?
- Építs: a legtöbbet a saját projektekből tanulod; mindig legyen egy aktuális kis projekted.
- Olvass kódot: nyílt forráskódú projektek, mások megoldásai; kérj és adj kódáttekintést.
- Használd a hivatalos forrásokat: a Microsoft Learn és a .NET dokumentáció a legfrissebb; a kérdéseidhez közösségi fórumok.
- Tanítsd: magyarázd el valakinek, amit tanultál: ez ellenőrzi és mélyíti a tudásod. Tanárjelöltként ez a legjobb tanulási módszer.
- Légy kitartó: a hibák és a megakadások a tanulás részei; a hibakeresés (13. fejezet) tudása éppen erre szolgál.
A tanfolyam végén: mit tudsz már?
- Windows Forms alkalmazásokat építesz: űrlapok, vezérlők, események, grafika, fájl- és adatkezelés, gyűjtemények, párhuzamos munka (
async). - Programot tervezel rétegekkel: osztályok, modell, szolgáltatás, felület különválasztása (12. fejezet).
- Hibát keresel és javítasz (debugger, kivételek, naplózás, tesztelés: 13. fejezet).
- Kiadsz egy programot: Release, telepítő, adatok helye, verzió, frissítés (14. fejezet).
- Ismered a továbblépési utakat: WPF, MVVM, MAUI, web, webes szolgáltatások (15. fejezet).
- Képes vagy egy saját projektet megtervezni, felépíteni és bemutatni.
Gratulálunk: a tanfolyam végére értél!
Térj vissza a tanmenethez, ismételd át azokat a részeket, ahol bizonytalan vagy, és kezdd el a saját projektedet.