Код-ревью иногда бывает утомительным процессом, но я считаю, что нам нужно уделять этому больше времени. Может быть, это возможность для вас узнать что-то новое или поделиться некоторыми знаниями.
В этой статье я перечислил некоторые моменты, которые считаю необходимо проверять в code review в Android-проектах.
Утечки памяти
Представьте себе такой случай: красивое приложение, но в то же время медленное, навигация между экранами с каждым разом все больше и больше замедляется.
Некоторые моменты, которые необходимо проверить во время проверки кода:
- Есть ли удержание Context в новом фрагменте кода?
- Есть ли какой-либо код RxAndroid? Если да, проверьте, удаляются ли вызовы RxCall в конце жизненного цикла (ViewModel/Fragment/Activity).
- Если в коде есть корутины, проверьте, правильно ли высвобождается Job, запущенная из области ViewModel.
- Использует ли код CountDownTimer, AsyncTask или любой видео/аудиоплеер? Если да, код должен освобождать ресурс памяти для предотвращения утечки.
- Если используется новый Fragment с ViewBinding, код должен освободить биндинг в методе onDestroyView.
Глубокие макеты
Иногда у нас есть ViewGroup, у которого есть другая ViewGroup в качестве дочернего элемента.
Хорошим советом всегда будет использовать для ViewGroup ConstraintLayouts, чтобы макеты были более плоскими. Это может избежать перерисовки, которая вызывает проблемы с производительностью.
В документации по Android есть несколько советов по уменьшению перерисовки.
Аннотации ресурсов
Каждый ресурс в мире Android имеет идентификатор целочисленного типа. Как убедиться, что наше целочисленное значение представляет действительный идентификатор ресурса? Аннотации помогают нам в этом.
Например:
В приведенном выше коде рецензент мог бы предложить: «Что вы думаете об использовании аннотаций? Что-то вроде этого»:
Другие примеры аннотаций вы можете найти здесь.
Похожие компоненты
Очень важно уделять время проверке кода. Попробуйте думать так, как думал автор, делая свой выбор, задавайте вопросы, чтобы понять код.
Приходит новый код. Подождите: «Этот код делает то же самое, что и в этом компоненте». Подобные комментарии необходимы, потому что здорово повторно использовать то, что уже существует в нашей кодовой базе. Обращайте внимание, когда компоненты выглядят примерно так:
- Компонент X меняет цвет луны на красный 🔴;
- Компонент Z меняет цвет полной луны на синий 🔵;
- Компонент А превращает луну в зеленую 🍏.
Почему не компонент для изменения цвета любой луны? Он может получить цвет в качестве аргумента. Это слишком много работы?
Зоны опасного кода
Я предпочитаю вместо термина “чувствительный код” использовать выражение “опасная зона”, которое лучше описывает эту ситуацию. Опасный код — это код, на который проверяющий смотрит и дает реакцию вроде: «Этот код не имеет никакого смысла».
В этом случае не судите автора. Поговорите с ними, чтобы понять причину появления этого кода. Этот разговор может быть возможностью узнать что-то новое.
Нарушение архитектуры 📐
Архитектура программного обеспечения — это протокол связи, определенный между частями программного обеспечения.
Core Review — очень эффективный инструмент для выявления таких проблем, как нарушение архитектуры. Добавление подобных комментариев полезно в таких сценариях:
- «Друг, твоя ViewModel обращается к репозиториям. У нас есть UseCase между ними. Пожалуйста, взгляни на файл MainViewModel, это отличный пример».
- «Почему ты используешь ссылку на Adapter внутри твоей ViewModel? Адаптер — это компонент RecyclerView. Было бы лучше поместить это во Fragment и держать подальше от нашей ViewModel».
Маленькие детали имеют значение
- Неиспользованный импорт;
- Неиспользуемые ресурсы, такие как изображения, строки, цвета…;
- Закомментированный код;
- Неформатированный код;
- Имена переменных, имена методов, имена файлов…;
- Код не соответствует руководству по стилю. Например, Kotlin дает нам четкое руководство по стилю. Он помогает любому разработчику очень быстро найти любой программный компонент в существующей кодовой базе.
Заключение
Инструменты статического анализа полезны в процессе проверки кода, но они не эффективны на 100%. Критический обзор разработчика необходим, если ваша команда хочет получить качественный код.