• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    Diskuze o obzive programovanim pro starsi a pokrocile.
    rozbalit záhlaví
    JANFROG
    JANFROG --- ---
    MCHNCD: Tohle mozna spis patri do do spoluprace...
    JINX
    JINX --- ---
    MCHNCD: Potřebuješ napsat vlastní nebo chceš dodat data?
    MCHNCD
    MCHNCD --- ---
    Jen dotaz, nedelal ste nekdo scraper na firmy.cz v pythonu treba?
    NAVARA
    NAVARA --- ---
    VOY: Přesně :)
    VOY
    VOY --- ---
    MCHNCD: Ten naseptavac mimochodem generuje misto uvozovek kolem atributu apostrofy. A to ja... nemuzu akceptovat! ;-) (<img src='URL'>)
    MCHNCD
    MCHNCD --- ---
    sem se nudil a rikal sem si, jak me to gui nyxu v jistych aspektech celkem sere :) tak sem si to trosku poladil a
    kdyz sem to mel hotovy, tak mi typek rek, ze tu je naseptavac v textarea, ale stejne sem linej i na to, takze hazu do placu, kdyby si to nekdo chtel upravit, whatever ;]

    GitHub - paperbonsai/nyx_buttons: This function creates additional buttons for inserting image, video (mp4), spoiler, code and quote
    https://github.com/paperbonsai/nyx_buttons
    ANT_39
    ANT_39 --- ---
    VOY:
    vsechno co se ti uplne nezda das "needs work" a nepustis to dokud nebude po tvym
    Jasne, souhlasim. Muze se stat a stava se, ze reviewer neco identifikuje jako problem, kdyz to problem ve skutecnosti neni, nekdy je to treba edge case, kterej se da opravit jako follow-up, atd. Je to (resp. mela by to byt) diskuse. Ale jo, vim, ze takovy toxicky typy existuji. Ja osobne jsem s tim nastesti problem nemel, mam pricetny kolegy, se kteryma je rec.
    pokud nedej boze najdes na designu neco spatne uz nekde v tom prvnim commitu, tak se asi potkas s velkou rezistenci to cely predelavat
    Jestli je to zasadni designova chyba tak jo, to muze bejt prusvih, tam muzes kvuli tomu predelavat zbyvajicich tricet commitu, co mas navrseny nad tim, nebo to zrovna zahodit a prepsat. Tam by melo byt setsakra dobre vyargumentovany, proc je to spatne tak, jak to je, ne ze "I feel like X would be better". Ale kdyz to fakt je blbe, tak... no je to holt blbe, no, a musi se to predelat ^o^. A je na miste ptat se, kdo ten design delal a proc jsme si toho nevsimli driv :)
    E2E4
    E2E4 --- ---
    VOY: tak ono to je i o kultuře obecně, pokud je moc velkej důraz na osobní odpovědnost, nebo málo tymovosti tak si buď dělá každej to svoje podle čeho je hodnocen, a není ochoten investovat čas do úspěchu někoho jinýho, nebo prostě kvůli svýmu egu vnucuje změny který jsou v danou fázi zbytečný z hlediska poměru cena/výkon..

    já jsem to zažil, jak to funguje když to funguje a je to super, ale asi to je fakt vzácný, viz kerray.
    VOY
    VOY --- ---
    E2E4: Vsak tak nejak to funguje, vzdycky se nejak dohodneme jestli nejaka zmena v danym momentu dava smysl. Spis rikam, ze nejde pozvedavat kulturu tak, ze se postavis pred frontu PR a na vsechno co se ti uplne nezda das "needs work" a nepustis to dokud nebude po tvym. I takovy lidi jsem poznal a pracovat s nimi nebylo snadny, protoze to jaky zmeny jsou "nutny" muze byt hodne subjektivni. Ze nas proces neni idealni to klidne podepisu, ale zaroven zatim jsem zadny idealni nevidel. Prinejmensim povazuji za pozitivni, ze mame lidi dedikovani zlepsovani tech testu a taky ze tech testu pomerne velky mnozstvi vubec existuje, jinak bychom nejspis davno nebyli schopni to vyvijet dal.

    Samozrejme delat maly lehce reviewovatelny PRs je nejlepsi a to pro me treba neznamena, ze udelam obrovsky PR, ktery je ale rozdeleny na 10 mensich commitu. Ono to review sice usnadni, ale pokud nedej boze najdes na designu neco spatne uz nekde v tom prvnim commitu, tak se asi potkas s velkou rezistenci to cely predelavat. Navic GitHub pripadne interni nastroje co jsem zatim potkal tomuhle reviewovani po commitech v ramci PR nevychazely vstric tak jak bych povazoval za idealni.
    KERRAY
    KERRAY --- ---
    já po 15 letech práce s kódem teprve teď jsem ve firmě, kde se dbá na štábní kulturu, ke všemu jsou testy, automatizace, a 'works on my machine' není ani zdaleka dostačující na to, aby se to pouštělo dál - pro předchozí firmy nebylo programování hlavní náplň, nebo si to aspoň šéfové mysleli, a z toho, jak náročné a nákladné je dělat to pořádně, dbát, aby prošel jen dobře promyšlený, srozumitelný, otestovaný kód, by se dřívější šéfové osypali... co ale neviděli byly ty obří náklady na hašení požárů, přepisování, zaučování nováčků atd., které se tím uspoří
    E2E4
    E2E4 --- ---
    VOY: to mi přijde, že prostě není ideální kultura a proces. asi tu mame vysoký standard. :)

    přesně tyhle problémy způsobené tím, že na velké a složité codebase pracuje hodně lidí celý ten proces a kultura kolem něj řeší..

    a jak se píše o příspěvek níž, ty napíšeš komentář, a je na autorovi aby řekl "dobrej nápad ale v tyhle fázi to uděláme zatím bez něj". nemusí ho to blokovat dokud to reviewer neschválí..
    SULTHAN
    SULTHAN --- ---
    VOY: úplně nechápu. Pokud vidím nějaké možné vylepšení kódu, tak to tam napíšu. Třeba github nenechá mergnout, pokud všechny konverzace (tj. komentáře) nejsou resolved, tj. někdo si to musí minimálně přečíst a označit za "přečtené". Když se drobné detaily neopravují, tak se akorát vytváří technický dluh pro budoucnost.
    VOY
    VOY --- ---
    ANT_39: To je jednoduchy pozorovani, ze v kazdym tymu najdes lidi, ktery clicknou na approve uplne vseho a pak lidi co napisou spoustu komentaru a neni lehky je uspokojit. S tim to jestli sem Cech moc spolecneho nema. Samozrejme se snazim delat kvalitni review, abych mel pokud mozno co nejvetsi pozitivni dopad, kdyz uz nejaky cizi kod ctu.

    SULTHAN: Bavime se o opravdu nemale aplikaci postaveny na canvasu. Netrivialni frontend, na kterem pracuji najednou nizsi desitky tymu. Pracuji na frontendu uz celkem dlouho, rozhodne dost dlouho na to, abych vedel ze neni tym, pro ktery by bylo snadny udrzet tak velkou sadu testu stabilni a bleskove rychlou. Pokud je, tak jsem o nem zatim neslysel. Rada, ze pokud testy nejsou stabilni mam je zahodit je pomerne bezcenna, testy vubec nemusi byt nestabilni diky praci myho konkretniho tymu. Podstatne je, ze cim delsi feedback loop na PR a vetsi mnozstvi reviewers, tim mensi motivace delat opravdu malinky granularni PR. Navic vsechno jde ihned na produkci a vyvoj s feature flags taky neni uplne bez rizik.

    K tomu abych zablokoval PR requestovanim nejakych zmenu uz musim mit silnejsi duvod. Pokud chces rozumne vychazet s lidmi tak nemuzes na kazdy PR postnout wishlist mnoha zmen a blokovat dokud ti nebude vyhoveno. V tomhle mame kazdy nejaky socialni kredit, ktery je omezeny, a ja jim rozhodne neplytvam pokud to co k danemu PR chci rict neni zasadni.
    KOLCON
    KOLCON --- ---
    ANT_39: Nevím co je na tom českýho, nepozoruji že by se jiné národy chovaly nějak vzorně.

    KPI jsou problémem samy o sobě. Zabíjí to agilitu a lidi mají tendence optimalizovat na to kpi, podle kterýho jsou hodnocený. Což většinou nechceš.
    SULTHAN
    SULTHAN --- ---
    ANT_39: Když dá "request changes", tak žádný další approval ho nepřebije.
    ANT_39
    ANT_39 --- ---
    VOY: A jeste zvlast k tomu "kdyz to neapprovnu ja, udela to nekdo jinej". To je takovej... az karikaturne ceskej postoj, no. Kdyz bude v dobrym stavu aspon ta cast, ktera projde pres tebe, bude na tom projekt o kus lip, nez kdyz bude sracka durch vsechno. Ale jako jo, je to tochu boj s vetrnymi mlyny, zvlast kdyz jdou nejaky KPI proti tobe.
    ANT_39
    ANT_39 --- ---
    AMBIENTIUM: Dava smysl. Napsal jsem programator, ale samozrejme to muze byt uz nekdo driv, kdo rozhodne, co je atomicky z hlediska mergovani. Programator pak resi jen rozdeleni na commity, logickou progresi commitu k nejakymi vysledku, atd.

    Ad to CI, muze byt zadouci, aby CI dokazal projit kazdej prefix toho merge requestu. (Jen prvni patch, prvni plus druhy, to plus treti, atd.) Aby pak pri bisekcich nevznikaly ruzny nefunkcni bazmeky co nejdou testovat. Asi zalezi na projektu, u nas bisekce pouzivame celkem pravidelne, tak na to dost dbame.

    VOY: Jo, rozbita kultura je prusvih. Nejhorsi jsou code review po telefonu, kdy si dotycni dva neco povykladaji, vysledkem je approval, a nikdo nevi, v cem byl problem, a jak ho autor odargumentoval. V kodu to stopu nezanecha, v mailech / mergovacim nastroji taky ne.

    Co se tyce tech testu, nechapu, jakou to tu hraje roli. OK, mate noisy testy, to prece nikoho neomezuje v tom, co vrazi do merge a jak ho rozdeli na commity, ne?
    SULTHAN
    SULTHAN --- ---
    VOY: To je kec, já taky dělám na frontendu. Práce samozřejmě rozdělit na commity lze stejně jako kdekoliv jinde. Je pravda, že nějakou feature pak mezi větvema merguju jako velký balík, ale mám ji stejně rozdělenou do zvládnutelných commitů.
    Nerozumím souvislosti s e2e testy. Ano, jsou drahý, ale pokud je máš nespolehlivý, tak je rovnou zahoď. Na rozdělanou práci logicky nepíšeš e2e testy. Pokud máš nějaké náhodné pády v E2E testech, je to typicky buď chyba spojení (nám se stává poměrně málo, máme i retries) nebo máš chybu v testech.
    AMBIENTIUM
    AMBIENTIUM --- ---
    ANT_39: u nás jsou malý PR daný už při analýze, kdy ty tasky tvoříme a zapisujem do Jiry. Snažíme se jet metodou jeden task = jeden PR. Občas jsou subtasky a PR se dělá na každej subtask. Děláme to tak, aby po zamergování se to mohlo ihned releasnout, tzn. musí projít komplet CIčko. Pullrequesty jsou pak fakt docela malý. Obvykle se vejdeme do 300 řádků změn nebo novejch. Ano, trávíme víc času na analýze a promýšlíme to docela do detailu, ale osvědčilo se to.
    VOY
    VOY --- ---
    ANT_39: Zcela s tebou souhlasim, ale bohuzel v praxi tam kde pracuji ja (na frontendu) tohle neni casto dost dobre mozny zajistit, protoze jednak smysluplna zmena je casto dost velka a i kdyz by se principielne rozdelit dala, tak te treba muzou brzdit drahy a nespolehlivy E2E testy. Dalsi vec je, ze kdyz na to approval nedam ja tak on se nekdo jiny uz najde a to je valka co nevyhrajes.

    Samozrejme na cokoliv se da namitnout, ze proces se da zlepsit, ale to je jednak ve velky firme beh na dlouhou trat, druhak sem jeste ve svem zivote nevidel ani neslysel o firme, kde by frontendovy integracni testy fungovaly rychle a bez nutnosti je sem tam restartovat, aby prosly.

    Ale jak rikam, mluvim ze svoji specificky perspektivy na frontendu, v zavislosti na tom v jake oblasti delas to muze byt lehci.
    ANT_39
    ANT_39 --- ---
    VOY: IMHO zajistit, aby byl merge request dostatecne dobre definovanej, rozsekanej na atomicky reviewovatelny patche a s dostatecnou dokumentaci / commit messagema / atd. je zodpovednost autora. Pokud jako reviewer dostanu na stul blbe rozsekanej blob, kde neni jasny co je cilem nebo nejakej patch dela vic, nez by mel, tak holt bounce. A to je zase zodpovednost reviewera, aby to bouncnul. Od toho mame interaktivni rebase, aby slo praci prezentovat srozumitelne.

    Tahle disciplina pak dost pomaha pri blamovani, kdy je mozny se doblamovat ke commitu s rozumnou commit message, kde je napsany, proc jsou veci tak, jak jsou. Coz dale emancipuje juniory, protoze si spoustu otazek dokazou zodpovedet sami a nejsou zavisli na buddym nebo seniorovi.
    JARDABEREZA
    JARDABEREZA --- ---
    VOY: No tady časová dotace na code review nebyla a oni to dělali fakt důkladně a snaží se, aby jedno PR řešilo jednu věc a dalo se v tom vyznat. Takže dokud si nejsou jistý, že to tak chtějí nepouští to dál. Případně se zjistí, že je třeba něco spravit, tak to tam visí delší dobu, než se dokončí jiný PR, který opravuje chybu.

    Ono taky záleží jaká je tvoje role dodavatele. Např. daňový poradci mají povinně pojištění profesní odpovědnosti za škody. Oni mi sice řeknou, ať si to pročtu jestli tam někde není chyba, jenže já tomu vůbec nerozumím a proto si je přece platím.

    Ale u téhle korporace jsem jako pomocná síla. Tzn. jejich zaměstnanci by měli znát produkt lépe anebo přinejmenším stejně jako já. A když je něco nejasné, tak se o tom samozřejmě pobavíme. Pokud by si mě najali na něco, co oni sami neumí a nerozumí tomu, tak přiznávám, že to je alibistický.

    No a pokud tam tu chybu stejně pustím, tak budu první, kdo se bude hlásit o opravu :-)
    Kliknutím sem můžete změnit nastavení reklam