Многие думают, что code review — это когда сеньор проверяет джуна, чтобы найти ошибки. На самом деле всё гораздо глубже. Главная цель — не поймать опечатку, а обеспечить качество и обмен знаниями. Бывает, что смотрят только на форматирование и ставят LGTM («Looks Good To Me»). Это не работает. Такой подход не спасает от реальных проблем и только отнимает время. В MIC мы подходим к этому серьёзно. Это наш способ делать надёжные продукты и растить сильную команду. Хороший код — это не тот, что просто работает. Это тот, который понятен и надёжен.
Многие думают, что code review — это когда сеньор проверяет джуна, чтобы найти ошибки. На самом деле всё гораздо глубже.
Это не про «поиск багов»
Главная цель — не поймать опечатку, а обеспечить качество и обмен знаниями.
- Контроль качества. Мы проверяем не только работает/не работает, но и архитектуру: не делаем ли мы костыли, которые потом всё сломают? Читаем ли код другие люди? Насколько он устойчив к будущим изменениям?
- Передача знаний. Это лучший способ учиться. Джун видит, как думают сеньоры. Сеньор может узнать о новой библиотеке от мидла. Вся команда растёт вместе.
Что именно проверяем?
- Архитектура: решение вписывается в общую систему?
- Читаемость: через месяц ты сам поймёшь, что тут написано?
- Устойчивость: что будет, если данные будут кривыми или сервис упадёт?
Анти-паттерн: review ради галочки
Бывает, что смотрят только на форматирование и ставят LGTM («Looks Good To Me»). Это не работает. Такой подход не спасает от реальных проблем и только отнимает время.
В MIC мы подходим к этому серьёзно. Это наш способ делать надёжные продукты и растить сильную команду.
Хороший код — это не тот, что просто работает. Это тот, который понятен и надёжен.