Ответ
Как тимлид, я рассматриваю код-ревью не только как поиск багов, но и как ключевой процесс для поддержания качества кода, обучения команды и распространения знаний.
Основные фокус-области:
-
Корректность и архитектура:
- Логика соответствует задаче и edge cases.
- Соответствие архитектурным принципам проекта (слои, границы контекстов).
- Отсутствие скрытых побочных эффектов.
-
Читаемость и поддерживаемость:
- Понятные имена переменных, методов, классов.
- Простота против излишней умности (KISS).
- Соблюдение Code Style команды.
- Качество комментариев (объясняют "почему", а не "что").
-
Безопасность и производительность:
- Проверка на уязвимости (SQL-инъекции, XSS).
- Неоптимальные запросы к БД (N+1), проблемы с памятью.
-
Тестируемость:
- Код покрыт юнит-тестами.
- Отсутствие жестких зависимостей, которые мешают тестированию.
Процесс и принципы:
- "Ревьюируй быстро": Стараюсь дать фидбек в течение нескольких часов.
- Конструктивный тон: Задаю вопросы ("Как ты думаешь, что произойдет, если...?"), а не выношу приговоры.
- Автоматизация: Настаиваю на использовании статических анализаторов (SonarQube), линтеров и форматтеров, чтобы не тратить время ревью на пробелы.
- Обучение: Использую ревью, чтобы указать на лучшие практики или альтернативные подходы, делюсь ссылками на документацию.
- Баланс: Не требую идеального кода с первой попытки, но строго спрашиваю за критические недостатки.
Цель — не только улучшить конкретный PR, но и постепенно поднять общий уровень кода и экспертизы в команде.
Ответ 18+ 🔞
Да ты послушай, что эти тимлиды выдумывают! Сидят, блядь, и думают, как бы нам всем жизнь усложнить под соусом "заботы о качестве". Ну ладно, слушай сюда, раз уж спросил.
Вот смотри, я этот ваш код-ревью воспринимаю не как охоту на ведьм, где надо найти, кого бы завалить за лишний пробел. Нет, блядь. Это ж, ёпта, целый многоходовый движ! Три в одном: баги вылавливаем, качество кода поддерживаем, и заодно всю команду учим, чтобы не писали хуйню.
На что я, сука, смотрю в первую очередь, когда мне пулл-реквест подсовывают:
-
Чтобы всё работало и не развалилось. Это же основа, мать его! Логика должна соответствовать задаче, а не делать вид. И чтобы на всех этих краевых случаях — пустые списки, нуллы, дикие вводы — не накрылось всё медным тазом. Архитектуру тоже смотрю: если у нас модули по слоям разделены, а ты тут, хитрая жопа, из контроллера напрямую в репозиторий лезешь — это пиздец, а не архитектура.
-
Чтобы можно было это прочитать, не сломав глаза. Имена переменных — не
a1,tmpилиdata2, а что-то человеческое. Код должен быть простым, а не гениально-запутанным, чтобы потом только ты один, полупидор, мог в нём разобраться. Стиль кода — соблюдаем, блядь! И комментарии... О, комментарии! Если ты пишешь// увеличиваем счетчик на 1, то иди нахуй. А если пишешь// увеличиваем из-за костыля в API гугла, иначе падает, вот это — золото. -
Чтобы не взломали и не легло всё. Смотрю, нет ли дыр, куда можно SQL-инъекцию воткнуть или скрипт злой вставить. И на перформанс: если ты в цикле на каждую итерацию новый запрос в базу гоняешь (этот твой любимый N+1), я тебя, бздуна, нахуй пошлю переделывать. Память тоже не резиновая.
-
Чтобы это можно было проверить. Где тесты, Билли? Если твой код — чёрный ящик, который только божественным проведением работает, то доверия к нему — ноль ебать. И зависимости должны быть такие, чтобы моки воткнуть можно было, а не одна сплошная жесткая сцепка.
А как я это, сука, провожу?
- Тянуть не буду. Понял — сделал. Стараюсь фидбек дать быстро, чтобы ты не забыл, о чём вообще код писал.
- Не буду орать "ты — мудак". Лучше спрошу: "Слушай, а что будет, если сюда
nullприлетит?" или "А не думал ты использовать вот этот паттерн?". Конструктив, блядь, а не унижение. - Всё, что можно автоматизировать — автоматизируем. Чтоб я, блядь, из-за отступов или точки с запятой время тратил? Линтер и форматтер сами всё поправят. У нас SonarQube есть — пусть он рутинную хуйню ищет.
- Учу, блядь. Если вижу, что человек не в курсе лучшей практики, не ору, а скину ссылку на доки или пример. Распространяем знания, ебать!
- Баланс. Я не буду придираться к каждой мелочи в первом же PR джуна. Но если ты, опытный, накосячил в чём-то фундаментальном — тут уж извини, пиздец тебе, а не ревью.
А цель-то у меня какая, думаешь? Не просто этот кусок кода подправить. А чтобы через полгода вся команда писала код так, что его и читать приятно, и расширять легко, и багов в нём — овердохуища меньше. Поднимаем общий уровень, ебать мои старые костыли! Чтобы не я один всё видел, а чтобы у всех глаза открылись. Вот и вся философия.