Код-ревью: как не тормозить, а ускорять поставку продукта. Часть - 2. 4. Делайте саморевью перед открытием PR Одна из самых недооценённых практик – саморевью. Ты открыл PR – и сразу же пробежался глазами по изменениям: - глянул, нет ли мусорного кода, отладочных принтов, забытых комментариев; - проверил названия переменных и функций – всё ли читаемо; - оценил, насколько логично читается код тем, кто в него не погружён. Эту проверку можно делать самостоятельно, а можно – с помощью нейрух. Пусть нейросеть скажет, что по ее мнению не ок. Это занимает 10 минут, но экономит часы на ревью. Чем чище вход, тем меньше возни в процессе и на выходе. 5. Держите фокус на поставке В момент, когда вы правите замечания, обсуждаете правки, дорабатываете PR – не распыляйтесь. Не переключайтесь на другие задачи. Не лезьте в другую фичу. Почему это важно? Потому что: - вы теряете контекст – и возвращаетесь в PR с отвлеченной головой; - ревьюеры тратят время на повторные проверки, когда PR снова плывёт; Сфокусируйтесь: правки, обсуждение, доработка, выкладка на тест. Это ускорит T2M и высвободит команду от лишних итераций. 6. Проверьте свой код сами, прежде чем отдавать дальше Не отправляйте код в тестирование или дальше по процессу, если сами не уверены, что он работает. Это базовая гигиена. Что стоит сделать: - руками проверить сценарий; - дёрнуть ручку, если пишете API; - убедиться, что фича действительно делает то, что должна. Это покажет уважение к коллегам, сэкономит время тестировщикам и избавит от возвратов “с полпути”. Лучше 10 минут сейчас, чем день простоя потом. Это список принципов и практик, которым я сам стараюсь следовать в повседневной работе. А вот о том, как эффективно проводить само ревью, смотреть чужой код и давать конструктивный фидбэк – расскажу в следующий раз.