Проверка кода — иногда утомительный процесс, но я считаю, что нам нужно уделять этому больше времени. Возможно, для вас это возможность научиться или поделиться какими-то знаниями.
Я перечислил некоторые моменты, которые считаю необходимыми для проверки в процессе ревью кода в проектах Android.
Утечки памяти
Представьте себе следующий случай: приложение красивое, но в то же время медленное, навигация между экранами с каждым разом становится все медленнее.
Некоторые моменты, которые необходимо проверить во время проверки кода:
- Есть ли какие-либо Context retention на этот новый кусок кода?
- Имеется ли какой-либо связанный с RxAndroid код? Если да, проверьте, утилизируются ли RxCalls в конце области жизненного цикла (ViewModel/Fragment/Activity).
- Если в коде есть coroutines, проверьте, правильно ли запускается Job из области видимости ViewModel.
- Является ли код реализацией, использующей CountDownTimer, AsyncTask или какой-либо видео/аудио плеер? Если да, то код должен освобождать ресурс памяти, связанный с предотвращением утечки.
- Если это новый фрагмент с использованием ViewBinding, то код должен освободить привязку в методе onDestroyView.
private ResultProfileBinding binding;
@Override
public View onCreateView (LayoutInflater inflater,
ViewGroup container,
Bundle savedInstanceState) {
binding = ResultProfileBinding.inflate(inflater, container, false);
View view = binding.getRoot();
return view;
}
@Override
public void onDestroyView() {
super.onDestroyView();
binding = null;
}
Глубокие макеты
Иногда у нас есть ViewGroup, которая имеет другую ViewGroup в качестве дочерней.
Хорошим предложением всегда является использование в качестве ViewGroup ConstraintLayouts, чтобы сохранить более плоские макеты. Это поможет избежать перерисовки, которая вызывает проблемы с производительностью.
<LinearLayout>
<FrameLayout>
<RelativeLayout>
<ConstraintLayout>
<View />
<View />
<View />
<View />
</ConstraintLayout>
</RelativeLayout>
</FrameLayout>
</LinearLayout>
В документации по Android есть несколько советов по уменьшению размера.
Аннотации ресурсов
Каждый ресурс в мире Android имеет идентификатор, который представляет собой тип Integer. Как убедиться, что наше значение Integer представляет собой действительный идентификатор ресурса? В этом вопросе нам помогут аннотации.
Например:
fun showMessage(context: Context, val idRes: Int) {
Toast.makeText(context, idRes, Toast.SHORT_LENGHT).show()
}
В приведенном выше коде рецензент мог бы предложить: «Как вы думаете, как использовать аннотации? Что-то вроде этого:» (покажите пример):
fun showMessage(context: Context, @StringRes val idRes: Int) {
Toast.makeText(context, idRes, Toast.SHORT_LENGHT).show()
}
Другие примеры аннотаций: здесь.
Похожие компоненты
Очень важно уделять время обзорам кода. Постарайтесь думать так, как думал автор, отражая его выбор, задавая вопросы, чтобы понять код.
Появляется новый код. Подождите: «Этот код делает то же самое, что мы уже имеем в этом компоненте». Комментарии, подобные этому, необходимы, потому что великая вещь — повторное использование того, что уже есть в нашей кодовой базе. Обратите внимание, когда компоненты выглядят примерно так:
- Компонент X меняет цвет луны на красный 🔴;
- Компонент Z меняет цвет полной луны на синий 🔵;
- Компонент А превращает луну в зеленую 🍏.
Почему бы не сделать компонент для изменения цвета любой луны? Он может получать цвет в качестве аргумента. Не слишком ли много работы?
Зоны опасного кода
Если у вас чувствительный код — мне нравится выражение опасная зона, которое лучше описывает эту ситуацию. Опасный код — это код, на который рецензент смотрит и дает такую реакцию, как: «Этот код не имеет никакого смысла».
В этом случае не стоит осуждать автора. Поговорите с ним, чтобы понять, что стоит за этим кодом. Этот разговор может стать возможностью узнать что-то новое.
Нарушение архитектуры
Архитектура программного обеспечения — это протокол связи, определенный между частями программного обеспечения.
Обзор кода — очень эффективный инструмент для выявления таких проблем, как нарушение архитектуры. Добавление комментариев, подобных этим, полезно в таких сценариях:
- «Друг, твоя ViewModel обращается к репозиториям. У нас есть UseCase между ними. Пожалуйста, взгляни на файл MainViewModel, это отличный пример».
- «Почему ты используешь ссылку на Adapter внутри твоей ViewModel? Адаптер — это компонент RecyclerView. Было бы лучше поместить это во Fragment и держать подальше от нашей ViewModel».
Маленькие детали делают разницу
- Неиспользуемый импорт;
- Не используются ресурсы, такие как drawables, strings, colors…
- Закомментированный код;
- Не отформатированный код;
- Имена переменных, имена методов, имена файлов, …
- Код, не соответствующий руководству по стилю. Например, Kotlin определяет четко сформулированное руководство по стилю. Это очень помогает любому разработчику быстро найти любой программный компонент в существующей кодовой базе.
Заключение
Инструменты статического анализа полезны в процессе ревью кода, но они не эффективны на 100%. Критический анализ разработчиков незаменим, если ваша команда стремится к качеству кода.
