Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: alfonz 02. 11. 2012, 23:25:44
-
Ja by som najradsej programoval sam. Na spolukoderov / kolegov sa proste neda spolahnut. A to nie som este "naplno" v praxi. Mne sa zda, ze vela krat spolupraca brzdi vyvoj ako ho ulahcuje. Kazdy si nieco nejako robi po svojom a vysvetlit im to ... ja by som bol oznaceny za toho, kto ma problem.
Zoberme si napr. formatovanie / uprava zdrojoveho kodu. Ja som asi paranoidny ale pre mna je spravne naformatovany a okomentovany kod alfa a omega, niekedy casto rozmyslam aj nad tym ako nejaku metodu alebo premennu pomenovat a je mi na prd ked vidim ako to tam ostatni hadzu hlava nehlava. Potom ten kod nie je vobec konzistentny a dokonca jeden vyvojar ani nedodrziava trvalo jeden styl kodu po cely projekt. Proste to tam pisu ako ich napadne.
Mate vo firme / vyvojovom time nejaku specifikaciu "ako sa programuje" alebo sa to neriesi a riesi sa to slovnym dohovorom?
V eclipse je nieco ako sablona na zdrojovy kod (napr. na javu) co je jedno xmlko, takze na to, aby bol kod konzistentny pri automatickom formatovani staci, ked je IDE kazdeho vyvojara nastavene rovnako. To sa mi ale zda ako absolutne minimum. Neviem ci sa to parsuje automaticky, ale napr. ked mam v if-e zretazene || alebo && a je to dlhe, tak je dobry standard pisat tie operatory na zaciatok noveho riadku a nenechat ich na konci. Toto ale myslim ze tie automaticke formatovace zdrojakov (to ctrl+shift+f a podobne) tusim neriesia ... (vsetko to hodi na jeden riadok a je to dlhe jak sliz).
Proste ludom chyba cit pre detail.
Suvisi to aj s nedavnym clankom "ako spravne pisat commity". Ono sa to zda ako blbina ale pri projektoch je ta disciplina fakt dolezita. Mate nejake rady, ako postupujete, aby sa vam projekt pocas vyvoja nezosypal po formalnej stranke?
-
Atoformat v eclipse a pred metodou nejaky koment a som spokojny, kto by to nerobil tak ho jebal pes na teamovych projektoch
-
presne tak, autoformat v eclipse staci. Pokud neni customizovatelnost eclipsu dostatecna tak si napiste do eclipsu plugin co to pri save preformatuje.
V zadnem pripade nenutit programatorum aby delali rucne formatovani a tvrde to vyzadovat.
Pouzivejte standardni code style kde se jenom da a ktery umi pak analyzovat dostupne tooly. Z praxi vim, ze ty teamy co si vymysleji vlastni produkuji hnuj, protoze nejsou schopni pochopit proc to Rational SW doporucuje delat takto.
Kod ma byt snadno udrzovatelny - kuprikladu jednoduchy maven vs zprasene ant build.xml. Dale je nutnost mit sve maven repo + repo manager (artifactory, ...) a automatizovany continualni build system.
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.
-
Efektivita pri pouziti spravnych nastroju je asi 5x vyssi nez kdyz lidi pouzivaji veci jako vim, git, mantis atd.
To si vycucal ze zadku nebo to necim podlozis?
Ne ze bych z praxe nemohl uvest sposutu prikladu jako Jira vs tebou zminenej Mantis/Bugzilla, ale takovyhle numera hazet je proste jen pustej kec.
-
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.
JIRA je hnuj, to jsem urcite nedoporucoval.
-
Jasne, tak doporuc naky svoje notes-based-like reseni, at se z toho vsichni posereme :) koukam po tvych podlozenych datech tady nemame o cem dal moc kecat.
-
mne sa zda JIRA dost pomala ale funkcionalita je celkom ok, bugzilla ... neviem.
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.
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.
ja si programovanie s autocomplete (magicke ctrl + space) ani neviem predstavit, myslim, ze ked by som mal napisat v notepade validny java kod (alebo akykolvek), tak by som mal problem :D veci ako ctrl + space a doplni vam to komplet funkciu po ktorej beham tab-om a pisem navratovy typ, nazov funkcie a argumenty je k nezaplateniu. clovek sa tak moze venovat tomu co riesi a nemotat sa okolo "co" ale "ako". (alebo naopak, ved chapete).
-
Mate vo firme / vyvojovom time nejaku specifikaciu "ako sa programuje" alebo sa to neriesi a riesi sa to slovnym dohovorom?
mam to stesti, ze mi nezbyva nez psat podle http://drupal.org/coding-standards . i pri zachovani co nejvetsi svobody apod je nutny tohle dat restriktivne a vyzadovat tvrde, v opacnem pripade se to opravdu stava brzdou vyvoje. Stejne jak bug tracker a version system.
Nastesti nejaky sikovny clovek exportoval to pro me spravne nastaveni do netbeanu a tim padem nad necim takovym vubec nemusim premyslet. Pro eclipse to taky nekde bylo, z ceho teda usuzuju ze neni tak tezky tem lidem pripravit editor aby jim to psalo samo.
-
... maji 5x mensi pocet naprogramovanych radku denne ...
[/quot
To maju tvoji zamestnanci pomerne zle. Ked programuju efektivne, tak za to budu vyhodeni. Vzdy som sa divil ludom, co aj spojak napisali na 1000 riadkov (a ludom, ktorym sa to chcelo citat), ale proti gustu...
-
mam to stesti, ze mi nezbyva nez psat podle http://drupal.org/coding-standards . i pri zachovani co nejvetsi svobody apod je nutny tohle dat restriktivne a vyzadovat tvrde, v opacnem pripade se to opravdu stava brzdou vyvoje. Stejne jak bug tracker a version system.
To je sice pravda, jenže je nutné aby pravidla stanovoval odborník a ne ignoranti tak jako v případě Drupalu, jinak jde do kytek celý tým.
-
mam to stesti, ze mi nezbyva nez psat podle http://drupal.org/coding-standards . i pri zachovani co nejvetsi svobody apod je nutny tohle dat restriktivne a vyzadovat tvrde, v opacnem pripade se to opravdu stava brzdou vyvoje. Stejne jak bug tracker a version system.
To je sice pravda, jenže je nutné aby pravidla stanovoval odborník a ne ignoranti tak jako v případě Drupalu, jinak jde do kytek celý tým.
hm, mozna ignoranti, ale spousta schopnych vyvojaru s tim nema problem. vzdyt je to vlastne jen o nastaveni editoru a chvilku si zvyknout. ono je taky lepsi nez neco vymyslet si osvojit neco co je bezne pouzivane.
-
hm, mozna ignoranti, ale spousta schopnych vyvojaru s tim nema problem. vzdyt je to vlastne jen o nastaveni editoru a chvilku si zvyknout. ono je taky lepsi nez neco vymyslet si osvojit neco co je bezne pouzivane.
No to se tak zdá na první pohled, jenže coding style nepřímo ovlivňuje tvůj způsob práce a uvažování a proto by měl být zvolen s mimořádnou péčí.
Také se uplatňuje tradiční vlastnost diktatury, je-li diktátor schopný tak diktatura prosperuje, je-li neschopný tak upadá :)
-
netvrdim opak.
-
Ja by som najradsej programoval sam. Na spolukoderov / kolegov sa proste neda spolahnut. A to nie som este "naplno" v praxi. Mne sa zda, ze vela krat spolupraca brzdi vyvoj ako ho ulahcuje. Kazdy si nieco nejako robi po svojom a vysvetlit im to ... ja by som bol oznaceny za toho, kto ma problem.
Jestli to tak je, dej to přečíst kolegům. Oni jsou totiž lemplové, bastlíři a amatéři. Řád je jeden z předpokladů úspěšného a kvalitního programování. Sám o sobě nic nezaručuje, ale lecos naznačuje. Zatím co Tvoje cena na trhu poroste, oni budou nezajímavý průměr. Nenech se odradit!
PS: jsou firmy, kde coding style/format hlídají v pre-commit a pokud to není ok, nepustí je to dál
-
V práci máme to XMLko do Eclipse (i když bych něco třeba dělal jinak, respektuji ho a jsem rád za jednotný styl) a asi u všech projektů, kam jsem přispíval, byla sepsané pravidla a vyžadovalo se jejich dodržování.
-
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.
-
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.
-
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…
-
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.
-
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.
-
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, 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.
-
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 .
-
na to ti coding style nijak nepomuze.
-
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čí :)
-
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.
-
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í.
-
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.
-
Co ked nechcem nikoho nic ucit?
Nežereš maso, nepoznáš vtip.
-
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.
-
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.
Měřit efektivitu programátora počtem napsaných řádků je jako měřit efektivitu markeťáka počtem slajdů v prezentaci. Ale jestli je cílem mít tam pouze exoty, jejichž kód každou chvíli končí na The Daily WTF, jste na nejlepší cestě ;-)
-
Akoze lenin sa tu z casu na cas objavi, ale pri jeho prispevkoch sa vzdy usmievam. Ako napriek tomu ze som makac a pomerny puntickar, by som neustale zil v strese ze nieco nahodou niekde, a potom ma lenin ukrizuje.
Na jednu stranu sa mi pacia jeho naroky, akoze ano, niekde kde to ma slapat a neni to garazova flakaren, to tak holt asi musi byt, ale na druhu stranu neni to az moc?
Neviem, jednak ten pristup beriem, ale jednak by som ho nad sebou mat nechcel :) je to freak. Vzdy cakam ze pusti nejake vacsie info o sebe, co vlastne v USA robi, ci on je sef / majitel alebo nie, popripade co vlastne sam vie :) ale bohuzial nikdy nic
-
Na jednu stranu sa mi pacia jeho naroky, akoze ano, niekde kde to ma slapat a neni to garazova flakaren, to tak holt asi musi byt, ale na druhu stranu neni to az moc?
Docela vtipný pohled :-) Ve skutečnosti je to přesně naopak – nejlepší zašívárnu člověk najde ve velké firmě. Pokud se chceš flákat, čím větší firma, tím lépe pro tebe. Naopak v garážovkách to moc nejde – taková firma neutáhne lidi, kteří nic nedělají (spíš často není schopná zaplatit ani ty, kteří pracují) a náklady na byť jediného flákače jsou strašně znát. Jeden flákač v garážovce může rozhodnout o tom, že to majitel vzdá a zabalí. Zatímco tisíce flákačů ve firmách typu Microsoft můžou vesele vegetovat, aniž by si toho někdo všiml – zákazníci (pacienti) jsou na mizernou kvalitu produktů a služeb zvyklí a management má dost svých vlastních problémů.