„Szerkesztő:Madbence/Szoftver labor 4 tanácsok” változatai közötti eltérés
Saját tapasztalataim/tanácsaim szoftlab4-re. |
a Hierarchia átalakítva |
||
| 2. sor: | 2. sor: | ||
=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. | ||
==Á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. | ||
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). | 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ó== | ===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 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. | ||
| 14. sor: | 14. sor: | ||
=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 gyártani. | 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 gyártani. | ||
Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. | Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. | ||
==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. | ||
==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. | ||
===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]], előbb utóbb felrakom. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET)) | [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]], előbb utóbb felrakom. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET)) | ||
=Kód= | =Kód= | ||
| 35. sor: | 35. sor: | ||
# Profit! | # Profit! | ||
==Editor== | ===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 [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak. | É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 [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak. | ||
É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= | ||
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). | ||
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). | 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= | ===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. | 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 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= | ||
A lap 2013. január 20., 00:12-kori változata
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ó:
- 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
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!)
