Poslední příspěvky1
Vývoj / Re:Jak děláte code review?
« Poslední příspěvek od David Novák kdy Dnes v 18:15:49 »Jak si to tady čtu, chápu víc, proč je tolik SW (webového zejména) neustále ve více-méně rozbitém stavu 
Už se jen "těším", až všichni s těmito workflow přejdou na generování kódu pomocí LLM a různé výpadky a bezpečnostní incidenty důležitých služeb budou na denním pořádku.
Code review má být u každého seriózního projektu pořádný (tj. dle velikosti MR zabere hodiny až dny a dle kvality aspoň 10%, ale spíš 25% času samotného vývoje) a kontrola kvality ani není ten nejdůležitější důvod (byť je stále kritický).
To hlavní, čeho má review dosáhnout je sdílená znalost codebase - každý subsystém by měli chápat a znát alespoň dva lidé (malé týmy), ideálně víc. Proč? Kromě obligátního "co když nám původní vývojář odejde" také schopnost debuggování - aplikace se nějak špatně chová a vývojář, který zná codebase, bude spíš schopen odhadnout, kde by mohl být problém a tedy ho rychleji najde a vyřeší.
Další rozměr je také vzdělávání se a zejména juniorů - bez aktivní kritiky člověk jen těžko objeví své slabiny a nemůže na nich zapracovat. Pokud toto firma nebude dělat (nebo hůř, juniory vyhodí či nenajme a použije AI), přijde o budoucí seniory.
Kontrola kvality je ale samozřejmě také nepostradatelná - i kdyby měl tým perfektní sadu automatických testů včetně GUI testování (skoro nikdo nemá), stejně musíte při přidání/přepracování featury zajistit, že ji testy pokrývají. Tj. musíte problém samostatně analyzovat, zadefinovat si test cases a porovnat svůj výsledek s analýzou vývojáře, co změnu implementoval.
Zpomaluje to release featur? Ano (a je to dobře!). Je to často nevděčná práce? Rozhodně. Když ji ale nebudete dělat, dřív nebo později toho budete jistě litovat podobně jako u absence záloh
Samozřejmě pokud je to nějaký hobby projekt nebo něco, na čem vám moc nezáleží a za pár let to opustíte, tak je to jedno a můžete to třeba i vibe kódovat
Už se jen "těším", až všichni s těmito workflow přejdou na generování kódu pomocí LLM a různé výpadky a bezpečnostní incidenty důležitých služeb budou na denním pořádku.
Code review má být u každého seriózního projektu pořádný (tj. dle velikosti MR zabere hodiny až dny a dle kvality aspoň 10%, ale spíš 25% času samotného vývoje) a kontrola kvality ani není ten nejdůležitější důvod (byť je stále kritický).
To hlavní, čeho má review dosáhnout je sdílená znalost codebase - každý subsystém by měli chápat a znát alespoň dva lidé (malé týmy), ideálně víc. Proč? Kromě obligátního "co když nám původní vývojář odejde" také schopnost debuggování - aplikace se nějak špatně chová a vývojář, který zná codebase, bude spíš schopen odhadnout, kde by mohl být problém a tedy ho rychleji najde a vyřeší.
Další rozměr je také vzdělávání se a zejména juniorů - bez aktivní kritiky člověk jen těžko objeví své slabiny a nemůže na nich zapracovat. Pokud toto firma nebude dělat (nebo hůř, juniory vyhodí či nenajme a použije AI), přijde o budoucí seniory.
Kontrola kvality je ale samozřejmě také nepostradatelná - i kdyby měl tým perfektní sadu automatických testů včetně GUI testování (skoro nikdo nemá), stejně musíte při přidání/přepracování featury zajistit, že ji testy pokrývají. Tj. musíte problém samostatně analyzovat, zadefinovat si test cases a porovnat svůj výsledek s analýzou vývojáře, co změnu implementoval.
Zpomaluje to release featur? Ano (a je to dobře!). Je to často nevděčná práce? Rozhodně. Když ji ale nebudete dělat, dřív nebo později toho budete jistě litovat podobně jako u absence záloh
Samozřejmě pokud je to nějaký hobby projekt nebo něco, na čem vám moc nezáleží a za pár let to opustíte, tak je to jedno a můžete to třeba i vibe kódovat
