• ú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í
    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.
    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 :-)
    E2E4
    E2E4 --- ---
    VOY: no ale v takovým případě pak už ani nemá smysl dělat peer review u těch malých změn ;)
    KOLCON
    KOLCON --- ---
    JARDABEREZA: To mi přijde jako v pohodě ošetření problému...
    EUCHRID
    EUCHRID --- ---
    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.
    VOY
    VOY --- ---
    JARDABEREZA: To mi přijde jako poněkud alibistický přístup. Každý ví, že se problém do codebase může lehce dostat i přes veškerou snahu o kvalitní review a to zejména v případě kdy neexistuje disciplína dělání malých změn, u kterých ještě lze o kvalitním review vůbec mluvit. U nás např. někdo lehce změní 50-70 souborů a tam už reviewer při časové dotaci na review nemůže ručit prakticky za nic.
    JARDABEREZA
    JARDABEREZA --- ---
    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.
    ALMAD
    ALMAD --- ---
    KOLCON: Tady podle me hodne zalezi v jaky zemi a mezi jakejma subjektama, v mym sektoru se pojisteni b2b skod dela bezne a naopak korporaty od dodavatelu to pojisteni dost casto vyzadujou
    KOLCON
    KOLCON --- ---
    E2E4: To nevím... Když jsem kdysi zjišťoval to pojištění v b2b, byl to problém. Pojišťovny v tom viděly velké riziko, že se firmy mezi sebou domluví. Možná se situace změnila a jak to je u fyzických osob netuším.

    Řešil jsem to pro situace v automotive kde když zastavíš linku, může být každá minuta drahá.
    E2E4
    E2E4 --- ---
    KOLCON: čéče nevím, nexistuje pojištění statutárních orgánů fyzických osob za totéž?
    KOLCON
    KOLCON --- ---
    DWICH: Na byznys škody (druhotné) tě imho nikdo nepojistí.
    E2E4
    E2E4 --- ---
    QWWERTY: jj, často je průšvih způsobeny neobvyklou kombinací věci, které jsou samy o sobě OK, i jsou OK jejich běžné kombinace..
    QWWERTY
    QWWERTY --- ---
    E2E4: " software je vždycky plný chyb" ... a musel by byt zazrak, aby jsi za vsechny ty chyby byl zodpovedny jenom ty
    coz te vraci zpatky k AMBIENTIUM: "nade vší pochybnost musí být prokázáno, že jediná odpovědná osoba za škodu jsi Ty a firma nebo kdokoliv další nemůže za nic"
    E2E4
    E2E4 --- ---
    DWICH: tak tady se bavíme spíš o odpovědnosti Švarc systém zaměstnance..

    a to prokazování zavinění škody je u software těžký, software je vždycky plný chyb, nevím jak velká už je odpovědnost zakládající nedbalost..
    DWICH
    DWICH --- ---
    Ještě bych doplnil, že v případě chyby nebo problému jsou dvě možnosti, jaké klient může chtít uplatnit: smluvní pokuta nebo vzniklá škoda.

    Smluvní pokuta je past. Škoda může být tisícovka nebo klidně nulová, smluvní pokuta může být nastavena na 10 tis. Na smluvní pokutu nepřistupovat. Těch důvodů je víc.

    Vzniklou škodu je potřeba definovat jako reálně vzniklou a prokázanou škodu. Tzn. když ji klient chce uplatnit, musí ji opravdu prokázat nějakým věrohodným způsobem. Což je právě ta výhoda oproti pokutě. Leckdy právě ta potřeba reálného vyčíslení klienta může odradit to řešit, podobně jako dodavatel leckdky promíjí klientovi jeho pozdní dodání podkladů a jiný "prohřešky" vůči podepsaný smlouvě.

    Třetí věc je - nepřistupovat na pokutu a vzniklou škodu zároveň. Vysvětlit, že budete ručit za reálně vzniklou škodu, což by jakýkoliv pracovník měl, ať v IT nebo zedník. Na profesi nesejde. Všichni bychom měli odpovídat za svoje chyby. A opravdu se na to pojistit. Ty výše pojistek jsou dneska zanedbatelný vzhledem k výši příjmů.

    No a poslední bod - limitace škody. I když je to právně složitější, je dobrý klienta připravit na to a mít to smluvně ošetřené, že ručíte do výše škody XY podle vašeho pojištění. Nedostanete se tak do situace, že děláte můstek mezi dvěma bankama, kde výpadek na hodinu může být škoda za miliardu, kdežto za tu práci dostanete 20 tisíc. I když ta škoda může být astronomická, vy můžete ručit do např. 10 % z ceny díla. Jinak by se nevyplatilo dělat takhle rizikovou věc za 20 tisíc a pak rovnou odevzdat celou odměnu při výpadku na jednu minutu.

    Jestli klient chce astronomické záruky, měla by tomu odpovídat i cena za zhotovení a případně i pojištění. Kde může být argument - naše standardní pojištění je do výše 20 miliónů. Pro tento projekt se můžeme pojistit až na dvě miliardy, ale ty náklady z principu promítneme do ceny. Nebo se můžete pojistit jako klient vy. Je to věcí jednání.
    DELVIT
    DELVIT --- ---
    AMBIENTIUM: Pěkně sepsané, díky.

    Metody předcházející škodě jsou jasné, ale nikdy nevíš co vše se může zvrnout a je dobré o tomhle vědět předtím, než pak něco hasit narychlo. s.r.o. mě napadlo, že to by mohlo být zajímavý způsob na omezení škod.
    AMBIENTIUM
    AMBIENTIUM --- ---
    DELVIT: samozřejmě by se člověk neměl ani přiblížit k něčemu, čemu nerozumí a kde může napáchat škody. Tzn. pokud máš přístup na produkční databázi a jsi schopen tam poslat zlej update, pak bys sám měl mít svoje metody práce, které škodě předejdou; ale nechci poučovat, to je asi všechno jasné.

    Když už se to ale stane a je to opravdu obří průser; obří znamená, že škoda odpovídá např. vysokýmu procentu ročních tržeb firmy, tak i s případným pojištěním v zádech je nutné jednat s předběžnou sebe-opatrností (je potřeba to brát tak, jako bych už dostal padáka). Moje zkušenost je taková, že největší průser, jehož jsem byl svědkem, byl oceněn na 3 mil. CZK a skutečně ta škoda byla přesně taková a jasně prokazatelná. Tato částka firmě nestála za to, něco řešit. Byl z toho hezkej zápis do fail logu.

    Co dělat:
    - asap sehnat právníka,
    - nic nepřiznávat, nepodepisovat,
    - aby někdo po Tobě mohl požadovat náhradu škody, musí být prokázáno, že skutečně došlo ke škodě a škoda musí být vyčíslena tak, aby to obstálo u soudu (což se nerovná tomu, že majitel firmy vezme denní tržby a vynásobí je dvěma a přičte k tomu recovery costs, například.)
    - nade vší pochybnost musí být prokázáno, že jediná odpovědná osoba za škodu jsi Ty a firma nebo kdokoliv další nemůže za nic (špatné nastavení pravidel bezpečnosti je odpovědnost firmy atd.).
    - to, že je někde v nějakém elektronickém logu vidět Tvoje identita nemusí znamenat z právního hlediska nic moc.
    - atd. atd. Je tam mnoho možností jak vést právní obranu.

    Výše uvedené ale platí hlavně OSVČ. Zaměstnanci mají škody limitované na myslím max čtyřnásobek průměrné hrubé mzdy.

    A úplně nejlepší metoda je z tohoto hlediska nebýt OSVČ ale s.r.o. kde je "ručení omezené", ale i toto probrat s právníkem. Nejlepší obrana je totiž předběžná. Skončit v osobním bankrotu nikdo nechceme.
    Kliknutím sem můžete změnit nastavení reklam