„Szerkesztő:Madbence/Szoftver labor 4 tanácsok” változatai közötti eltérés
a →Git |
Egy plusz megoldás belinkelve. |
||
| (4 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva) | |||
| 1. sor: | 1. sor: | ||
Személyes tapasztalataim, illetve tanácsaim az utókornak. | Személyes tapasztalataim, illetve tanácsaim az utókornak. Utoljára frissült: [[Szerkesztő:Madbence|lennon]]<sup>[[Szerkesztővita:Madbence|(vita)]]</sup> 2013. január 21., 07:40 (CET) | ||
=A csapat= | =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. | 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=== | ===Á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. | 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. (Kivételek persze vannak.) | ||
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 | 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?''", (szinte) 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ó=== | ===Kommunikáció=== | ||
Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot). | Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com 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. | 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. | ||
Gyakorlatilag '''a siker kulcsa a kommunikáció''', minden ezen múlik. A feladatokat érdemesebb minél atomibb, minél kisebb részekre bontani, és '''folyamatosan''' egyeztetni. Máshogy nagyon nehéz (egész egyszerűen amiatt, hogy mindenki a saját munkatempójához, gondolkodásmódjához szokott, és a kooperációhoz meg kell ismerni egymást). | |||
Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni. | Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni. | ||
=Kollaboráció= | =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. | Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni. | ||
===Doksi=== | ===Doksi=== | ||
Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ 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 | Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ 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 [http://en.wikipedia.org/wiki/LaTeX LaTeX]-et ([[Dokumentumszerkesztés|Van is rá tárgy]]). A [https://www.sharelatex.com/ ShareLaTeX] oldalon lehet kollaborálkodni is, illetve ha éppen nincsenek kéznél a binárisok, neten, [http://manuels.github.com/texlive.js/website/ on-the-fly is lehet pdf-et generálni] (az [http://github.com/kripken/emscripten emscripten] csodákra képes :D). | |||
'''''Update''' --[[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2018. május 28., 07:02 (UTC)'': Legalábbis 2018-ban már előre kiadott docx fájlokat kellett kiegészíteni, és ezeket kellett dokumentációként leadni. Mi az egészet felraktuk egy Google Drive mappába, és ott Google Docs-szal kényelmesen lehetett csapatban szerkesztgetni. | |||
===UML=== | ===UML=== | ||
Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ 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. | Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ 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=== | ===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. | 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==== | ====SVN==== | ||
Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek. | Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek. | ||
====Mercurial==== | ====Mercurial==== | ||
A [http://mercurial.selenic.com/ 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 | A [http://mercurial.selenic.com/ 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==== | ====Git==== | ||
[http://git-scm.com/ Az áltimét verziókezelő], '''ha tudod kezelni, mással nem is érdemes foglalkozni'''. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial|tutorialt]], még most is viszonylag használhatónak tartom. | [http://git-scm.com/ Az áltimét verziókezelő] (szintén DVCS), '''ha tudod kezelni, mással nem is érdemes foglalkozni'''. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial|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= | =Kód= | ||
| 40. sor: | 62. sor: | ||
Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket). | Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket). | ||
===Kommit-policy=== | ===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). | 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. | 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=== | ===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. | 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. | Ö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=== | ===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. | 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=== | ===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. | 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=== | ===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. | 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= | =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 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. | |||
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 | |||
===Ha nem megy=== | ===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. | 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=== | ===É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. | 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= | =Feladatok= | ||
Mire kell figyelni az egyes heti leadott anyagokban. (Majd lesz... [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET)) | Mire kell figyelni az egyes heti leadott anyagokban. (Majd lesz... [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET)) | ||
=Continuity= | =Continuity= | ||
2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon | 2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon hipszter Helvetica] betűtípussal is). [https://github.com/madbence/fearlesscode_szoftlab Forráskód] (kizárólag okulási célokkal!) | ||
''Update:'' mi pedig 2018 tavaszán csináltuk, a kód, a doksi és néhány bónusz jó tanács elérhető [https://git.sch.bme.hu/schulczf/killer_sokoban itt]. (Jeles értékelést kaptunk.) | |||
A lap jelenlegi, 2018. május 28., 08:10-kori változata
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. (Kivételek persze vannak.)
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?", (szinte) 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.
Gyakorlatilag a siker kulcsa a kommunikáció, minden ezen múlik. A feladatokat érdemesebb minél atomibb, minél kisebb részekre bontani, és folyamatosan egyeztetni. Máshogy nagyon nehéz (egész egyszerűen amiatt, hogy mindenki a saját munkatempójához, gondolkodásmódjához szokott, és a kooperációhoz meg kell ismerni egymást).
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).
Update --Schulcz Ferenc (vita) 2018. május 28., 07:02 (UTC): Legalábbis 2018-ban már előre kiadott docx fájlokat kellett kiegészíteni, és ezeket kellett dokumentációként leadni. Mi az egészet felraktuk egy Google Drive mappába, és ott Google Docs-szal kényelmesen lehetett csapatban szerkesztgetni.
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ó:
- Kódolj
- Ha kész van, nézd meg, hogy bonyolult-e. Ha igen, kezd elölről.
- 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!)
Update: mi pedig 2018 tavaszán csináltuk, a kód, a doksi és néhány bónusz jó tanács elérhető itt. (Jeles értékelést kaptunk.)
