Ответ
Я регулярно участвую в код-ревью как в качестве автора, так и ревьювера. Для меня это не просто формальность, а ключевой инструмент для поддержания качества кода и обмена знаниями в команде Flutter-разработчиков.
На что я обращаю внимание при ревью кода на Dart/Flutter:
-
Производительность и эффективность Flutter:
- Избегает ли код лишних перестроений (
build)? Используются лиconstконструкторы где возможно? - Правильно ли управляются подписки на
Stream'ы илиChangeNotifier'ы (отписка вdispose)? - Нет ли
print-отладочных операций в продакшн-коде?
- Избегает ли код лишних перестроений (
-
Архитектура и читаемость:
- Следует ли код выбранному паттерну (например, BLoC, Provider, Riverpod)? Логика отделена от UI?
- Названия переменных, методов и виджетов понятны и следуют Dart conventions (
lowerCamelCase,UpperCamelCase). - Сложная бизнес-логика прокомментирована.
-
Обработка ошибок и edge cases:
- Есть ли обработка ошибок сетевых запросов (через
try/catchили.onError)? - Учитываются ли состояния загрузки и пустых данных?
- Есть ли обработка ошибок сетевых запросов (через
Пример замечания из реального ревью:
Было (потенциальная проблема):
Widget build(BuildContext context) {
return FutureBuilder<String>(
future: _fetchData(), // Future создается при каждом build!
builder: (context, snapshot) { ... },
);
}Предложил исправить: Инициализировать Future в initState() или использовать FutureBuilder с ключом, либо, что лучше, вынести логику в Cubit/Bloc.
Я всегда стремлюсь давать конструктивную обратную связь, задавая вопросы ("Как ты думаешь, что произойдет, если...?") и предлагая конкретные альтернативы или ссылки на документацию.
Ответ 18+ 🔞
А, ну вот, опять про код-ревью. Давай, рассказывай, как мы тут друг другу мозги ебём за качество кода. Для меня это, бля, не какая-то хуйня для галочки, а реально важная штука, чтобы вся команда не превратилась в сборище распиздяев, которые пишут говнокод. Обменяться опытом, подтянуть джунов — дело святое.
Так, на что я, сука, смотрю, когда втыкаюсь в чужой Dart/Flutter:
-
Производительность, мать её:
- Этот код не дрочит лишние перестроения виджетов?
constконструкторы, ёпта, где они? Их же нада впендюрить везде, где можно, это ж не просто так придумали! - Подписки на стримы или нотифаеры — они закрываются в
disposeили будут висеть, как сопли, до скончания времён? Это же классика, доверия ебать ноль новичкам в этом вопросе. - И, бля,
print-ы, которые в проде будут спамить в консоль — ты чё, охренел? Удали эту дичь, ядрёна вошь!
- Этот код не дрочит лишние перестроения виджетов?
-
Архитектура и чтобы можно было прочитать:
- Мы вроде как договорились на BLoC/Provider/Riverpod — так следуй, бля, паттерну! Не мешай логику с UI в одну кучу, как говно в проруби. Отделяй, сука, одно от другого.
- Имена переменных — это пиздец просто.
a,b,temp— это ты для себя пишешь или для людей? Называй понятно, по конвенциям языка,lowerCamelCaseдля переменных,UpperCamelCaseдля классов. Э, бошка, думай! - Если написал какую-то хитрожопую логику, на которую сам через неделю будешь смотреть как баран на новые ворота — поясни её комментарием. Не заставляй меня гадать, чувак.
-
Ошибки и краевые случаи:
- Сетевой запрос упал — и что? Приложение крешнется, а пользователь увидит белый экран?
try/catch,.onError, состояния ошибки — это must have, а не опция. - Данные грузятся, данных нет — эти состояния тоже надо отрисовывать. Нельзя показывать пустой экран и делать вид, что всё окей.
- Сетевой запрос упал — и что? Приложение крешнется, а пользователь увидит белый экран?
Вот, смотри, реальный пример из жизни, как я одного коллегу поправил:
Было (потенциальная ёбаная проблема):
Widget build(BuildContext context) {
return FutureBuilder<String>(
future: _fetchData(), // Future создаётся при КАЖДОМ build, ёпта! Овердохуища перестроений!
builder: (context, snapshot) { ... },
);
}Я ему и говорю: Мужик, ты что, совсем? Этот Future будет запускаться каждый раз, когда виджет перестраивается, хоть от ветра. Инициализируй его в initState, либо используй FutureBuilder с ключом, а в идеале — вынеси всю эту логику в Cubit или Bloc, как взрослые дяди делают. Так и написал.
Я всегда стараюсь не просто тыкать пальцем и орать «фигня», а объяснять, почему так плохо и как сделать лучше. Спрашиваю: «А как думаешь, что будет, если тут прилетит null?». И кидаю ссылки на доки или хорошие статьи. Чтобы человек не просто исправил, а понял, и в следующий раз не наступил на те же грабли.
