Poslední příspěvky

1

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od Zopper kdy Dnes v 11:35:52 »

Muzes mit automatizovane testy, ktere ti otestuji jestli mas testy a jestli ty testy testuji co maji testovat viz napr. mutation a coverage testing.

To co popisujes ty znaci, ze nemas dostatecnou duveru v pipelinu.

Pokud je to na produkci a funguje to tak je to v poradku a muze to tam byt.. .proc bych travil cas na code review kterym budu blokovat merge?

Review ale nemá primárně chytat nějaké testovatelné bugy, jak už tu zaznělo několikrát. Review potřebuješ dělat i u 100% covered codebase, protože jen neuronka (ať už biologická, nebo umělá) může posoudit, jestli jsou věci smysluplně pojmenované, rozdělené, jestli je to udržitelně napsané, jestli ty testy jsou napsané tak, aby reálně detekovaly chyby a přitom nezávislé změny nevyžadovaly hromadu oprav testů...

Jasně, mutation a fuzzy testing je v principu super, ale pokud i bez nich plný test suite běží hodiny a hodiny, tak plošná mutabilita to násobí, takže se to dá používat jen cíleně.

Pokud je to hnusno-kod kterej tam nechci i kdyz funguje tak ho proste oznacim jak technical friction ktery je potreba resit a udelam ta to ticket do pristiho sprintu... S nikym nemusim diskutovat jestli se to udela nebo ne... projektova kultura proste rika, ze tohle se bude resit... A navic muzu pridat automatizovanej test na to aby uz se to priste nestalo...

Pokud není čas na "udělat to pěkně už na prvním MR", tak stoprocentně nebude čas na přepsání později, kdy to začnou používat další věci. Tyhle tickety se přištích pár měsíců přesouvají ze sprintu do sprintu, pak se to přesune na plán na příští rok a pak se zavřou jako "not relevant after 5 years".

Casem se muze stat ze ta pipelina sama bezi moc dlouho tak se musi resit ktere veci se budou kontrolovat s kazdym MR a ktere veci pobezi prez noc...

Ano. To má být jako nějak špatně, nebo co?

#MoveFastAndBreakThings

Jo, při rozhlédnutí se je vidět, kolik lidí a firem za tuhle myšlenku schovává nekvalitní práci a věčně akumulující se technický dluh.

2

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od listoper kdy Dnes v 11:07:33 »

Delate code review pred merge nebo az po nem?
1. Vede to na to, ze lidem se nechce a zacnou delat formalni approvaly.. nebo approvujou podle toho od koho je MR...
...

Uáááá! Pokud to mergneš před review, tak všechny ty body, co vypisuješ, jsou úplně nic proti "však to už je na produkci a funguje, tak proč bych na tom review trávil půl dne." Review je buď požadavek na merge, nebo nemá smysl.

A pak to "ex post" code review muze naopak mit velky prinos.. udela se jednou za cas meeting kde se posedi a dohromady se probere co jde spravnym smerem a co jsou veci ktery by se radsi meli opravit... a vysvetli se proc a treba se to muze zdokumentovat pokud jsou v guidelines nejaky diry...

To není code review, to je možná tak architecture review, long term planning, nebo něco takového. Code review má chytit problémy (a problém není vždy jen bug zachytitelný testem) PŘED tím, než se ten kód oživí na produkčním prostředí. Ostatně, jak bez code review víš, že ta nová funkcionalita vůbec má nějaké testy a ty testy reálně něco dělají? Pak už je na to pozdě. Prevence lepší lékaře a tak.

Doporucuju nastudovat neco o continuous delivery.

Muzes mit automatizovane testy, ktere ti otestuji jestli mas testy a jestli ty testy testuji co maji testovat viz napr. mutation a coverage testing.

To co popisujes ty znaci, ze nemas dostatecnou duveru v pipelinu.

Pokud je to na produkci a funguje to tak je to v poradku a muze to tam byt.. .proc bych travil cas na code review kterym budu blokovat merge?

Pokud je to hnusno-kod kterej tam nechci i kdyz funguje tak ho proste oznacim jak technical friction ktery je potreba resit a udelam ta to ticket do pristiho sprintu... S nikym nemusim diskutovat jestli se to udela nebo ne... projektova kultura proste rika, ze tohle se bude resit... A navic muzu pridat automatizovanej test na to aby uz se to priste nestalo...

Casem se muze stat ze ta pipelina sama bezi moc dlouho tak se musi resit ktere veci se budou kontrolovat s kazdym MR a ktere veci pobezi prez noc...

Ale jak sem uz psal... plati to jen pro veci ktere muzu takhle delat a pokud mam projektovou kulturu pripravenou na takovy proces...

#MoveFastAndBreakThings

3

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od L.. kdy Dnes v 10:49:12 »

3. Vede to na to, ze se tolik netestuje a automatizace je na druhe koleji...

Tenhle bod hlavně, ale i celý příspěvek je psaný z pohledu jako kdyby code reviews byly nějaká náhrada testů. To je za mě naprosto chybný pohled, code reviews mohou nějaký bug sem tam zachytit, ale primárně jsou zaměřené na úplně jiné věci. Na to, jak smysluplné automatické testy jsou, jak moc pochopitelný je kód, jestli jsou proměnné a funkce dobře pojmenované, high-level věci, různé pasti... My třeba máme kód, co běží v mnoha různých deploymentech a chová se na nich různě, což se přepíná feature flagy. Nedávno jsem jednomu juniorovi vrátil kód, kde testoval, zda je na konkrétním deploymentu podle jeho jména místo co by zavedl feature flag. Testy by procházely, ale code review tohle nesmí projít.

4. hrozne to zpomaluje flow... (mam treba rozdelany 3 pull requesty zaroven a tlacim je prez code review 3 dny nez si lidi udelaji cas na review zapracuju pozadovany zmeny apod.. )

To záleží na týmové kultuře a je to práce team leada, aby se pull requesty na code review zbytečně nesekaly, stejně jako aby si v nich programátoři nepoměřovali pindíky a nehádali se o blbostech.

Mimochodem, AI je na code review celkem užitečná - konkrétně hezky zachytí například když člověk zkopíruje kód, ale zapomene upravit komentář. Ale je dobré jako doplněk - občas reportuje nesmysly a samozřejmě dost z věcí co jsem psal výš že code review má kontrolovat neodchytí.

4

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od M3phistoCZE kdy Dnes v 09:13:53 »

Řekl bych, že aplikuji několik "strategií" code-review na základě pár informací, které zjistím rychle

- Kdo je autorem - na základě toho už přibližně vím, co mě čeká a jakou kvalitu můžu očekávat.
- Čeho se změny týkají - zasahuje to do mého modulu, do společných věcí, do modulu jiného týmu, ...
- Testy - má to vůbec nějaké? Jsou test-casy srozumitelné? Je zvolen správný typ testu? ...
- git historie - když tam např vidím 10 commitů s message "fix" pár minut po sobě, jsem ostražitější

Tyhle věci co mi zaberou maximálně pár minut rozhodnou o tom jak zevrubně dělám review. U kódu který se týká mého modulu a společných věcí buď schvaluji nebo žádám změny, u cizího modulu - pokud to vyloženě není odpad - změny nežádám (blokuje merge) a nechávám rozhodnout jiné vývojáře

5

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od Zopper kdy Dnes v 09:02:57 »

Jak se firma rozrůstala, tak se přidalo code review, ale commitovalo se pořád rovnou do masteru. Výsledek: junioři se toho báli a stejně si věci dělali ve větvi a nechávali schválit před mergem, master byl věčně rozbitej (padaly testy nebo vůbec nešel zkompilovat)

Jinak řečeno, sice byly testy, ale lokálně neužitečné, protože sis je stejně nemohl pustit, dokud někdo jiný neopravil svou kupku hnoje.

My máme mergnutí do masteru/release větví podmíněné nejen review, ale i zelenou CI a approval od statické analýzy, která mimo jiné například hlídá zakázané patterny, použití ne-cryptograficky-bezpečných funkcí , nebo detekuje nové použití označených deprecated tříd a v tu chvíli vyžaduje na review approval od teamu, co vlastní tu deprecated třídu. Výsledek je ten, že k rozbití masteru prakticky nedochází (vždycky se můžou sejít dvě navzájem nekompatibilní změny dřív, než vyprší životnost CI buildu, ale to je výjimka). Ale taky je fakt, že nejsme startup a máme týmy lidí na věci, které ve startupu dělá jeden člověk, když mu zbyde prostor v pátek odpoledne.

6

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od snugar_i kdy Dnes v 08:12:25 »

Jeste je zajimave se na to podivat z jineho pohledu.
Delate code review pred merge nebo az po nem?

Když jsem kdysi pracoval ve startupu, tak tam nebylo vůbec žádný code review a commitovalo se rovnou do masteru. Jak se firma rozrůstala, tak se přidalo code review, ale commitovalo se pořád rovnou do masteru. Výsledek: junioři se toho báli a stejně si věci dělali ve větvi a nechávali schválit před mergem, master byl věčně rozbitej (padaly testy nebo vůbec nešel zkompilovat), často nešlo nasadit do produkce, protože to nepustily sanity checky (který jsme naštěstí měli celkem robustní). Pro mě jako seniornějšího člověka to ale bylo pohodlný, protože jsem nemusel řešit problémy typu "dělám na věci X, ale potřebuju použít něco, co jsem udělal na věci Y, která ještě není zamergovaná".

Jinak k původní otázce: Jdu commit po commitu a čtu poctivě všechno. Kontroluju hlavně čitelnost a best practices. Jestli kód dělá to, co má, ověřujou testy (který ale taky kontroluju důkladně).

7

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od Zopper kdy Dnes v 08:04:41 »

Delate code review pred merge nebo az po nem?
1. Vede to na to, ze lidem se nechce a zacnou delat formalni approvaly.. nebo approvujou podle toho od koho je MR...
...

Uáááá! Pokud to mergneš před review, tak všechny ty body, co vypisuješ, jsou úplně nic proti "však to už je na produkci a funguje, tak proč bych na tom review trávil půl dne." Review je buď požadavek na merge, nebo nemá smysl.

A pak to "ex post" code review muze naopak mit velky prinos.. udela se jednou za cas meeting kde se posedi a dohromady se probere co jde spravnym smerem a co jsou veci ktery by se radsi meli opravit... a vysvetli se proc a treba se to muze zdokumentovat pokud jsou v guidelines nejaky diry...

To není code review, to je možná tak architecture review, long term planning, nebo něco takového. Code review má chytit problémy (a problém není vždy jen bug zachytitelný testem) PŘED tím, než se ten kód oživí na produkčním prostředí. Ostatně, jak bez code review víš, že ta nová funkcionalita vůbec má nějaké testy a ty testy reálně něco dělají? Pak už je na to pozdě. Prevence lepší lékaře a tak.

8

Vývoj / Re:Jak děláte code review?

« Poslední příspěvek od listoper kdy Dnes v 08:04:01 »

Ale funguje... jen zalezi na tymove kulture.

9

Windows a jiné systémy / Re:Samovolné restarty Windows 11 v KVM

« Poslední příspěvek od David kdy Dnes v 04:26:31 »

Začal bych tím, že tam budu mít verzi IoT LTSC, kde se dá leccos nastavit.

10

Bazar / Re:Sháním notebook s Windows 98

« Poslední příspěvek od _Jenda kdy Dnes v 03:25:37 »

HW s w98 se bude hledat hodne tezko.

Zrovna nedávno nějaká příbuzná odněkud vytáhla funkční notebook s Windows ME a ptala se co s tím. Prodali jsme to nějakému retro gaming nadšenci přes sbazar. Takže jak píše RDa. Nebo samozřejmě pokud je to jen trochu možné tak virtualizace.