Вы работаете в команде, которая заботится о качестве кода. Вы делали или думали о создании пары кода. Ваша команда регулярно проводит хакерские мероприятия, чтобы рассказать и представить новые технологии или рассказать о личных открытиях каждого участника. И вы пытаетесь разработать идеальный процесс проверки кода для своей организации. Вам знакома эта ситуация?

Проверку кода сложно реализовать. Команда состоит из N человек, у каждого из которых своя повестка дня и приоритеты. Некоторые люди могут быть более перфекционистами и могут иметь другие критерии приемлемости для проверки кода. Некоторые другие искренне верят, что обзоры должны быть посвящены каждой новой функции или исправлению и должны быть полностью добровольными. Как и в любой команде, нужно убедить, а не навязывать.

Какова цель проверки кода?

После нескольких лет его применения (а точнее, сравнения с тем временем, когда я их не использовал), я могу думать только о проверках кода в положительных терминах. Если они реализованы должным образом, в них нет единого недостатка, а все дело в преимуществах. Это список читов, который я когда-то написал, чтобы убедить других членов команды в том, почему мы должны применять обзоры кода:

  • Обучение других разработчиков: программные системы сложны. Вы, вероятно, будете работать на обширных платформах, зная 5%, может быть, 10% от общего числа глобальных. Вы не знаете, что происходит на другой стороне, и это большое ограничение. Время ограничено, а давление обычно достаточно велико, чтобы вы не могли свободно бродить по другим модулям. Обзор кода может познакомить вас с другой частью платформ, не занимая много времени - и да, это потрясающий вводный метод для новых членов команды. Проверка кода - это инструмент для передачи знаний.
  • Повышение качества кода: программирование погружает вас в мысленный поток, в котором вы изолируетесь от внешних воздействий и сосредотачиваетесь на одной цели. Это делает вас предвзятым, поскольку вы думаете «как мне заставить это работать?». Внешний разработчик подумает: «как я могу это исправить и где найти слабые места?». Это причина, по которой разработчики никогда не должны тестировать свой код, а также почему у нас есть специализированные тестеры QA. Представление третьего лица для проверки, скорее всего, обнаружит ошибки, которые в противном случае останутся незамеченными.
  • Создание развивающейся культуры: все мы работаем над правилами и стилем программирования. У всех нас есть свои странности и увлечения, которые мы приобрели за годы разработки, но в организации мы хотим, чтобы все вписывались в одну развивающуюся культуру. «Но что происходит с творчеством нашей команды!» Я много раз слышал, когда разоблачает этот аргумент. Есть японская пословица 出 る 釘 は 打 た れ る: «Гвоздь, который торчит, забьют». Здесь не нужно забивать гвоздь. Мы можем взять лучшее из западной и восточной философии, чтобы создать радикально крутой процесс, взяв лучшее из каждого мира.
  • Уверенность: если вы работаете в одиночку, вы пишете код для себя. Вам все равно, читается ли код другим человеком, и это вредит вашему качеству. Человек никогда не должен работать один в какой-либо команде: он перегорит, качество кода упадет, проект погибнет). Если вы знаете, что третий человек будет читать и анализировать ваш код, ваш внутренний код приложит дополнительные усилия, чтобы сделать его ясным, кратким и читабельным. Похоже на очень дешевый инструмент для статического анализа кода.

Как нужно делать обзор кода для Android?

Это общие причины и аргументы в пользу проверки кода, но вы читали в начале этой статьи в заголовке слово Android. Итак, как мы можем эффективно проверять код Android? Что ж, есть несколько инструментов и методов, которые мы можем специально применить на нашей зеленой платформе.

Заявление об отказе от ответственности / 50% спама: некоторое время назад я написал статью об автоматизации разработки под Android, в которой была представлена ​​модель ветвления и фиксации в репозитории Git. Принятие модели ветвления и разработки имеет решающее значение для реализации процесса проверки кода. Все проверки кода должны быть выполнены до того, как одна ветка будет фактически объединена с другой. В моей конкретной модели проверки кода выполняются в следующих разделах:

  • Когда функция завершена и ее нужно объединить в альфа-версию.
  • Когда ошибка была обнаружена во время спринта по исправлению ошибок, и ее необходимо объединить в бета / альфа.
  • Когда исправление завершено, и его нужно снова объединить.

ОБНОВЛЕНИЕ: Мой коллега Ник Скелтон, который представлял мне эту тему на разных конференциях, также разместил свою статью с идеями и дальнейшим расширением модели. Я полностью рекомендую это проверить.

Начиная

Прежде всего, это модель, которую я использовал в своей предыдущей компании, а теперь как независимый подрядчик. У меня это сработало. Это особенно сработало, когда дело доходит до разработки под Android. Но не забывайте, что в программной инженерии нет ничего догматичного. Теории должны быть адаптированы к каждому сценарию, поэтому возьмите отсюда то, что вам нравится, и не стесняйтесь изменять.

Когда у меня есть ветка в одном из трех ранее упомянутых корпусов, которую необходимо объединить, я открываю запрос на вытягивание и назначаю по крайней мере одного (а лучше двух) других разработчиков для проверки кода. Необъяснимо, что в некоторых средах разрешен только один рецензент на PR (Доброе утро, GitHub!), Поэтому этот процесс нужно выполнять вручную (когда рецензент A завершает работу, он должен назначить рецензию рецензенту B). Оптимально один рецензент должен быть из команды разработчиков (они осведомлены об ограничениях и статусе проекта), а второй - из чужой команды (мы хотим поделиться знаниями с этим человеком).

Рецензенты имеют право вето. Им обоим нужно договориться об объединении ветки. Это порождает командный дух, поскольку все немного реагируют на каждую функцию, добавляемую в нашу систему, даже если они не являются прямыми участниками. Когда возникают разногласия, их нужно обсуждать и решать в нашей PR Dashboard, пока мы не достигнем консенсуса. Если фигура рефери абсолютно необходима, руководитель группы или подобная фигура должны иметь право принимать решения - хотя за все годы моего опыта у меня никогда не было проблем с блокировкой PR из-за отсутствия согласия блестящих придурков!

Правильный PR начинается с локальной загрузки ветки и ее компиляции в нашем эмуляторе или устройстве. Зачем это нужно? Что ж, Android - это фрагментированная платформа с богатой экосистемой плагинов и версий. 99% этих проблем можно избежать, воспроизведя среду на другом компьютере и устройстве / эмуляторе.

Я также выступаю за неформальное тестирование новой функции или ошибки. Из-за приобретенных нами предубеждений мы часто упускаем тривиальные моменты в процессе разработки, потому что сосредотачиваемся на своей функциональности. Еще один большой процент ошибок можно обнаружить с помощью этого простого шага: запросить функциональные требования и проверить, что приложение им следует.

Чтобы легко связать функциональные требования с ветвями и PR, будет хорошей стратегией назвать наши ветки в качестве нашей заявки (например, PROJECT-123). Большинство сред позволяют нам связать PR с репозиторием заявок, содержащим описание заявки и функциональные требования, поэтому рецензенту легче получить к нему быстрый доступ.

Когда нам их делать?

Мы должны избегать перебоев. Если это не исправление, я обычно проверяю код после обеденного перерыва или начинаю во время перерыва на Помидор. Таким образом я гарантирую, что они не мешают моему собственному развитию, но это делается в более расслабленный момент.

Проверка кода также не должна занимать более 30 минут, но это во многом зависит от того, насколько детализированы реализуемые вами функции. Если вы обнаружите, что более 30 минут непрерывно заняты проверкой кода, это хороший момент, чтобы поговорить с вашим менеджером проекта и обсудить, адекватны ли масштабы реализуемых вами функций или нет.

Анализ кода

Итак, у нас есть функция в нашем компьютере. Он скомпилирован, соответствует функциональным требованиям, и теперь нам нужно приступить к анализу кода. С чего начать? Какие вопросы мы можем задать коду?

Шаблоны архитектуры

  • Соответствует ли этот код нашему архитектурному шаблону? MVP, MVC, MVVM, шина событий?
  • Выполняется ли какая-либо операция в неправильном классе? (т.е. логика данных во фрагменте)

Тестирование

  • Создан ли тест для функции или ошибки? Обновляются ли предыдущие тесты?
  • Реализованы ли все типы тестов? Модульные тесты, интеграционные тесты и тесты пользовательского интерфейса.
  • Новые тесты в настоящее время работают?

Статический анализ кода

Один из моих любимых! В Android мы можем использовать Lint для статического анализа исходного кода. Некоторые из этих комментариев могут иметь смысл, а некоторые нет (например, я получаю много предупреждений об орфографических ошибках ... потому что я в основном работаю с немецкими командами, которые, как правило, используют немецкие имена, что приводит к таким именам переменных, как datenbankVerbindung. Если у вас есть устаревший код и нет ресурсов для рефакторинга, вы можете отключить предупреждения об устаревании.

Практическое правило: я применяю Lint ко всем новым добавленным файлам и к предыдущим измененным файлам. Я вручную проверяю, что предупреждения Lint имеют смысл, и уведомляю, когда они появляются, и код можно улучшить.

Линт может быть очень кстати. Уведомляет о возможных ошибках и утечках памяти. Он также уведомляет об устаревшем коде, проблемах стиля и соглашениях об именах. Это может быть мощный образовательный инструмент.

Стиль кода

Каждая организация должна иметь собственное руководство по кодированию (и если у вас его нет, самое время начать его определять). Во время моей работы в Sixt мы открыли исходный код наших руководств по кодированию. В Android есть несколько руководств по написанию кода для участников, которые вы можете использовать в качестве вдохновения для своих собственных. И, конечно же, в библии Чистый код есть обширный набор рекомендаций по чистому кодированию и стилизации кода - книга, которую вы обязательно должны прочитать, если вы еще не читали ее.

Детка автоматика!

Судя по предыдущим шагам, некоторые из них можно очень легко автоматизировать. Lint можно легко настроить в Jenkins для выполнения с каждой сборкой. Сначала нам нужно установить Lint plugin на нашем сервере Jenkins CI. Затем нам просто нужно активировать его в нашей конфигурации задания:

Как полезное правило, вы должны деактивировать Lint в вашем файле Gradle, чтобы приложение не прекращало сборку. Это легко сделать с помощью следующего фрагмента кода:

android {
    // ...

    lintOptions {
        // Don't abort if Lint finds an error, otherwise the Jenkins build
        // will be marked as failed, and Jenkins won't analyse the Lint output
        abortOnError false
    }
}

Я предпочитаю отмечать сборки Lint как нестабильные, а не как неудачные, и проверять вывод вручную (опять же, это будет зависеть от политики вашей компании). Jenkins можно даже настроить для запуска Lint, когда открыт PR! Я не могу перестать говорить, насколько использование Jenkins облегчает жизнь всем в офисе, но я все еще удивлен, как много людей все еще не используют его - мое случайное предположение после того, как я задавал его на многих конференциях, вероятно, составляет треть компаний .

Рекомендации по кодированию и стили также можно автоматически проверить в Android. Вы можете использовать Checkstyle (инструмент разработки, обеспечивающий соблюдение стиля кодирования) и запускать его в соответствии с вашим кодом. В Checkstyle есть плагины для Android Studio, Jenkins и, конечно же, для других платформ. В зависимости от строгости, которой вы будете следовать, вы можете сделать сборку неудачной или пометить ее как нестабильную. Мне лично нравится отправлять коммиттеру автоматический отчет, в котором упоминаются недостатки в его стиле кодирования.

Выводы

Выполнение обзора кода похоже на приготовление: это личный процесс, в котором необходимо следовать только основным принципам, а заключительная процедура имеет тенденцию к ветвлению и отличаться от первоначальной посылки. Однако после прочтения этого поста у вас должно появиться более четкое представление о том, с чего начать и как проверить, и аналогично, если вы опытный разработчик, я надеюсь, что вы смогли почерпнуть несколько идей и вдохновения.

Прежде чем закончить статью, я хотел бы отметить еще несколько моментов:

  • Проверки кода касаются кода, а не человека. Это должно быть ясно сказано каждому члену команды, чтобы не принимать его на свой счет. Цель состоит в том, чтобы выпустить высококачественный код, а не увеличить эго.
  • Следует также отметить хорошие вещи. Когда я нахожу что-то умное или блестящее, я учусь на этом и сообщаю об этом разработчику.

Я всегда думаю, что живые демонстрации намного лучше, чем теоретический пост, поэтому я планирую опубликовать еще несколько статей с конкретными идеями и обзорами кода. Если вам интересна тема, не стесняйтесь подписываться или подписываться на меня в Twitter! Если вам понравилась статья, нажмите на сердечко внизу, чтобы порекомендовать ее, и не стесняйтесь поделиться ею :-)

Спасибо Corey Latislaw за отзыв, вы молодцы!