Контрольный список Code Review для Android-проектов

Проверка кода — иногда утомительный процесс, но я считаю, что нам нужно уделять этому больше времени. Возможно, для вас это возможность научиться или поделиться какими-то знаниями.
Я перечислил некоторые моменты, которые считаю необходимыми для проверки в процессе ревью кода в проектах 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%. Критический анализ разработчиков незаменим, если ваша команда стремится к качеству кода.