Jak byla ve vašem týmu organizována procedura revize kódu?

Použili jsme společný vývoj pomocí systému správy verzí Git a platforem pro správu úložišť (například Bitbucket nebo GitLab). Proces kontroly kódu byl organizován následovně:

1. Vytvoření větve: Vývojář vytvoří samostatnou větev pro novou funkci nebo opravu chyby (git checkout -b feature/my-new-feature).
2. Vývoj a commity: Do větve jsou prováděny změny, které jsou zaznamenány commity (git add ., git commit -m "Počáteční implementace funkce").
3. Push do vzdáleného repozitáře: Větev je odeslána do vzdáleného repozitáře (git push origin feature/my-new-feature).
4. Vytvoření Pull/Merge Request: Vývojář vytvoří Pull Request (na Bitbucketu) nebo Merge Request (na GitLabu), uvádí cílovou větev (například develop nebo main). V popisu je uveden stručný přehled změn, odkazy na úkoly v trackeru (Jira, Trello atd.) a připojené soubory (snímky obrazovky, videa, diagramy).
5. Přiřazení reviewerů: Jeden nebo dva vývojáři z týmu jsou přiřazeni k provedení revize.
6. Proces revize: Revieweři prohlížejí změny v Pull/Merge Request. Mohou zanechat komentáře, navrhnout vylepšení, klást otázky.

   // Příklad komentáře během revize
   function fetchData() {
     // Možná je třeba přidat zpracování chyb
     return fetch('/api/data');
   }
   

7. Zavedení změn na základě revize: Vývojář provede potřebné změny na základě komentářů reviewerů a vytvoří nové commity.
8. Aktualizace Pull/Merge Request: Změny se automaticky zobrazí v Pull/Merge Request po pushi do vzdáleného repozitáře.
9. Opakovaná revize: Revieweři znovu prohlédnou změny a schválí je.
10. Sloučení větve: Po získání schválení je větev sloučena s cílovou větví (obvykle automaticky platformou po úspěšném průchodu CI/CD pipeline).

Také jsme používali CI/CD pipeline, které automaticky spouští jednotkové testy, statickou analýzu kódu (ESLint, Prettier) a sestavení projektu před sloučením, což pomáhalo odhalit chyby v raných fázích.

Kritéria úspěšného review zahrnovala:

• Shodu s požadavky úkolu.
• Dodržování stylu kódu týmu.
• Přítomnost jednotkových testů pro kritickou logiku.
• Absenci zjevných chyb a "workarounds".
• Srozumitelnost kódu pro ostatní členy týmu.