Projektmunka követelmények

Általános követelmények

Teljesítések leadása

A leadandók esetén a megadott névkonvenciókat szigorúan tartani kell. A névkonvenciót nem tartó leadás nem minősül elfogadott teljesítésnek (akkor sem, ha határidőig beérkezett).

Csak megfelelően aláírt commit-okat fogadunk el

Csak azt a leadott anyagot tudjuk az egyéni értékelés során figyelembe venni, ami a saját GitLab felhasználó segítségével került feltöltésere. Ez minden esetben a H-s azonosító, vagy az egyetemi LDAP belépés. Olyan elektronikus címeket fogadunk tehát el, amelyek h123456@stud... alakúak. Amennyiben más egyetemi email címmel is rendelkezik a hallgató, abban az esetben is a fenti H-s email azonosítót kell használni a kurzus folyamán. Csak olyan commit-okat fogadunk el ami a hallgató saját, stud-os címéről készült. Hogyan?

Korábbi anyagok felhasználása

Minden leadandóban csak azok a részek fogadhatóak el új teljesítésnek, amik korábbi, a projekttel kapcsolatos teljesítésben még nem lettek leadva.

A projekthez tartozó forráskód (általában *.java fájlok) és hozzá kapcsolódó erőforrásokat a hallgatók GitLab szerverére kell feltölteni, folyamatosan a félév során.

Nagy bináris fájlok Git-ben

A (nagy) bináris fájlok tárolása nagyon lelassítja a Git működését. Ezért nem szoktunk ilyeneket feltölteni. Minden bináris fájlnak számít amit nem tudsz elolvasni, ha egyszerű Notpad-el megnyitod. Általában semmilyen generált fájlt sem töltünk fel, hiszen ezek előállíthatóak a forráskódból. Gitben nagy bináris állományok (*.class, *.jar, *.zip, *.rar, ...) tárolása tilos (max. 3 pont levonás jár érte), a .gitignore fájl segíthet ennek követésében.

Végül a leadandók bemutatása során szigorúan tartani kell az időkeretet. Ne tervezzünk túl hosszú prezentációt!

Csapatmunka

A hallgatók a projektmunka elvégzését csapatban teszik, lásd értékelés. A valós szoftverfejlesztés projektekhez hasonlóan a feladatok elvégzése a csapat felelőssége. Vagyis a csapat kapja a feladatot, melyet a gyakorlatvezető iránymutatásával egyénileg teljesíthető részekre bontanak a tagok.

Miért dolgozunk csapatban?

Több szem többet lát alapon érdemes lehet mások véleményét meghallgatni. Továbbá elakadás esetén könnyebb lehet segítséget kérni.

A csapatok 4-6 fősek és az első olyan órán kerülnek kiválasztásra, amikor a kurzusfelvétel lezárult, ez jellemzően a haramadik hét. A csapat feladatát a csapatválasztással azonos órán határozza meg a gyakorlatvezető a csapattagok véleménye alapján.

A csapatok neveit a gyakorlatvezetővel közösen határozzák meg a csapattagok. A nevekben, az ütközések elkerülése miatt, kisebb módosítások történhetnek a gyakorlatvezető által.

Dolgozhatok közösen más gyakorlat hallgatóival?

Sajnos adminisztrációs okok miatt a különböző gyakorlatra járó hallgatók nem dolgozhatnak együtt egy csapatban.

A csapat felelős önnmagáért!

Bármilyen a csapattal kapcsolatos problémát csakis

• írásban a gyakorlat e-mailcímére
• minden csapattag címzésével
• tisztelet teljes és tárgyilagos hangnemben
• a pontozás előtt

fogadunk el. Minden egyéb esetben a csapat a hallgatásával vállalja a felelősséget a következményekért. A nem megfelelő formában és hangnemben érkező panaszokat további visszajelzések nélkül figyelmen kivül hagyjuk.

Munkaidő nyilvántartása

A hallgatóknak a munkájuk követésére minden a projektre szánt munkát a GitLab felületén könyvelni kell. A munkaidő könyvelés célja kettős. Egyrészt vezetése ösztönzi a hallgatót a rendszeres munkavégzésre, másrészt a tevékenység követésére és a problémák időben történő feltárásának is alkalmas eszköze.

A rendszeres munka és annak követése kötelező

A rendszeres munka és könyvelés hiányában pontlevonás jár.

A munkaidőt a GitLab projekt adott feladathoz tartozó issue-ja alá kell bejegyezni, részletes (legalább 1-2 mondatos) leírással. Minden hallgatónak a saját munkaidejét kell könyvelni. Ha a feladathoz még nem tartozik issue akkor létre kell hozni. Egy issue-ban több munkaidőt is be lehet jegyezni. Egy issue alá több hallgató is jelezheti az idejét, pl.: ha segített a társának, de a saját feladatait mindenkinek el kell látnia.

Pótlás, csúszás és hiányos teljesítések kezelése

Nomen est omen

Bármelyik kötelezőnek megjelölt leadandó vagy a kötelező pont hiánya esetén a hallgató elégtelen érdemjegyet kap.

A projektmunkák javítására nincs lehetőség

A projektmunka elvégzése a félév során folyamatos és az tanórákon túli munkát igényel. Az ipari projektekhez hasonlóan a nem megfelelő minőségű munka elvégzése a gyakorlat során is következményekkel jár. Ezen okok miatt a projektmunkák javítására nincs lehetőség. Betegség miatt előfordulhat, hogy hallgatók csúsznak a projektmunkával. A váratlan körülmény csak a körülmény idejében elvégzendő feladatnak a határidejét tudja befolyásolni és az elvégzendő munka mennyiségét illetve a további részek határidejét sem befolyásolja.

A fentiektől eltérően a levelező tagozaton a leadandók, mérföldkövek ütemezését a félév rendjét figyelembe véve a gyakorlatvezető határozza meg.

A projektmunka formai követelményei

Szöveges anyagokra vonatkozó általános követelmények

Minden szövegnek, ábrának és képnek olvashatónak kell lennie A4-es lapra nyomtatás során ill. prezentáció esetén a kivetítőn nagyítás nélkül (javasolt betűméret: 11-14pt). A szöveges dokumentumokat az issue-k megjegyzésébe írjuk be. A megjegyzések nyelve nyelve magyar vagy angol lehet, de adott issue-n belül ne keverjük a nyelveket (kivétel az egyes forráskód idézetek).

Ábrák, diagramok, táblázatok

Mitől ábra egy ábra?

A kettőnél kevesebb elemből álló ábra (diagram, gráf) nem számít ábrának. Az olyan ábra ahol nincs az elemek között kapcsolat (él) nem számít ábrának.

Nem tudsz mindig ott lenni, hogy elmagyarázd a jelölést

Az olyan ábrát vagy képernyőképet amihez nem tartozik legalább egy bekezdésnyi magyarázó vagy részletező szöveg nem vesszük figyelembe a teljesítés során.

Az ábráknak és a képernyőképeknek tartalmaznia kell a bemutatott elemeket. Logikátlan vagy követhetetlen módon feldarabolt ábrákat nem fogadunk el.

Prezentációk

A prezentációk során javasoljuk a ,,The beamer class User Guide for version 3.57'' 5. fejezetében ,,Guidelines for Creating Presentations'' leírt irányelvek betartását. A prezentációt PDF forámtumba kérjük beadni, ezzel biztosítva, hogy mindenhol ugyan úgy jelenik meg. Ez elkészíthető LaTeX-ben, Microsoft PowerPoint-tal, vagy bármilyen egyéb programmal, mely képes PDF formátumba menteni a prezentációt.

Videó bemutatók

A projektbemutatók a gyakorlatvezető döntése alapján videó formában is elkészülhetnek. Ez a forma különösen a levelező tagozaton előnyös, tekintettel a levelező képzés távoktatás jellegére nézve. Az elkészült felvételeket YouTube-ra kell feltölteni. Rögzítéshez az ingyenes OBS Studio szoftvert, míg szerkesztéshez az ingyenes Blender szoftvert ajánljuk. Egyéb programot a hallgatók saját felelősségre használhatnak. A videós prezentáció részleteiről ezen az oldalon tudsz tájékozódni.

Tartalmi követelmények - megvalósítás

Programozás és kódolás

Egy átlagos programozó a munkaidejének 90%-át kód olvasásával tölti.

Bármilyen bolond képes olyan kód írására, amit egy gép megért. A jó programozók kódját más emberek is megértik.
Martin Fowler

Honnan tudom hogy nem "szép" a kódom?

• nehezen tudod régi kódjaidat megfejteni
• sok megjegyzésre van szükséged kódolás közben
• programjaidhoz nagyon nehéz új funkciót illeszteni
• új funkciók hozzáadása után programod más részén érdekes dolgok történnek

Mit tehetek ellene?

Javasoljuk a Tiszta kód elvek követését. Ezenkívül érdemes megérteni és elsajátítani a tervezési minták használatát. A fejlesztés során célszerű figyelni a "bad smell"-ekre majd különböző újratervezési technikákkal javítani a forráskód minőségét.

A szoftverfejlesztés végső célja természetesen a megrendelő igényeinek kielégítése olyan módon, hogy az nyereséges legyen a fejlesztést végző szakemberek számára is. Természetesen a munka során rengeteg jogi, erkölcsi és szakmai elvet is figyelembe kell venni. A szoftverfejlesztés több mint pusztán forráskód írása, de ez természetesen része.

A megrendelők igényei általában követelményspecifikációként kerülnek rögzítésre. A fejlesztő csapat vezetője és más menedzserek ezt tovább bontják a fejlesztők számára is feldolgozható feladatokká, melyeket issue-k formájában rögzítenek. Ezt a folyamatot a gyakorlatvezető végzi el. A hallgatók az issue-kban megfogalmazott feladatoktól veszik át a munkát, mint egy fejlesztő csapat tagjai.

Egy átlagos programozó sokkal több időt tölt hibakereséssel, mint fejlesztéssel.

Szeretem, ha a kódom elegáns és hatékony. A kód logikája egyértelmű kell legyen, hogy nehezen rejtőzzenek hibák a sorok között. A függőségek legyenek minimálisak, mert ez megkönnyíti a karbantartást. A hibakezelés legyen teljes és a kód teljesítménye közel optimális, így nem kísérti az olvasóját további optimalizálásra, amellyel a tisztaságát veszélyezteti. A tiszta kód egy dolgot csinál, és azt jól.
Bjarne Stroustrup

Értékelés

A hallgatók a Programozás és kódolás részre 11 pontot kaphatnak. Ebben az alfeladatban teljesíteni kell az elvállalt issue-ban leírt igényeket. A korábbi leadásért a gyakorlatvezető plussz pontot adhat, saját belátása szerint az elvégzett munka minőségét is figyelembe véve. A határidők a naptárban találhatóak, további részleteket a gyakorlatvezető ad a határidő közeledtével.

A fejlesztés GitLab környezetben történik. A futtatható kódot az issue-hoz kapcsolódó feature branch-en kell elhelyezni a Git-ben. Határidőre fordítható, bemutatható kódnak kell lennie, amit videó(ko)n keresztül kell bemutatni. A videó(k) hossza összesen legfeljebb 15 perc lehet. Az elérést lehetővé tévő YouTube linket (videó vagy lejátszási lista) az érintet feladatot tartalmazó issue alá kell beszúrni megjegyzésként. A hallgatóknak ismerniük kell a kapcsolódó issue-k megvalósítása során elvégzett főbb változtatásokat. A bemutatón az implementált változtatásokat, új feature-öket kell bemutatni.

Dokumentáció

A fejlesztő feladatai közé tartozik, hogy az általa készített programkódot később tovább lehessen fejleszteni, javítani. A forráskód minősége mellett a rendszer megértéséhez szinte minden esetben szükség van olyan információkra, melyek a megrendelő területéről származnak és nem programozástechnikai jellegűek.

A projektek esetén a fordítottja is igaz. A felhasználó általában nem rendelkezik átfogó informatikai ismeretekkel, vagyis ami a fejlesztő számára egyértelmű az a felhasználó számára sokszor nem az.

Ezeket a többlet információkat a különböző dokumentációk tartalmazzák. A fejlesztők általában saját maguk írják a fejlesztői (kódhoz közelebbi) dokumentációt. Továbbá aktívan együttműködnek a PR szakemberekkel a felhasználói dokumentáció elkészítése során.

Fejlesztői dokumentáció

A fejlesztői dokumentáció olyan technikai tudást tartalmaz, amely segíti a többi programozót a rendszer továbbfejlesztésében.

De a kód önmagát dokumentálja, nem?

A kód képes bizonyos mértékben leírni és magyarázni, hogy hogyan működik a rendszer. A probléma az hogy általában nem tartalmaz információt arról, hogy miért kell úgy működnie.

Például egy céges adatokat tartalmazó adatbázis tárolhatja a cégek nevét és a telephelyeket. Amíg az kiolvasható az adatbázisból, hogy egy telephely csak egy céghez tartozhat, addig nem lehet tudni, hogy ezt a hatályos jogszabályok, vagy a gyakorlati tapasztalat miatt van-e így, esetleg mindkettő. Ez az információ fontos, hiszen az előbbi esetben a rendszernek követnie kell a jogszabályok változását, míg utóbbinál csak a cég üzletpolitikáját kell figyelembe venni.

Fontos figyelembe venni, hogy a fejlesztői dokumentáció nemcsak más fejlesztőknek, hanem saját magunk jövőbeli változatának is segítséget nyújthat.

Segíts magadon (is)!

Mennyi megjegyzést kell írni?

Annyit hogy a kód könnyen érthető legyen egy speciális tudással nem rendelkező fejlesztő számára.

A pontatlan megjegyzések még rosszabbak, mint a megjegyzések teljesen hiánya. A megjegyzések írásának egyik gyakori oka a rossz kód. Érdemesebb inkább rendbe tenni a rossz kódot, mint megjegyzésekkel megtűzdelni. A dokumentálás során az alábbi sorrendet célszerű követni.

• A publikus és protected elemek legyenek dokumentálva, kivétel egy-két triviális eset.
• A kulcsfontosságú vagy összetett privát elemek legyenek dokumentálva.
• A speciális szoftverfejlesztési szaktudást igénylő elemek kerüljenek dokumentálásra. Pl.: miért használtunk egyedi bináris objektum soros-konverziót.

Milyenek a jó megjegyzések?

• Jogi megjegyzések
• Informatív megjegyzések
• Szándékot magyarázó megjegyzés
• Tisztázó megjegyzés
• Következményekre figyelmeztető megjegyzés
• TODO megjegyzés
• Megerősítő megjegyzés
• Javadoc megjegyzés nyilvános API-ban

Milyenek a rossz megjegyzések?

Fajtája	Leírás	Példa
Motyogás	hanyagul odavetett megjegyzés, mely legfeljebb a szerzőnek jelent valamit, más számára nem érthető	//TBD
Redundáns	nem szolgál semmiféle plusz információval a kódról, nem könnyebb elolvasni sem, mint magát a kódot	// sqrt(i) + 42 / (id % 0x0123BA)
Félrevezető	nem eléggé pontos megjegyzés	// ellapsed time (milyen mértékegységben?)
Kötelező	a nyilvánvalót magyarázó megjegyzés, ami csak azért van ott, mert megkövetelik, hogy minden függvényhez, változóhoz tartozzon dokumentációs megjegyzés	//the constructor
Napló	egy modul elején a benne végzett minden egyes módosítást naplószerűen dokumentáló megjegyzés	//2042-06-01: Creation of the file
Zaj-megjegyzés	új információval nem szolgáló, a magától értetődőt újra megfogalmazó megjegyzés	// this method gets the name (string getName() előtt)
Pozíciójelző/szalagcím	kód tagolására szokták használni, a legtöbb esetben újratervezéssel a kódban is kifejezhető	// Class Variables
Szerző neve	a verziókezelő rendszerek feleslegessé tették	//author: Gergő Balogh
Megjegyzésbe tett kód	mások azt fogják gondolni, hogy okkal van ott, fontos, és ezért nem lesz bátorságuk törölni	//i += count % step
Nem lokális	olyan megjegyzés, mely nem a közvetlen környezetében lévő kódra vonatkozik
Pletyka	túl sok információt tartalmazó	//base on Pythagorean (born around 570 BC) theorem a^2 + b^2 = c^2 where c is the hypotenuse
Nem releváns	kódhoz nem nyilvánvalóan kapcsolódó	//Java virtual machine (JVM) is a virtual machine that enables a computer to run Java programs (adatbázis definíciós fájlban)
Rejtett Javadoc	Javadoc megjegyzés nem nyilvános kódban

Értékelés

A Fejlesztői dokumentáció részre a hallgatók összesen 9 pontot kaphatnak. A dokumentálás során az egyes kódelemeket Javadoc segítségével dokumentáljuk. Az algoritmusok és folyamatok egyéb részeit hagyományos kommentekkel kell ellátni, ahol a megértéshez a programozástechnikai tudáson túlmutató információra van szükség. Például, miért az adott képletet használta a távolság kiszámítására két épület között a CodeMetropolis Placing fázisában.

Felhasználói dokumentáció

A felhasználói dokumentáció célja, hogy segítse a rendszer használatának elsajátítását. Ezt célszerű párhuzamba állítani a fejlesztői dokumentációval, melynek célja a továbbfejlesztés segítése.

A felhasználó nem rendelkezik szoftverfejlesztői, sőt az esetek többségében még informatikai tapasztalatokkal sem. Egy asztalos feladata, hogy meghatározott összegért bútorokat készítsen, nem várható el tőle, hogy ismerje a bankszámláját kezelő rendszer adatbázis-sémáját. A nagymama, aki receptet keres az unokája születésnapjára, nem fogja tudni, hogy a menüben és az ikonsoron lévő gomb ugyan azt az eseménykezelő metódust hívja. A portás, aki Bluetooth-os kamera rendszert használ nem tud sebezhetőségi elemzést futtatni a kódoló algoritmusokon, hogy meggyőződjön róla nem lehet-e lehallgatni a rendszert.

Milyen konverziókat használhatunk a CodeMetropolis Mapping eszközében?

A CodeMetropolis-ban van lehetőségünk, hogy a bemenő adatokat különbözőképpen átalakítsuk a vizualizáció során ezzel javítva az ábrázolás kifejezőképességét. Ezt különböző konverziók segítségével tehetjük meg, melyeket a codemetropolis.toolchain.mapping.conversions csomagban lévő osztályok valósítanak meg.

A rendszer felhasználója itt általában egy fejlesztő vagy kutató, aki szeretné megvizsgálni a forráskód (nem a CodeMetropolis, hanem egy másik rendszer) tuladjonságait. De lehet, hogy nem fér hozzá a forráskódhoz, nem ért "Java-ul" vagy nincs ideje a rendszer belső működését megismernie. A felhasználó csak a hivatalos oldalon lévő dokumentációra támaszkodhat.

A felhasználói dokumentáció megírása nem egyedül a fejlesztő feladata. A fejlesztő birtokában van számos olyan információnak, melyet a dokumentációnak tartalmazni kell, de ezek bemutatása során számos egyéb aspektust is figyelembe kell venni. Ilyen például a termék és a cég marketing céljai és egységes arculata. A terméknek meg kell felelnie az aktuális jogszabályi elvárásoknak. Végül a vezetők döntése hogy bizonyos funkciókat milyen ütemezéssel és költségekkel tesznek elérhetővé.

De hát ez teljesen egyértelmű! Minek írjam le?

Teszt Elek egész este forgolódott az ágyában. Pár hónapja került be junior fejlesztőként a +Műtlek projekt fejlesztői csapatába. A termék egy új robotkar volt, melyet az olyan műtétek során használnának, ahol a legprofibb sebész keze se tud elég pontos vágásokat ejteni. Számítógépes grafikai tapasztalatai miatt a kar térbeli vezérlésének megtervezésével bízták meg. Az orvos megadja a kulcspontokat, majd a robot megfelelő mozdulatokkal összeköti ezeket.

Álmában a projekt óriási sikert aratott. Bankettek sora követte egymást, s a cég már az Egyesült Államokban is megkezdte az eszköz értékesítését. Elek épp az egyik Floridai értekezleten volt, amikor autóbalesetet szenvedett. Kórházba szállították, ahol már ott várta a műtőben az orvos, a +Műtlek robotkar és az asztalon a használati utasítása. Az orvos belelapozott a vaskos könyvbe.
"...az origótól vett távolságot kell megadni" - dünnyögött magában az orvos. - "Nővér, az első bemetszészt a bal felső pontól 1.24 inch-re kezdjük meg. Altatást!"
Elek próbált kiáltani, hogy ne! az origó a jobb alsó pont és minden távolságot mm-ben kell megadni, de ekkor már a maszk a száján volt. S a világ elsötétült.

Teszt Elek remegve ébredt, még félálomban az első dolga az volt, hogy a koordináta rendszerhez kapcsolódó issue alá tett egy megjegyzést: "Felhasználói dokumentációt és követelményeket átnézni: mértékegységek és referencia pontok".

Azt hogy a fejlesztők a felhasználói dokumentációhoz szükséges adatokat milyen formában és módon adják meg az adott cégtől és projekttől függ.

Értékelés

A Felhasználói dokumentáció részre a hallgató összesen 9 pontot kaphatnak. A hallgató feladata hogy közvetlenül a választott issue lezárása előtti megjegyzésben röviden összefoglalja az elkészült munka felhasználásának lehetőségét és módjait. A leírásnak a használatra kell koncentrálnia és nem a rendszer belső elemeinek működésére vagy kapcsolataira. Ha az elkészült módosítás eltért az issue-ban megfogalmazott követelményektől, azt részletezni és indokolni kell.

Tartalmi követelmények - projektmenedzsment

Issue megismerése

Cél az átvett projekt megismerése, és a kiválasztott issue elhelyezése a projekten belül. Ez a feladat két fő részre bontható: Azon kódrészletek, komponensek azonosítása, amelyek kapcsolódnak a kiválasztott issue-hoz, valamint a kapcsolódó issue-k feltérképezése.

Kapcsolódó komponensek megismerése

Ezen komponensek szerkezetét (UML package, osztály vagy egyéb szerkezeti diagram, pl. E/K) és fő funkcióit (UseCase, szekvencia diagram, funkcióleírások screenshotokkal) ábrázolhatjuk.

Mindenkinek értékelhetőnek kell lennie

Az értékelés miatt összesen legalább annyi diagramot kell átadni ahány fő dolgozik az adott issue-n (a javasolt diagram típusok az alábbi linkeken érhetők el: 1, 2). A feltöltés során mindenki a saját felhasználói azonosítóját használja, hogy egyértelműen el tudjuk dönteni, melyik rész kinek a munkája.

Az issue (és a projekt) megismerése során tapasztalt hiányosságok, nehézségek, esetleg pozitívumok rögzítése szintén fontos lehet a feladat végrehajtása során. A projektek komplexitása tetszőleges lehet, ezt az átlagember egyszerűen nem képes átlátni. Szerencsére nincs is szükség emberfeletti memóriára, hiszen az issue-khoz rengetek információ kapcsolható, amely szükség esetén elérhető.

Csak akkor tudunk segíteni tudunk a problémáról!

A feladat megoldása során felmerülő komplikációkról azonnal tájékoztatni kell a gyakorlatvezetőt (ha másképp nem rendelkezik erről, akkor e-mail-ben).

Ezt vajon miért írtam fel?

Ha egy issue-hoz másikat kapcsolunk mindig adjuk meg hogy mi a kapcsolat köztük.

Melyik segít többet? #42 vagy előfeltétele: #42

Értékelés

A kapcsolódó komponensek megismerése részfeladatra összesen 8 pontot lehet szerezni. Az issue-hoz kapcsolódó információkat az issue alá kell gyűjteni. Az folyamat során azonosított hibákat, fejlesztési javaslatokat és alfeladatokat új issue-ként kell rögzíteni és említéssel belinkelni a fő issue alá.

Kapcsolódó issue-k összegyűjtése és munka összehangolása

Keresztbe-módosítás

Képzeljük el hogy egy adott feladatot, pl. az egyik eszköz parancssori kimenetének színezését több különböző könyvtárral is meglehet oldani. Teszt Elek a HiperSzínes csomagot, míg Pró Béla a SzívárványConsole csomagot választja. A fejlesztés egészen addig gond nélkül folyik amíg össze nem ér a két rendszer. Pl.: szeretnénk kiemelni a hibaüzenetek színét egy közös helyre, hogy egységes legyen minden eszközben.

Ilyenkor az egyik megvalósítást át kell írni a másik javára, vagyis vagy Elek vagy Béla fölöslegesen dolgozott. Ez a kellemetlen helyzet és a projekt számára kidobott erőforrás (munkaidő) elkerülhető lett volna, ha Béla és Elek tisztában vannak az issue-k közötti kapcsolatokkal.

A példában bemutatott helyzet elkerülése érdekében az issue-kat (legalább) említésekkel össze szokták kötni. Az issue-k egy gráfot vagy hálózatot alkotnak. Azonban nem szabad elfelejteni, hogy a hálózat mögött emberek (szoftverfejlesztők) és az ő munkájuk közötti kapcsolat húzódik meg. A nagyobb méretű vagy összetett csapathierarchiával rendelkező projektek esetén ritka, hogy egy ember képes legyen átlátni az egyes feladatok közötti kapcsolatokat. Vegyük figyelembe, hogy a feladatokhoz technikai részletek is tartoznak, például, hogy melyik könyvtárcsomagot vagy tervezési mintát használjuk.

Ezek a jelenségek a projektmunka kapcsán is megfigyelhetőek. Bár a CodeMetropolis közepes méretű rendszerek közül a kisebbek közé tartozik, de a több gyakorlaton és szemeszteren átívelő fejlesztés növeli a folyamatok összetettségét.

Az issue-k társas lények

Nagyon ritkán fordul elő, hogy egy issue-ban leírt feladat független a többi issue-ban definiálttól. Az issue-k általában összetett hálózatot alkotnak, amelynek megismerése fontos lépés a feladat elvégzése során.

Fontos felismerni, hogy bár az issue-k listája szétbonthatóak kisebb csoportokra a kapcsolataik mentén, de ezek végül egy közös rendszerhez kapcsolódnak, ami itt a CodeMetropolis projekt. Vagyis szükséges összehangolni az egyes részeken végzett munkát. Ezt a projektszintű összehangolást a gyakorlatvezetők fogják végezni a hallgatók segítségével.

Egységesség

Képzeljük el, hogy vezetőként el kell döntenünk hogy a projektben mennyire készültek el a naplózás funkciók. Ez 3 issue-ban került kiosztásra 3 különböző fejlesztőnek. Kakszi Lajos szereti az angol (amerikai) szakkifejezéseket, például naplózás helyett loggol-ást használ. A szleng és a poénok megszállottja Turbók Imre szenior fejlesztő, soha nem hagy ki egyetlen szóviccet se, még akkor se ha csak ő érti. Végül Király Sándor, egy junior fejlesztő, nem igazán ismeri a szakkifejezéseket, ezért gyakran rosszul használja, például keveri a kimenet és a naplófájl fogalmát.

A fejlesztés folyamán, az issuek kezelésében is törekedni kell a konzekvens, egységes stílus alkalmazására. Az egységesség biztosítása minden résztvevő egyetemleges feladata.

Egyeztessünk!

A hallgatók megfelelő issue-k választásával befolyásolhatják, hogy kivel kell szorosabban együtt dolgozniuk.

Értékelés

A Kapcsolódó issue-k összegyűjtése és munka összehangolása részre a hallgató összesen 7 pontot kaphat. A hallgató feladata, hogy a kapcsolódó issue-kat hivatkozza (említse) a választott issue-ja alatt. Fontos hogy a feladat elvégzésének része az egymás közötti kommunikáció és egyeztetés.

részfeladat	maximális pontszám
kapcsolódó issue-k megjelölése	4
egységesség	3

A fejlesztési és egyéb folyamatok követése

A szoftverrendszerek az életciklusuk során folyamatosan változnak. Új verziók készülnek el, gyorsabb hardverek jelennek meg, új operációs rendszer frissítéseket telepítenek. A technikai jellegű változásokon kívül a felhasználók igényei is folyamatosan alakulnak.

Kihez fordulnál segítségért?

Képzeljük el, hogy frissen becsatlakozol egy hosszú ideje futó fejlesztési projektbe. A munkád során feltérképezed, hogy a feladatot melyik osztályt érinti. Sajnos a módosítás során előjön egy olyan kivétel, amelyet nem tudsz értelmezni.

Kihez fordulnál segítségül?
Biztos hogy mindegyik szenior átlátja a program minden részét?
A vezető fejlesztő mindenre tudja a választ?

A fenti kérdéseket a verziókövetéssel és a projekt menetének folyamatos dokumentálásával válaszolhatjuk meg. Egy jól felépített és helyesen használt verziókövető rendszer esetén nemcsak az adott osztály, de akár a kérdéses sor szerzőit is pillanatok alatt le lehet kérdezni.

Forráskód verziókövetése

Szoftverrendszer régészet

A CodeMetropolis jelenleg szorosan támaszkodik a BlockModifier csomagra. Vajon miért lett ez ennyire kiszervezve? Miért nem része a rendereszköznek?

Egyáltalán miért fontos ezt tudnunk? A központi projektbe beemeléssel csökken a kezelendő függőségek száma, egyetlen fordítási folyamattal elő tudjuk állítani a BlockModifier és a CodeMetropolis legfrissebb változatát.

Bár a rendszer használ verziókövetést, ezt úgy tűnik ebben az időszakban elég hiányosan tette. A vizsgált könyvtár egyetlen commit-ban szerepel, abban ami valószínűleg a teljes projektet átemelte egy korábbi verziókezelő rendszerből. Ez 2016-ban volt, gyakorlatilag az első olyan commit amiben tényleges forráskód szerepel.

A fejlesztők nem emlékeznek a pontos okra, hogy miért került ez a csomag kiszervezésre, így ez örökre feledésbe merül. A tudás hiánya sajnos rizikót is jelent. Vajon ha beemeljük a központi projektbe azzal nem okozunk-e olyan problémát amire már nem emlékszünk?

Értékelés

A hallgató a Forráskód verziókövetése részfeladatra összesen 7 pontot szerezhet. A hallgató feladata a forráskódon végzett módosítások folyamatos verziókövetése Git rendszer segítségével.

részfeladat	maximális pontszám
Git és GitLab használat	4
Git flow követése	3

A hallgatónak törekednie kell, hogy segítse a további módosítások bevezetését. Az értékelés során csak azokat az elemeket vesszük figyelembe ami a saját felhasználói azonosító használatával került fel a hallgatói GitLab szerverre.

Fejlesztési folyamatok dokumentálása

A fejlesztés során a forráskódon kívül sok más információ is keletkezik. Ezek nyomonkövetése és gyűjtése legalább annyira fontos mint a kódbázis maga.

Éjszakázás ellen

Pró Barbara és Teszt Elek hallgatók egyazon funkciókon dolgoznak a félév során. Hétfőn mindkettőjüknek elmarad egy órája, így van idejük megbeszélni a következő lépéseket. Barbi nemrég hallott egy új programcsomagról, ami szerinte remekül illene a feladathoz. Elek szeretné még befejezni a választott issue-jához kapcsolódó rész átnézését. Így a csomag kipróbálását Barbi vállalja. A maradék időben a főbb megvalósítandó funkciókról esik szó.

Mindketten hazaindulnak, de Barbi a TIK-ben felejtette a táskáját, ezért vissza kell mennie érte. A villamos lerobban félúton. Úgy tűnik, ez nem az ő napja. Másnap eszébe jut a Kalkulus 2 ZH, így egész héten arra készül. Elekkel péntek délután fut össze, aki kíváncsian kérdi milyen az új programcsomag.

Barbi nem érti, hogy Elek mire gondol, volt valami a Rendszerfejlesztés 2 projektmunkával kapcsolatban, de kisebb gondja is nagyobb annál, hogy most ezzel foglalkozzon. Sajnos a határidő ettől nem változik, így mindketten egész hétvégén az új csomag megismerésével foglalkoznak, amit végül sikerül működésre bírni. Hétfő hajnalban már egyikőjük se mer módosítani a kódon, nem értik, hogy az miért működik, ezért félnek hogy elromlik egy óvatlan mozdulat eredményeképpen.

A fenti vitás helyzet, és a határidőhöz közeli kapkodás részben elkerülhető lett volna a folyamatok megfelelő naplózása segítségével. A megbeszélések után célszerű memo-kat írni, amelyekből kiderül, hogy milyen döntésekben állapodtak meg. Az új feladatokat issue-k formájában kell rögzíteni. A korábbi feladatokhoz kapcsolódó információkat az issue-k alá megjegyzésben írják, hogy minden szükséges információ egy helyen legyen. A határidőket, és az egyes feladatok haladását, felelősét frissíteni kell az issue-k alatt. Ezzel nem csak azt érjük el, hogy mindenki számára egyértelmű lesz a saját felelőssége, hanem hogy ezek az információk bármikor, a többiek zavarása nélkül is elérhetők lesznek.

Egy feature - egy branch - egy merge request: A hallgatók (a feature méretétől függően) egy általuk választott feature-ön dolgoznak. A hallgatók egy feature-t (vagyis egy issue-t) egy branch-ben fejlesztenek. A branch neve a feature-hoz kapcsolódó issue számát tartalmazza. A branch neve a következő formátumot követi: <issue szám>-<rövid leírás>. Ezt a branchet és a hozzá kapcsolódó merge request-et a hallgatóknak kell létrehozniuk. A branch neve a feature megvalósításának kezdetén jön létre és a munka elvégzése után merge-elésre kerül a hallgatók által a develop branch-be.

Csak az a munka értékes, amelynek eredményét eléred

Az egy feature-ön dolgozó hallgatók munkájának (commit-jainak) a fent létrehozott branch-re (és így a merge request-be) kell kerülni. Csak azt a munkát pontozzuk, amely elérhető a merge request-ből.

Hogyan látszik az a munka, amit nem a kódon végeztünk?

A szoftverfejlesztés során több olyan feladatot is el kell látni, amely nem kapcsolódik a kódoláshoz. Ilyen például a többi fejlesztővel való kommunikáció. Ezeknek nem commit-ként látszanak, így ezeket a hallgatóknak memo-k formájában kell rögzíteniük. A memo-kat a merge request-hez kell csatolni.

Értékelés

A hallgató a Fejlesztési folyamatok dokumentálása részfeladatra összesen 7 pontot szerezhet. A félév során a következő fejlesztési elemek dokumentált használatát pontozzuk.

részfeladat	maximális pontszám
Issuek karbantartása	4
Nappali tagozaton: Megbeszélések dokumentálása (példa)	3
Levelező tagozaton: Döntések és problémafelvetések dokumentálása	3

Az agilis módszertanokhoz hasonlóan kövessük nyomon a feladatok végrehajtását. Mindenkinek legyenek saját issue-jai (válalt feladatok és részfeladatai). Ezek állapotát a hallgatói GitLab szerveren a saját gyakorlathoz tartozó issue board-on kell frissíteni folyamatosan a félév során.

A megbeszélésekhez memot kell készíteni, amelyben a megbeszélésen résztvevőket fel kell tüntetni.

A levelező tagozaton a fentiektől eltérően lehetőség van egyéni feladatteljesítésre. Mivel ebben az esetben nincsenek megbeszélés memok, így levelező tagozaton ezt a részt feljegyzésekkel kell pótolni. A feljegyzések célja, hogy a projekt során felmerült problémákat, a meghozott döntéseket követni, ellenőrizni lehessen (akárcsak a memok esetében).