Szerkesztő:Madbence/Szoftver labor 4 tanácsok

Személyes tapasztalataim, illetve tanácsaim az utókornak.

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.

Á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 módszer, 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?". Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni).

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 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.

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, 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 gyártani.

Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni.

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.

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.

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ő, ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy tutorialt, előbb utóbb felrakom. (lennon (vita) 2013. január 19., 23:11 (CET))

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.

Tervezés

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).

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).

Konzulens

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, hiszen értekeléskor így is úgy is visszajelzést kaptok a haladásról, csak éppen lehet, hogy a pontjaitok látják ennek kárát.

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 hipster Helvetica betűtípussal is). Forráskód (kizárólag okulási célokkal!)