Coding style v týmu

[Franta <xkucf03/>]

Vseobecne se nebat investovat do kvalitnich vyvojovych nastroju - kuprikladu https://jazz.net/downloads/ a nepouzivat SVN protoze "je to zadarmo". Efektivita pri pouziti spravnych nastroju je asi 5x vyssi nez kdyz lidi pouzivaji veci jako vim, git, mantis atd.

Lenine, necpi nám sem ty svoje marketingové sračky. Vyvíjet se dá kvalitně i čistě s pomocí svobodného softwaru (Mercurial, Bazaar, Git, Trac, Bugzilla, Review Board, FindBugs…). Není potřeba (ani vhodné) si budovat závislosti na nějakých proprietárních produktech, a zadělávat si tak na problémy v budoucnu.

[Reklama]

[Juro]

Není potřeba (ani vhodné) si budovat závislosti na nějakých proprietárních produktech, a zadělávat si tak na problémy v budoucnu.

Presiel som si niekolkokrat migraciou na rozne tooly, ci uz boli open source alebo komercne.  Podla mna je to jedna z najmensich a najslabsich zavislosti, ktore vobec mozu byt. Raz zmigrujes tak ci tak. Vsetky tooly, ktore som pouzival pred 10 rokmi zapadli prachom a vela z tych, ktore som pouzival pred 5 rokmi ma omnoho lepsie alternativy. A nehovorim o tom, ze po niekolkych rokoch v IT firme je casto polovica osadenstva uplne ina, maju ine preferencie atd. Pouzivaj, co zvysuje efektivitu. Pokial to nerobi garazovka, je k tomu support a existuje vacsia komunita.

[Franta <xkucf03/>]

Podla mna je to jedna z najmensich a najslabsich zavislosti, ktore vobec mozu byt.

V jak velké firmě? Tohle může fungovat ve firmičce tvořené dvěma třemi kamarády – ve větších firmách je tahle infrastruktura dost klíčová a rozhodně se nemění ze dne na den. Mám zkušenost s tím, že se používají i dost staré nástroje, protože přejít jinam by bylo příliš drahé. Migrace rozhodně není zadarmo a jednoduchá, je potřeba upravit všechny procesy, přeškolit lidi…

[Lenin POWER!]

Ono je jedna vec take nastroje na zvysenie produktivity niekam implementovat, ale druha naucit ludi pracovat s nimi. Ten nastroj moze byt dobry ale ked ludia co s nim pracuju su flakaci a su lahostajni, tak mi ani nejaku extra program nepomoze.

Kdyz je nekdo flakac a dlabe na to tak to pochopitelne vyhodit bez diskuzi. Pak si vyslechnes scenu narikajiciho loosera nad tim ze ma deti a hypoteku a prijde o barak. Kdyz bude vyhrozovat okamzite mu jednu jebnout po rypaku.

Ono je ten jazz a jeho produkty fajn co som pozeral video, ale tiez to chce disciplinu a urcity workflow, inak to je dalsia vec, ktora len ludi brzdi a beru to ako zlo.
Bez discipliny v zivote nikdy nic nedokazes. Jaky maji na to zamestanci nazor na tom nesejde, protoze nemaji rozhodovaci pravomoce ovlivnujici proces. Musi se rozhodnout za sebe zda to budou ci nebudou dodrzovat. Kdyz ne, tak okamzite kopacky, at neblokuji misto jinym.

Proste lidi co nechteji jit s tebou tvoji cestou vyhodis, jinak se k cili nedostanes nikdy.

[Juro]

Podla mna je to jedna z najmensich a najslabsich zavislosti, ktore vobec mozu byt.

V jak velké firmě? Tohle může fungovat ve firmičce tvořené dvěma třemi kamarády – ve větších firmách je tahle infrastruktura dost klíčová a rozhodně se nemění ze dne na den. Mám zkušenost s tím, že se používají i dost staré nástroje, protože přejít jinam by bylo příliš drahé. Migrace rozhodně není zadarmo a jednoduchá, je potřeba upravit všechny procesy, přeškolit lidi…

Tak do 50 ludi (v roznych firmach). To je podla mojho nazoru rozumna velkost spolocnosti, kde este mozes mat ako bezny programator vplyv na vyber nastrojov a uz si neni garazovka.

Moze boliet zmena veci, ktore maju priamy dopad na to, co ide k zakaznikovi - kompilator zdrojakov, setupu, verzia platformy, ina klucova kniznica atd. Naopak, zmena vyslovene internych nastrojov ako je style checker, build server, bug tracking, test case management, version control system (sic!) bola vzdy pomerne bezbolestna. Ano, nerobi sa to kazdy den, ale kazdych par rokov sa pritrafi, nieco to stoji ale nemyslim si, ze tam hrozi zasadny vendor-lock (mozno ten VCS ak pouzivas nejaku naozaj specificku feature kvoli specifickym potrebam). Ci je nieco proprietarne, nie je proste v komercnom prostredi K.O. kriterium

Co sa tyka procesov su popisane tak, ze nespominame konkretne nastroje. A potom mame jednoduche ,,tahaky" s pravidlami ku konkretnym toolom. Je to OK pre developerov aj ISO auditora. Preskolenie je minimum, su to povacsinou inteligentni chlapci. Zvysok vyhadzujem pri pohovore, v skusobnej dobe a ked nahodou zdegeneruju neskor, tak priebezne. 

K povodnej teme coding style. Ak ludia programuju ako prasce a ty vytrcas, zbav sa ich a najdi si sebe rovnocenny alebo lepsi tim. Ak aj uspesne zadefinujete coding style, budu dalej programovat ako prasce akurat sa naucia formatovat zdrojaky a pomenovavat premenne a metody. A ked ziskas skusenosti s pracou so sikovnejsimi ludmi, tak sa o par rokov mozes k tomuto vratit a pomahat rast juniorom.

[Reklama]

[Franta <xkucf03/>]

Juro, zažil jsem v jedné firmě migraci z jednoho komerčního VCS na jiný a ačkoli snaha byla, nakonec to vyústilo ve ztrátu historie – z každé větve se do nového systému zmigrovala (nakopírovala) jen poslední verze. Líp to udělat nešlo, aniž by to neparalyzovalo vývojový tým na (pro management) nepřijatelně dlouhou dobu. V jiné firmě se zase používá nějaký prehistorický (byť od věhlasné firmy) systém na správu požadavků/chyb, který vypadá jak aplikace z Windows 3.11. O migraci na něco modernějšího se uvažuje (už několikátým rokem) a teď (během příštího roku) už snad doopravdy bude. Co se týče těch procesů – je potřeba mít vše zdokumentované a mít kompletní historii, být schopný ukázat, jaká chyba se kdy na jaké větvi řešila, kdo to opravil/vyvinul, kdo k tomu dělal revizi, kdo to testoval. A tyhle vazby je potřeba zachovat i po migraci na nové systémy.

[Juro]

Juro, zažil jsem v jedné firmě migraci z jednoho komerčního VCS na jiný a ačkoli snaha byla, nakonec to vyústilo ve ztrátu historie – z každé větve se do nového systému zmigrovala (nakopírovala) jen poslední verze. Líp to udělat nešlo...

...je potřeba mít vše zdokumentované a mít kompletní historii, být schopný ukázat, jaká chyba se kdy na jaké větvi řešila, kdo to opravil/vyvinul, kdo k tomu dělal revizi, kdo to testoval. A tyhle vazby je potřeba zachovat i po migraci na nové systémy.

No ano. Proste sa spravila hruba ciara, nasadil sa novy system, stary sa spristupnil len na citanie. Ziadna historia. Ked niekto potreboval nieco naozaj dohladat, siel do stareho. S casom ta potreba klesa. Vyvoj to neparalyzuje.

[alfonz]

Dakujem za diskusiu, je dost zaujimava a aj inspirativna. Ak by sa uz teda nejaky ten coding style presadil, akymkolvek sposobom, vzdy tam budu chyby. lenze to nie su chyby programovacieho charakteru ale cisto z nepozornosti. Napr. jeden priklad za vsetky, mam triedu v ktorej je napr.

public class Trieda {
    private static final logger = Logger.getLogger(Trieda.class.getName());
    ....
}

Ide sa spravit dalsia trieda podobna tejto, tak chlapec skopci celu triedu a len zmeni implementaciu. Naco ale zabudne je to, ze musi prepisat aj triedu, v tom loggerovi

   private static final logger = Logger.getLogger(NovaTrieda.class.getName());

A to samozrejme zabudne. Na tomto krasne vidiet akym stylom programuje a ako je nepozorny ked takuto vec zabudne zmenit. Ja neviem ci je slepy alebo mu to je uplne fuk alebo na to jednoducho zabudol, ake ked sa to raz commitne tak tom tam uz zostane, potom ja takemu koderovi neverim ze svoju robotu zvladne ok ked nedokaze dat pozor na takuto hovadinu.

Lenze byt pozorny ludi nenaucite, ze ano .

[to_je_jedno]

na to ti coding style nijak nepomuze.

[Mirek Prýmek]

    private static final logger = Logger.getLogger(Trieda.class.getName());

[...]
Na tomto krasne vidiet akym stylom programuje a ako je nepozorny

To jo - neuvést typ, to je velká nepozornost. Naštěstí ho na to překladač upozorní

Ja neviem ci je slepy alebo mu to je uplne fuk alebo na to jednoducho zabudol, ake ked sa to raz commitne tak tom tam uz zostane, potom ja takemu koderovi neverim ze svoju robotu zvladne ok ked nedokaze dat pozor na takuto hovadinu.

Lenze byt pozorny ludi nenaucite, ze ano .

Ale jo, já bych mu dal ještě šanci, on se ty typy uvádět naučí

[alfonz]

Ale jo, já bych mu dal ještě šanci, on se ty typy uvádět naučí

No lenze to je to Co ked nechcem nikoho nic ucit? Ja nemam ziadne rozhodovacie pravomoci, som tiez len "radovy" programator, ale hovorim to z pohladu zamestnavatela, lebo by som sa nim mozno niekedy v buducnosti rad stal. Ak by som mal nejakeho zamestnanca, ja ako firma nie som ziadna charita respektive nebudem nikomu robit nejaku "tutorial" firmu kde budu pracovat ludia "aby sa nieco naucili". To sa mali naucit niekde inde. Ked mam vysostne pravo niekoho zamestnat, tak ho nebudem zamestnavat len pre jeho modre oci a ked s nim nie som spokojny tak prec s nim. Nech sa to pre mna za mna nauci aj sam doma a potom si ide hladat pracu.

Je iny pripad, ked sa uci nejaku novu vec, ale toto suvisi s jeho kvalitou ako takou a aj s jeho osobnostym profilom a ja nemozem cakat na to, ze on sa za pol roka odnauci flakat veci. To je nonsens.

[cdcd]

Je hezké, že to máš tak promyšlené, ale má to trochu trhliny. Špatný programátor bude levný. Průměrný programátor bude dražší, ale zase možná i něco nabídne. Nadprůměrný programátor bude poměrně dražší a náročnější na zaměstnavatele. Ty nejlepší už nemáš šanci zaplatit. Není třeba dodávat, že se dnes často raději najmou dva levní (špatní), než jeden kvalitní.

Žádná charita není potřeba, pokud to můžeš zaplatit a nabízíš nadstandardní pracovní prostředí.

[Lenin POWER!]

Ten pripad s tim logem neni chyba kodera ale chyba procesu:

1. dela copy & paste textu nez aby udelal copy and paste class objektu (coz mu IDE zrefaktoruje)
2. je to velmi bezna chyba. Tu ma chytat automaticka staticka analyza
3. vyse platu se schopnostmi programatora nesouvisi. Neprogramuje s vyuzitim penez ktere za to dostane.
4. Zda sezene schopne lidi zalezi na tom jak je umi vyhledavat a motivovat.
5. delat tutorial firmu je pitomost, ja to taky nedelam.
6. Doma se to lidi nenauci. Mysli si totiz ze by se okradli tim ze by neco delali zadarmo. Misto toho se snazi uhrat ten prijimaci rozhovor.

[Mirek Prýmek]

Co ked nechcem nikoho nic ucit?

Nežereš maso, nepoznáš vtip.

[ded kenedy]

mam tu 2 maniky co delaji na hadoopu. Patlaji to ve vimu v ubuntu a maji 5x mensi pocet naprogramovanych radku denne nez nas standardni javista. Nenechaji si to vymluvit a tak jsem jim dal polovicni plat a na konci roku je vyhodim.

To se hned pozna pozorny sef. Co jsem zkousel tooly pro Hadoop, tak vetsinou byly naprosto k nicemu a bylo lepsi si napsat sadu vlastnich nastroju v bashi/vimu uzpusobenych na konkretni problem. Vetsi zabijak produktivity na Hadoopu je absence kvalitni dokumentace k poslednim verzim, ale to je chyba zamestnancu, ze si ji ve volnem case nedopsali, a proto zaslouzi polovicni plat.

Jinak, to ze jsi schopen merit efektivitu programatora poctem radku, ukazuje hodne na to, jak moc rozumis programovani.

Ak by som mal nejakeho zamestnanca, ja ako firma nie som ziadna charita respektive nebudem nikomu robit nejaku "tutorial" firmu kde budu pracovat ludia "aby sa nieco naucili". To sa mali naucit niekde inde.

Az budes mit vlastni firmu, pochopis, ze svet funguje uplne jinak. Obcas budes rad, ze u tebe vubec nekdo bude chtit pracovat.