Szerkesztő:Madbence/Szoftver labor 4 tanácsok

Személyes tapasztalataim, illetve tanácsaim az utókornak. Utoljára frissült: lennon^(vita) 2013. január 21., 07:40 (CET)

A csapat

Ha levlistán vadászol csapattagokat, vagy akarsz csapatot találni magadnak, mindenképpen érdemes jelezni, hogy milyen területen tartod magad jónak, hiszen lehet, hogy 5 profi Java kóder zseniálisan jól összerakott, és megtervezett kódot tud írni, ha a dokumentáció rossz, nagyon le tudja rontani a teljesítményt. (oké, mondjuk öt jó Java kóder max egy hosszúhétvége alatt lefejleszti az egészet mindenestül, utána meg csak generálja a diagramokat :) )

Államforma

Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól.

Tehát kelleni fog egy vezető, aki mindenkinek ki tudja osztani a konkrét feladatát, és meg tudja szabni, hogy azt pontosan mikorra kell elkészítenie. Az a módszer, hogy "Ki mit szeretne csinálni?", teljesen életképtelen, egyel jobb fokozat az "Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?" (ha nem, miért nem, csinálnál-e helyette Z-t, ami W-re elkészül?). Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni). Amikor faszán működik a csapat, azt biztosan észre fogjátok venni, ugyanis olyankor nem akarjátok egymást vízbe fojtani.

Kommunikáció

Ha mindenki kolis, az a legjobb. Egyéb esetben a Skype jó helyettesítő, valamint a levlista (tudom ajánlani a Google Groups-ot). A legjobb a napi szintű kommunikáció, de egy héten mindenképpen legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor. Oké, a leadás dél körül szokott lenni, és reggel 8 és dél között kemény 4 óra van, de azért próbáljátok ne ilyenkor befejezni. Vagy ha már így jártok, mindenképpen nézzetek körül, hol fogjátok olyan gyorsan kinyomtatni (és műanyag bugyit szerezni hozzá! :D), hogy még vissza is érjetek.

Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni.

Kollaboráció

Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni.

Doksi

Erre a célra érdemes valamilyen Wikit beüzemelni, mi a bitbucket szolgáltatását használtuk, a repó mellé kap az ember egy wikit is, ami szintén repóként működik. Érdemes megoldani, hogy a Wikiből on-the-fly lehessen pdf doksit generálni, mi erre a célra egy Wiki2LaTeX toolt csináltunk (ha megtalálom a kódját, felrakom), ami a Wiki saját markupjából LaTeX kódot generált, így gyakorlatilag pár kattintás volt az aktuális Wiki tartalmából dokumentációt készíteni.

Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. El lehet kezdeni tanulni a LaTeX-et (Van is rá tárgy). A ShareLaTeX oldalon lehet kollaborálkodni is, illetve ha éppen nincsenek kéznél a binárisok, neten, on-the-fly is lehet pdf-et generálni (az emscripten csodákra képes :D).

UML

Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az Enterprise Architect-et választottuk (találtunk egy "ingyenes" letöltési lehetőséget), de igaziból úgyis csak nyilakat meg dobozokat kell rajzolni, szóval ami ezt tudja, az rendben van. Ha tud menteni vektoros formátumba, az külön orgazmus, mert még ki is fog nézni valahogy a doksi.

Mivel ha ezt a tárgyat csináljátok, mind átmentetek Szofttechből, tehát állítólag az UML a kisujjatokban van. Ez jól is fog jönni, mert tonnaszámra kell diagramokat csinálni (és olyan részleteseket, amiket a valóságban többet a büdös életben nem fogtok).

Verziókezelés

LZ biztos mindenkit bevezetett a verziókezelés rejtelmeibe Szofttechből, csak éppen a többség nem hitte el, hogy ez valami értelmes dolog. Értelmes dolog, és meg kell tanulni használni. Én a Git-et ajánlom.

SVN

Hagyományos verziókezelő szoftver a Subversion, valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. TortoiseSVN must have jutility, nélküle el se kezdjétek.

Mercurial

A Mercurial egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom.

Git

Az áltimét verziókezelő (szintén DVCS), ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy tutorialt, még most is viszonylag használhatónak tartom.

Konzultációk

Itt többnyire az van, hogy meg lehet hallgatni, miért szar a munkátok, és hány pontot nem kaptatok meg. Jó beszélőkével rendelkezők itt még tudnak 1-2 pontot kisajtolni, a konzulens is emberből van, és nem gondolatolvasó, szóval az elmék egyeztetése esetenként jótékonyan tud hatni a pontszámra.

Amikor szoftvert kell bemutatni, mindenki legyen ott, egyébként irgumburgum jár (akár random mínuszjegy!). A szürke hétköznapokon elég, ha egy ember van ott, de ilyenkor célszerű olyan embernek bemenni, aki tudja, miről szólt az aktuális feladat, amit beadtatok.

Ilyenkor adják ki a következő heti feladatokat, és aki nem alszik éppen, az tippeket is hallhat ezzel kapcsolatban.

Kód

Előbb-utóbb kódolni is kell, érdemes nem szarozni vele túl sokat. Érdemes minél egyszerűbb, logikusabb kódot írni, aminek az előállítására az alábbi algoritmus rendkívül jó:

1. Kódolj
2. Ha kész van, nézd meg, hogy bonyolult-e. Ha igen, kezd elölről.
3. Profit!

Editor

Érdemes a Notepadnál komolyabb cuccot használni, de azt figyelembe kell venni, hogy beadásnál parancssorból kell majd fordítani, szóval Maven ne legyen feltétele a fordításnak.

Én Sublime Text 2-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az IDEA, NetBeans, Eclipse (ebben a sorrendben ajánlanám őket).

Kommit-policy

Mivel állítólag a kódolás csapatmunka, nem illik a master ágba csak úgy belekommitkodni, szóval érdemes mindenkinek saját ágon dolgoznia, és ott gyakran kommittolnia. A gyakran úgy van értve, hogy ha a kommit megfogalmazásában szerepel az és szó, akkor már elfelejtettél egy kommitot. Magyarul a kommitok atomiak, 5-10 sor kód legyen bennük max (nyilván lehet, hogy több is lesz, de célszer ilyen nagyságrendben mozogni).

Parasztság syntax erroros kódot kommittolni, ilyet ne tegyünk, ellenkező esetben a vétkes sarokba állítható tetszőleges időtartamra.

Kódolni nehéz

Fogadjuk el, hogy úgyis szar kódot fogunk írni elsőre, ne is próbáljunk mentegetőzni. Te sem, és én sem tudok elsőre jó kódot írni. Viszont a szar kódot újra kell írni, de minimum refaktorálni.

Ökölszabály, hogy ha egy egység (egy osztály) nem fér ki az editorban egy (max másfél) képernyőre, az a kód szar. Persze a szar kód is működhet, leadás előtt az ember meg annak is nagyon örül, ha egyáltalán lefordul, szóval ez a kód esztétikai értékét növelni, amire meg mondjuk a jó kóder tud áldozni az idejéből.

Kommentok

A kommentek alapvetően azért kellenek, hogy legyen miből doksit generálni. Ha kommentek nélkül nem érti valaki a kódot, akkor az a kód ismét csak szar, újra kell írni/tervezni.

Kódolási stílus

Többnyire minden editor csuklóból tud kódot formázni, ettől még érdemes valami egységes kódolási stílust betartani, és speciel sírva tudok fakadni a nem konzisztens whitespace használaton. Mindegy, hogy mit választotok, legyetek konzisztensek, a kód ne nézzen ki úgy, mint egy marék hányás.

Debug

Debuggolni nem könnyű, főleg egy grafikus játékot. Azért próbáljuk meg, és lehetőleg a System.out.println legyen az utolsó megoldás erre.

Egyéb megfontolásra érdemes dolgok

Adatszerkezet

Biztosan kell majd valamiféle adatokat tárolni, mondjuk egy játéktérképet, kapcsolási rajzot, stb. Ilyenkor az ember előveheti az XML-t, mint taktikai atomtöltetet, a JSON-t, mint ágyút, vagy kitalálhat valami kulcs:érték párokból álló saját hóttegyszerű szintaktikát, amivel lehet a verébre lövöldözni. A lényeg, hogy szerintem nem akartok kézzel XML-t írni.

Magic!

Ha nekiálltok tervezni UML diagramokat, mindig legyen fogalmatok arról, hogy ez kódban hogyan fog kinézni, illetve működni fog-e majd így a kódban. Ezzel a módszerrel elég sok alapvető hibát ki lehet szűrni. Ha ez nem megy, akkor jön az a szégyenteljes megoldás, hogy a cuccot le kell kódolni, majd a kódból kell előállítani a doksit (ugye alapvetően pont fordítva kéne). Ja és ezt nem tőlem hallottátok.

Konzulens

A konzulens tanácsait érdemes megfogadni, ő azért van ott, hogy ne csinálj hülyeséget (illetve megbasszon, ha hülyeséget csináltál).

A mi konzulensük tök jó fej volt, gyorsan válaszolt az emailekre (egyszer hajnali háromkor írtam neki, egy óra múlva már meg is jött válasz :D). Ha valami nem világos a feladatban, vagy nem vagytok biztosak benne, hogy jó úton haladtok, érdemes írni neki. Értékeléskor így is úgy is értékelni fogja a munkátokat, de olyankor már pontot fog levonni (kérdezni nem bűn). Ha olyan anyagot adtok be, amire már előtte is azt mondta, hogy begyere, az csak jót jelenthet.

Ha nem megy

Ha nem tudtok együtt dolgozni (valaki képtelen kódolni, rendes UML doksit csinálni, stb), de azért a motiváció megvan, akkor érdemes valami hatékony megoldást keríteni. Ez kb úgy tud működni, hogy mindenki csak arra a területre fog korlátozódni, amihez tényleg ért, magyarán a balanszot (mindenki kódol, mindenki dokumentál, mindenki UMLezik) el kell tolni egy jobb irányba. Az ezzel járó lustálkodást, többletmunkát csapaton belül kell lerendezni.

Értékelés

Minden feladatra kaptok egy értékelés a konzulenstől, a doksiban be lesz karikázva mi nem tetszett neki. Ezt érdemes feljegyezni, ugyanis az összefoglalásban meg fogja nézni, hogy kijavítottátok-e.

Feladatok

Mire kell figyelni az egyes heti leadott anyagokban. (Majd lesz... lennon (vita) 2013. január 19., 23:11 (CET))

Continuity

2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az elkészült dokumentáció összesen 214 oldal (elérhető nagyon hipszter Helvetica betűtípussal is). Forráskód (kizárólag okulási célokkal!)