Должен же тимлид смотреть Merge Request (Pull Request)?
Если задать такой вопрос, то большинство людей ответят утвердительно, поскольку это кажется максимально очевидной обязанностью любого тимлида, чтобы:
контролировать качество кода программистов команды;
следить за соблюдением принятых стандартов;
управлять рисками кодовой базы команды;
обучать участников команды через ревью их кода;
держать руку на пульсе того, чем занимаются участники команды.
Однако что делать, если у вас кросс-функциональная команда, состоящая из двух бэкендеров, пары фронтендов, QA и аналитика? Нужно ли вам просматривать все их MR? Сможете ли вы адекватно оценить код на PHP, код на React + TypeScript и автотесты на Python? Очевидно, что нет.
Для разрешения данной ситуации вы можете:
Забить на код-ревью систем, которые не считаете критическими для успеха проекта. Возможно, никто не расстроится, если автотестер будет писать код так, как посчитает нужным.
Попросить разработчиков проводить код-ревью друг у друга. Однако всё довольно быстро превратится в формальные проверки, когда одобрения ставятся просто ради галочки.
Попросить самого опытного разработчика функциональной команды (например, техлида всех фронтендов) просматривать ревью вашего фронта, чтобы всё было хорошо. Но это быстро превращается в узкое место, когда ваши MR ждут ревью неделями, замедляя все релизы.
Как поступить?
Предварительное согласование решений. Мало кому нравится читать чужой код, но многие любят обсуждать правильные подходы. Если члену команды предстоит сложная задача, попросите его описать своё решение и предложите остальным её обсудить. Это станет одновременно и публичной документацией, и предварительным ревью выбранного подхода.
Максимально возможное покрытие фитнес-функциями (автоматические форматтеры, автотестеры, анализаторы кода). Согласуйте с техлидами внедрение в проект автоматических анализаторов и добавьте их в пайплайны репозитория. Ни один MR не пойдёт на ревью до тех пор, пока не будет соответствовать установленным стандартам. Так вы сэкономите массу времени.
Автоматическое распределение код-ревью среди всех участников функции (все фронтенды, все бэкенды), вне зависимости от проекта, с фиксацией лица, поставившего одобрение. Автоматически напомните человеку, что он превысил установленные компанией сроки на проведение ревью.
То есть программисты из других команд могут не разбираться в вашем домене, но они способны проверить, что код не делает ничего лишнего и корректно функционирует в рамках проекта (при нагрузке, сущностях, подходах). А факт рандомности ревьювера и фиксации апрува, не позволит им проводить ревью формально.
Приемочные тесты и регрессионное тестирование при релизах. QA-специалисты проверяют задачи на готовность и удостоверяются, что решение соответствует требованиям, а при выпуске на продакшн проводится автоматизированное тестирование, чтобы убедиться, что система нормально справляется с последним добавлением функционала.
В итоге, если тимлид вместе с техническими лидерами выстроит жёсткую систему доставки инкремента на продакшн, ему самому не обязательно просматривать каждый MR своей команды. Исключение составляют лишь те случаи, когда «душа просит».
P.s. Рекомендую: Эволюционная архитектура - автоматизированное управление программным обеспечением - Нил Форд`
