Попса

популярный светский альманах

Тег: разработка

Базовый чеклист для ревью кода

Ревью кода

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

Качество ревью можно повысить при помощи карты контрольных проверок. Данный чеклист взят с хабра и является отправной точкой. Какие пункты вам нужны, а какие нет — решайте сами.

Общее
Работает ли код? Выполняет ли он свои прямые обязанности, корректна ли логика, и т. д.
Легок ли код для понимания?
Соответствует ли код вашему стилю написания кода? Обычно это относится к расположению скобок, названиям переменных и функций, длинам строк, отступам, форматированию и комментариям.
Есть ли в ревью избыточный или повторяющийся код?
Является ли код независимым, насколько это возможно?
Можно ли избавиться от глобальных переменных или переместить их?
Есть ли закомментированный код?
У циклов есть установленная длина и корректные условия завершения?
Может ли что-то в коде быть заменено библиотечными функциями?
Может ли быть удалена часть кода, предназначенного для логгирования или отладки?

Безопасность
Все ли входные данные проверяются (на корректный тип, длину, формат, диапазон) и кодируются?
Обрабатываются ли ошибки при использовании сторонних утилит?
Выходные данные проверяются и кодируются (прим. пер.: например, от XSS)?
Обрабатываются ли неверные значения параметров?

Документация
Есть ли комментарии? Раскрывают ли они смысл кода?
Все ли функции прокомментированы?
Есть ли какое-то необычное поведение или описание пограничных случаев?
Использование и функционирование сторонних библиотек документировано?
Все ли структуры данных и единицы измерения описаны?
Есть ли незавершенный код? Если есть, должен ли он быть удален или помечен маркером типа «TODO»?

Тестирование
Является ли код тестируемым? Например, он не должен содержать слишком много зависимостей или скрывать их, тестовые фреймворки должны иметь возможность использовать методы кода, и т. д.
Есть ли тесты и если есть, то достаточны ли они? Например, они покрывают код в нужной мере.
Юнит-тесты на самом деле проверяют, что код предоставляет требуемую функциональность?
Все ли массивы проверяются на «выход за границы»?
Может ли любой тестирующий код заменен с использованием существующего API?

Источник

О группе управления разработкой

team

Для того, чтобы руководить разработкой продукта, нужно уверенно держать в руках три «руля»:

  1. Административное руководство.
  2. Управление изменениями.
  3. Техническое и архитектурное управление.

 
 
Рассмотрим все три «руля» более подробно.

team

Административное руководство.

Сюда входят четыре из пяти менеджерских компетенций, а именно планирование, организация, кадры и контроль.

Планирование — процессы, связанные с продумыванием порядка выполнения работ для того, чтобы уложить разработку в некоторые оговорённые с заказчиком сроки. Работы должны быть спланированы так, чтобы в ходе исполнения не возникали «пожары», но в то же время никто не сидел без дела. В случае продуктовой разработки это не слишком сложно, если речь идёт о заказной — значительно сложнее, в случае же комбинирования продуктовой и заказной разработки без разделения команд ничего спланировать не выйдет.

Организация — процессы, напрямую не связанные с производством, но влияющие на него. Инфраструктура (рабочие места, обеды, кофе и проч.) и обеспечение коммуникаций.

Кадры — рекрутинг сотрудников, мотивация.

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

Данного перечня работ вполне достаточно для полной загрузки менеджера продукта. При попытке навесить на него второй и третий «рули» возникнет сбивание фокуса и падение производительности всей команды.
 
 

team

Управление изменениями.

Разработчики пишут код по техническим заданиям/требованям, которые должны быть собраны, проанализированы и формально описаны. Кроме того, необходимо на протяжение всей работы над продуктом не упускать из внимания vision — общую концепцию, идею. Сюда входят следующие работы:

Vision — умение не поддаваться желанию навесить на продукт как можно больше функций, забыв о его основном назначении.

Управление техзаданиями/требованиями. В общем доступе всегда должна быть актуальная информация о том, как сейчас работает продукт. Разработчики всегда должны получать технические задания с информацией о том, каким образом им нужно изменить/доработать продукт.

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

Данного перечня работ достаточно для полной загрузки главного аналитика продукта. Именно этот человек должен в деталях знать, как работает продукт на уровне возможностей. Что можно, чего нельзя. Менеджер продукта формирует направление и сроки, главный аналитик организует проработку требований и обеспечение разработчиков техническими заданиями.
 
 

team

Техническое и архитектурное управление.

Сюда входит группа работ по обеспечению производства. А именно:

Архитектурное управление — обеспечение технической целостности и непротиворечивости работы модулей системы, структуры базы данных и проч.

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

Обеспечение технической инфраструктуры — выбор среды разработки, версионного хранилища, организация сборок билдов, методов передачи на тестирование.

Обучение. Организация обучения джуниоров, повышение квалификации мидлов, поддержание матрицы компетенций.

Управление технической документацией. Организация написания технических спецификаций. Особенно актуально для работы над продуктом, являющимся частью комплекса ПО. Без технических спецификаций (это третий вид документации) реализация взаимодействия продуктов будет затруднена.

Консультации аналитиков, выработка вариантов реализации.

Консультации менеджера продукта для корректного распределения задач на разработчиков с учётом степени развития индивидуальных навыков.

Данного перечня работ достаточно для полной загрузки главного разработчика продукта. Этот человек полностью отвечает за группу разработчиков и больше ни за что.
 
 
Таким образом, мы видим три роли, способные, грамотно взаимодействуя, обеспечить непрерывный и стабильный процесс разработки продукта. За кадром осталось тестирование, но его мне хотелось бы рассмотреть в отдельной статье.

Человек, полностью ответственный за продукт — менеджер продукта. Безусловно, в принятии решений должны участвовать все три менеджера, но старшим руководителем, обладающим право вето и последним словом является именно менеджер продукта. Главный разработчик и главный аналитик стоят на одном уровне и руководят группой разработчиков и группой аналитиков соответственно.

Проблема роста

Проблема роста

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

Традиционный для отечественных компаний сценарий, ведущий к подобным проблемам:

Команда состоит из человека с идеей и пары-тройки разработчиков. Он придумывает и держит требования в голове, разработчики весело кодят, о документации никто особо не думает, идёт творческий процесс. В лучшем случае оставляются комментарии в коде.

Продукт усложняется, команда растёт, модулей становится всё больше. Руководитель всё ещё помнит, зачем нужен и как работает каждый кусок системы. Тимлид всё ещё держит в голове всю архитектуру приложения. Начали использовать доску задач и какие-то бесконечные экселевские файлики.

Продукт усложняется ещё больше, часть команды сменилась. Руководитель с трудом помнит корректные сценарии работы кусков системы, тимлид всё чаще отправляет с вопросами о коде к людям, этот код писавшим. Переползают на какую-нибудь систему постановки и контроля задач, потому что иначе никак. Начали потихоньку описывать модули в отдельных документах, лежащих в гуглодоках.

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

Финиш. В продукте бардак.

Бороться можно. Серебряная пуля называется: «выделяем весь консалтинг в отдельный бюджет». С ранних этапов, как бы ни хотелось окунуться в кодинг с головой, сначала проектируем, затем кодим. Произошли изменения — актуализируем документацию. Для того, чтобы не забыть, встраиваем коррекцию документации в карту контрольных проверок и не считаем функционал готовым, если документация неактуальна. Кроме того, нельзя допускать, чтобы разработчики что-либо делали без формальной задачи в системе постановки и контроля задач. Это требование менее критично, но если его не соблюдать, в дальнейшем будет очень трудно найти концы.