Как беше организирана процедурата по преглед на кода…

Използвахме съвместна разработка с помощта на системата за контрол на версиите Git и платформи за управление на репозитории (например, Bitbucket или GitLab). Процесът на преглед на кода беше организиран по следния начин:

Създаване на клон: Разработчикът създава отделен клон за нова функция или корекция на грешка (git checkout -b feature/my-new-feature).
Разработка и комити: В клона се правят промени, които се записват чрез комити (git add ., git commit -m "Първоначална реализация на функцията").
Push към отдалечения репозиторий: Клонът се изпраща към отдалечения репозиторий (git push origin feature/my-new-feature).
Създаване на Pull/Merge Request: Разработчикът създава Pull Request (в Bitbucket) или Merge Request (в GitLab), като посочва целевия клон (например, develop или main). В описанието се включва кратко описание на промените, връзки към задачите в тракера (Jira, Trello и др.) и прикачени файлове (екранни снимки, видеа, диаграми).
Назначаване на ревюъри: Назначават се един или двама разработчици от екипа за извършване на ревюто.
Процес на ревю: Ревюърите преглеждат промените в Pull/Merge Request. Те могат да оставят коментари, да предлагат подобрения, да задават въпроси.
```
// Пример за коментар по време на ревю
function fetchData() {
  // Може би трябва да се добави обработка на грешки тук
  return fetch('/api/data');
}
```
Внасяне на промени след ревю: Разработчикът прави необходимите промени въз основа на коментарите на ревюърите и създава нови комити.
Актуализиране на Pull/Merge Request: Промените автоматично се показват в Pull/Merge Request след push към отдалечения репозиторий.
Повторно ревю: Ревюърите преглеждат отново промените и дават одобрение.
Обединяване на клона: След получаване на одобрение, клонът се слива с целевия клон (обикновено автоматично от платформата след преминаване през CI/CD pipeline).

Използвахме също CI/CD pipelines за автоматично изпълнение на единични тестове, статичен анализ на кода (ESLint, Prettier) и изграждане на проекта преди сливането, което помагаше за ранно откриване на грешки.

Критериите за успешен преглед включваха:

Спазване на изискванията на задачата.
Спазване на стиловете на кода на екипа.
Наличие на единични тестове за критична логика.
Липса на очевидни грешки и "костилки".
Яснота на кода за останалите членове на екипа.

Как беше организирана процедурата по преглед на кода във вашия екип?