Vlákno názorů k článku Připravenost IT studentů pro praxi… je čím dál horší od honza - Já se autora musím zastat, každý kdo dělal...

Já se autora musím zastat, každý kdo dělal na nějakém větším projektu (jak do počtu lidí, tak trvání plus např. následný support) podle mě vidí, že procesní řízení a kooperace v týmu jsou nutnou podmínkou, aby se projekt dotáhl do cíle alespoň v trochu použitelném stavu. Mít v týmu vývojáře všeználka, kterému je vše jasné, všichni ostatní jsou pro něj jen blbý manažeři/zákaz­níci/obchoďáci je nejrychlejší cesta do pekel, pokud se ho nepodaří včas usměrnit nebo vyměnit. Prostě nejenom technologie ale i orientace v systému řízení firmy a projektu je pro vývojáře nutnost (pokud tedy chce být užitečný a dostat se k zajímavým projektům).

A pravda taky je, že bych u juniorních vývojářů ze školy čekal nějaký minimální přehled v tom, že zdrojáky jsou v svn, že existuje něco jako dev, test, pilot, produkce prostředí, build a release management, vykazování práce, codereview, odhady praqcnosti, psaní testů, doumentace, logování a audit v aplikaci(to je vždy velké překvapení), bezpečnost, integrace do dalších firemních systémů, různe metodiky vývoje a spousta dalších věcí, který dle mě vývojář musí znát, ale které přímo nesouvisejí z algoritmizací. Obecně na projektech, které dělám, je to snad i důležitější, než znát složitosti algoritmů.

A ještě poznámka, jsem zastánce toho aby i poslední junior vývojář věděl co je cílem celé aplikace, aby znal požadavky zákazníka aby měl přehled, kam vývoj směřuje. Aby věděl, jak vlastně zakázka vzniká, že se řeší nějaká konkrétní potřeba zákazníka a že se to celé musí také zákazníkovi i zaměstanvateli vyplatit. Tedy business věci okolo vývoje (asi největší oblast pohrdání rádobyexpertů).

Pravdou je, že tyto věci začínající vývojáři většinou vůbec netuší, jestli je to má naučit škola nebo samovzdělávání podle knížek nebo interní firemní kurzy je na diskuzi. Ale samozřejmě když to nezná, tak to jsou náklady navíc pro firmu. A pro kritiky v diskuzi - jestli se bez výše zmíněných věcí obejdete, tak fakt nechápu, co za projekty děláte.

Ale uznávám, že když jsem byl mladej a nezkušenej, tak jsem dfense taky žral a manažeři pro mě byli zmrdi a byl jsem přesvědčenej, že bych to dělal mnohem lépe. Pro ty co tu házejí zmrdama, dejte pozor, dfens psal ještě o druhé velké skupině - ichtylech - abyste do ní náhodou pro změnu nepatřili vy.

Abych předešel urážkám, jsem vývojář ne manažer.

Ještě podotek, nejsem tak starý abych mohl dobře posuzovat dobu před 10 - 15 lety, ale řekl bych, že se od té doby výrazně změnila celá doména problémů které se řeší. Projektů je mnohem víc a složitějších, bez oop a design patterns se v podstatě neobejdete. Řekl bych, že tady školy právě výrazně zaostaly, připravují studenty na dobu a problémy, které tu už nejsou (v takové míře jako dřív).

honza

bez oop a design patterns se v podstatě neobejdete

Co přesně myslíte OOP (je docela rozdíl mezi OOP např. v Javě a Common Lispu)? A proč zrovna OOP?

V čem je to v těch jazycích jiné. Je jiný význam slova třída? Dědičnost? Hmm, to asi ne! OOP je způsob modelování reality. Implementace v jednotlivých jazycích se liší. Pro OOP design stačí UML.

V čem je to v těch jazycích jiné. Je jiný význam slova třída? Dědičnost? Hmm, to asi ne!

Na první pohled největší rozdíl je, že metody nejsou součástí tříd a dispatch lze provádět podle všech argumentů a nejen dle jejich typů.

Pro OOP design stačí UML.

Jak se v UML modelují např.: dědičnost, kde podtřída není podtyp, nebo multimetody?

Myslel jsem oop přístup ne nějaká konkrétní implementace. Je to prostě pohled na modelování a řešení daného problému. Za mých časů se to na střední škole neučilo vůbec a na vejšce okrajově.

Samozřejmě jsou i projekty, kde je oop přístup zbytečný nebo nevhodný, ale řekl bych, že v mainstreamu se bez toho neobejdete.

honza

Bez oop se v mhoha ohledech obejde sposuta vyvojaru. Nejradsi mam takovy, kteri maji plnou hubu vsemoznych technologii, a kdyz se jim podivam pres rameno, tak maj nejaky to visualko, natahaj tam mysi cosi ... sem tam doplni radek ... a pritom vubec netusi, co to vlastne dela.

Pak nastane nejakej problem (jako ze nastane) a oni ho nejsou schopni vyresit. Pripadne to dopadne tak, ze aby se "problem vyresil" ... tak vyrobi cpy&paste na 150 ruznych mist, kde si mysli, ze by to mohlo byt ... cimz rozbije 150 jinych veci.

BTW: 99% projektu jsou relativne snadny a trivialni ulohy, potiz je, ze to, co se da napsat za odpoledne, pokud dotycny vi co dela, trva prevazne minimalne mesic, protoze dotycny ma sice "funkcni" sampl za 10 minut, ale pak mesic ladi co mu kde nefunguje ... a kod podle toho taky pak vypada.

Tohle je všechno pravda, ale bohužel to v tom článku docela chybí. A to málo co tam je se ztrácí v záplavě věcí určených pro zcela jinou cílovou skupinu.

To je ten zásadní problém článu (a pravděpodobně i knihy): je cílen na ty co mají ambici být "IT manažer". A to je fakt jiná množina lidí (s neprázdným průnikem, ale malým).

Chces predvest procesni rizeni v praxi?

Mejme funci X. Ta funkce dela neco nad dokladem Y. Obecne se vi, ze doklady typu Y vznikaji desitky/stovky ... => logicky by bylo, aby funkce X sla spustit nad N vybranymi doklady typu Y. Mno nejde, protoze nejaky ma(na)gor vymyslel ... ze nepujde.

Kdyz budu chtit aby sla ... tak musim kontaktovat nekoho ... na strane dodavatele... kdo vubec netusi vocogo. Ten nekdo, se pak bude ptat nekoho, kdo netusi stejne jako on, ale ma na starosti pozadavky zakazniku a kumunikuje je smerem k vyvojovymu tymu. Tenhle clovek pujde za sefem vyvojaru, a popta se ho ... nacez se dovi, ze se sef vyvojaru zepta ... tech dvou lidi, kteri o danym modulu maji paru. Kdyz se jich zepta, tak se celej tenhle tobogan rozjede pozpatku. Cely to trva min 14 dnu (a to v pripade, ze behem tech 14ti dnu 5x volam dotycnemu stycnemu neumeteli a 3x generelanimu rediteli, jinak je to klidne mesic i vic). => pak mi prijde nabidka, ze ta funkce bude fungovat nad vice dokladama ... za 100hod prace ... protoze je treba zaplatit vsechny tyhle zbytecny parazity ... a 10minut prace kodera.

Nebo ... volam na (procesne rizenej) hotline ... veme mi to tam clovek, kterej vubec nic netusi o tom, co potrebuju resit a de shanet cloveka, o kterym vim, ze to vi, ale na kteryho nemam primej kontakt, protoze to tak neni "procesne spravny".

Jste přesně ten všeználek, co ve firmě udělá jenom bordel. Ano, že ve vetší firmě je spoust režie okolo je pravda (u většího projektu s více lidma taky), ale zkuste se zamyslet taky nad tím, jestli to není z důvodu zastupitelnosti, udržitelnosti a zajištění kontinuity provozu firmy. Prostě ve firmě o více lidech a projektech je nutný vše dokumentovat a schvalovat. Nebo se tedy na to vše můžete vybodnout, udělat z toho one man show, ale pak vám takový člověk na 14 onemocní nebo odjede na dovolenou a jste víte kde.

Nejlepší jsou v tomto správci sítě a systémů, si jednoho dne takový jedinec řekne, tady to na produkci poladím, co bych se obtěžoval to projednávat s parazitama nad sebou, oni by mi to zdržovali nějakýma nesmyslnýma schůzkama, analýzama a bůhví čím dalším. Pak vyřadí provoz firmy na půl dne, správci ostatních systémů/aplikací hledají chybu u sebe, dalších 14 dní se analyzuje co se vlastně stalo. Zajímavé je, že všeználek v těchto chvílích bývá nezvykle potichu a nějak nemá tendenci se k tomu průšvihu taky hlásit. Podobnou škodu dokáže napáchat všeználek kodér, který se neobtěžuje dodržovat procesy vývoje a změn sw, protože paraziti.

Opravdu by mě zajímalo co děláte za projekty, tady píšete práce na 10 minut kodéra při nějakém change reqestu, v jiném příspěvku o projektu na odpoledne. Za 10 minut ani nepopíšete změnu kterou děláte, kde máte testy, kde máte analýzu dopadů změn atd.? Můžete mi dát příklad projektu na odpoledne? Já si to neumím představit, za tu dobu tak akorát stihnu připravit scm, issue tracker a wiki plus nějaký další věci okolo pro daný projekt.

dík
honza

Se ozval presne ten flakac, kterej petkrat za odpoledne pichne mysi do vizualka a zbytek dne ceka, az mu prijde pokyn neco udela.

Firmu, kde by vedel vic nez jeden clovek jak funguje jedna konkretni funkcionalita sem vzivote nevidel. Zato sem mockrat videl firmu (i o tisicich zamestnancu), kde to, jak neco funguje nevi vubec nikdo, a tak kolem toho chodi pekne po spickach a tvari se, ze to nevidi.

A to mam zkusenosti s vyvojem softiku za "par tisicovek" az s projektama za desitky mega ... ostatne, nejvic sem se pobavil, kdyz mi kamoska vypravela jak implementovali sap. To sem si rikal, ze jeste ze ten smejd o kterej se staram ja je celkem pristupnej zasahum zvenci, takze co mi dodavatel nedoda si do nej dobastlim.

BTW: Na jak dlouho ze by melo byt napsat cyklus, kterej bude volat funkci opakovane nad doklady z nejakyho pole? Minuta? Ja si to totiz umim zvenku zavolat sam, ale zvenku neudelam userum tlackatko, kterym by ten muj bastl spustili.

Takze to vypada tak, ze useri prijdou na IT a reknou "nad temahle 500 dokladama nam to puste", protoze si to sami udelat nemuzou.

Omlouám se za osobní výpad, nechal jsem se strhnout konfrontačním stylem diskuze. Jinak na všem ostatním trvám.

Vizulako nepoužívám, ale nic proti, je to nástroj, který se dá použít dobře nebo špatně, vhodně nebo nevhodně jako cokoliv dalšího.

Samozřejmě neznám váš konkrétní problém s doklady, ale první co mě bez velkého přemýšlení napadá. Co počet dokladů v cyklu, je nutné ho nějak omezit (např. má dopad na další systémy)? Je potřeba uživatele informovat o průběhu? Má mít možnost korektně cyklus přerušit? Jak se dozví, které byly upraveny a které ne? Může to dělat každý nebo jen některý uživatel? Kam se výsledné dokumenty ukládají nemůžu to při hromadné úpravě zahltit? Určitě to není práce na 10 minut.

honza

že jste neviděl, neznamená, žře neexistuje. Prošel jsem 3 firmy a v té poslední je "přikázána zastupitelnost", tj. když jeden má dovolenou musí být schopen někdo druhý dělat jeho práci.
A důvod je prostý, dovolené, nemoci atd. Pokdu děláte ve firmě kde to není a ani sám neškolíte někoho za sebe, neznamená to, že je to správně, ale naopak, že to vy osobně i manegerové posíííráte.