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ří

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í..

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.

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.

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š.

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.

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.

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 :-)

JARDABEREZA: To mi přijde jako v pohodě ošetření problému...

VOY: A jak za to má potom ručit autor kódu? Jako když podnikáš, tak neseš nějaké riziko a je na tobě, abys zajistil procesy, aby se práce kontrolovala. Něco jiného je, když na to zaměstnanec sere a chybu či dokonce škodu udělá schválně nebo mimo pravidla. Ale zaměstnanec nemá co nést riziko např. proto, že mu práci nikdo nekontroluje, nebo že třeba někde kód ani netestují a po půl roce se diví, že se jim koleje v týmu nešešly. Alibismus je to házet na zaměstnance. Má existovat moment, kdy je hotovo, odklepnuto, zkontrolováno.
Dodatečné úpravy či opravy, může stát, jsou pak nový úkol.

Když se mě jako OSVČ v roli kontraktora u jedné korporace ptali na pojištění škody, tak jsem řekl, že všechna moje práce půjde přes pull requesty, kde jejich zaměstnanci budou dělat code review a od toho okamžiku je to jejich problém. Co se ostatních věcí týče, tak dělám remote a nemám moc šanci jim fyzicky něco poškodit :-D. Stačilo jim to.