Hogyan szervezték meg a kód-áttekintési folyamatot a csapatukban?

A verziókezelő rendszer Git és tárolókezelő platformok (például Bitbucket vagy GitLab) segítségével közös fejlesztést alkalmaztunk. A kódellenőrzési folyamat a következőképpen szerveződött:

1. Ág létrehozása: A fejlesztő külön ágat hoz létre egy új funkció vagy hibajavítás számára (git checkout -b feature/my-new-feature).
2. Fejlesztés és commitok: A változtatásokat az ágon végzik, amelyeket commitokkal rögzítenek (git add ., git commit -m "Első funkció megvalósítása").
3. Push a távoli tárhelyre: Az ág a távoli tárhelyre kerül (git push origin feature/my-new-feature).
4. Pull/Merge Request létrehozása: A fejlesztő létrehoz egy Pull Request-et (Bitbucket-en) vagy Merge Request-et (GitLab-en), megadva a célágat (például develop vagy main). A leírásban röviden összefoglalják a változtatásokat, hivatkozásokat a feladatokra a trackerben (Jira, Trello stb.), valamint csatolt fájlokat (képernyőképek, videók, diagramok).
5. Átnézők kijelölése: Egy vagy két fejlesztő kijelölése az ellenőrzéshez.
6. Áttekintési folyamat: Az áttekintők megvizsgálják a Pull/Merge Request-ben lévő változtatásokat. Hagyhatnak megjegyzéseket, javasolhatnak fejlesztéseket, kérdéseket tehetnek fel.

   // Példa megjegyzésre az áttekintés során
   function fetchData() {
     // Itt érdemes lehet hibakezelést hozzáadni
     return fetch('/api/data');
   }
   

7. Változtatások a review eredményeként: A fejlesztő elvégzi a szükséges módosításokat a megjegyzések alapján, és új commitokat készít.
8. Pull/Merge Request frissítése: A változtatások automatikusan megjelennek a Pull/Merge Request-ben, miután push-olták a távoli tárhelyre.
9. Ismételt áttekintés: Az áttekintők újra megvizsgálják a változtatásokat, és jóváhagyják azokat.
10. Ág összevonása: Jóváhagyás után az ág összevonásra kerül a célággal (általában automatikusan a platform által, a CI/CD pipeline sikeres lefutása után).

Emellett CI/CD pipeline-okat is használtunk, amelyek automatikusan futtatják az egységteszteket, a statikus kód-analízist (ESLint, Prettier), valamint a projekt buildelését az összevonás előtt, így korai szakaszban észlelve a hibákat.

A sikeres review kritériumai közé tartozott:

• A feladat követelményeinek való megfelelés.
• A csapat kódstílusának betartása.
• Kritikus logikához tartozó egységtesztek megléte.
• Nyilvánvaló hibák és "kötőelemek" hiánya.
• A kód érthetősége a többi csapattag számára.