TLDR ‍

  • Заставьте всех делать код-ревью, даже джуниоров
  • Проверить читаемость кода
  • Убедитесь, что запрос на включение создает пассивную документацию.
  • Тест производительности
  • Проверьте потенциальные угрозы безопасности
  • Проверить тестируемость

Отказ от ответственности:Это руководство предназначено для компаний с постом Product-Market-Fit. Если ваша компания еще не внедрила PMF, вы должны оптимизировать скорость итерации превыше всего. Если вы работаете до PMF, ваша численность персонала также должна быть как можно меньше, поэтому многие из приведенных здесь рекомендаций не применяются. Адаптируйте в соответствии с вашими потребностями.

Мы все видели что-то подобное раньше.

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

Однако наличие культуры ненадежных или нулевых проверок кода приводит к накоплению технического долга.

‍

Что такое проверка кода?

Проверка кода — это процесс проверки кода другим разработчиком. Разработчик отправляет новый код для интеграции в основную ветку и просит товарища по команде проверить его.

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

Хорошо налаженный процесс проверки кода также помогает обучать вашу команду. Это помогает разработчикам учиться друг у друга.

Итак, как лучше всего заставить код-ревью работать?

‍

Заставьте всех делать проверки кода

Даже самый младший разработчик должен просматривать пул-реквесты технического руководителя.

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

Это, однако, заставляет старшего разработчика лучше объяснять свои изменения кода.

Существует 2 метода распространения отзывов о пулл-реквестах. GitHub, например, предоставляет возможность автоматически назначать рецензента по связям с общественностью, используя и то, и другое.

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

Алгоритм балансировки нагрузки фокусируется на распределении отзывов о запросах на вытягивание в зависимости от количества невыполненных запросов на вытягивание, которые есть у каждого члена команды. Этот алгоритм пытается гарантировать, что все просматривают одинаковое количество запросов на вытягивание в любой 30-дневный период.

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

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

‍

Проверить на удобочитаемость

Код должен быть читабельным, чтобы его можно было сопровождать. Код должен поддерживаться, чтобы быть полезным для команды разработчиков программного обеспечения. Вот контрольный список для читаемости кода.

  • С пакетами все в порядке? Иногда пакеты выпускают новые версии и содержат критические изменения. Однако, как предлагает Бенджамин Сильва, принятие огромных изменений, когда они происходят, является частью сделки. Потратьте несколько дней на рефакторинг, когда выйдут большие выпуски версий, и таким образом вы всегда будете иметь свои пакеты в актуальном состоянии.
  • Соответствует ли код стандартам вашей организации? Стандарты очень специфичны для каждой команды и могут касаться соглашений об именах, линтинга или, вообще говоря, некоего набора правил, с которыми согласны люди в команде.
  • Являются ли имена переменных и функций описательными? Используйте имена, раскрывающие намерения, остерегайтесь имен, которые немного различаются, используйте произносимые имена и используйте имена с возможностью поиска (например: не называйте индексы массива i и j, назовите их описательно, например, numberOfTasks).
  • Можно ли разбить функции кода на более мелкие? Для этого стоит провести рефакторинг кода.
  • Нужны ли коду комментарии? Да.

‍

Включает ли запрос на вытягивание полезную пассивную документацию?

  • Заголовок. Дает ли заголовок информацию об изменении? Хорошей практикой является включение кода тикета (Jira, Linear, Notion, ClickUp или любой другой системы тикетов, которую вы используете) в заголовок, чтобы связать эти две части информации. Еще одна хорошая практика в именовании запросов на вытягивание — начинать их заголовок с глагола в повелительном наклонении настоящего времени (например, "переместить модуль…", "создать функцию...", "отладить функцию...")‍.
  • Описание. Объясняет ли автор проблему? Предполагаемое решение? Есть ли план тестирования? Содержит ли описание скриншот или видео?‍
  • Указан ли тип изменения в описании? Включение этой информации упрощает поиск для вашей команды.

Если вы хотите взглянуть на шаблон запроса на вытягивание, взгляните на тот, который у нас есть в нашем репозитории с открытым исходным кодом.

‍

Проверка производительности

Насколько строгим это должно быть, на 100 % зависит от стадии организации, владеющей кодовой базой. Требования к тестируемости для корпорации, которая имеет хорошо зарекомендовавший себя продукт, приносящий доход, с миллионами пользователей; отличаются от стартапов на ранней стадии, у которых есть экзистенциальная потребность найти Product-Market-Fit, иначе у них закончатся деньги. Первое нужно оптимизировать для строгости, а второе — для скорости итерации.

Если вы хотите оптимизировать строгость, вот что нужно протестировать.

  • Проверьте, нет ли ненужного ведения журнала кода. Ведение журнала в неправильном месте может значительно снизить производительность и раскрыть информацию, которая должна оставаться конфиденциальной.
  • Проверить типы данных. Основываясь на ожидаемых значениях, типы баз данных можно оптимизировать для повышения производительности. Например, в SQL, если данные различаются по длине, более эффективно использовать varchar, чем char. Если столбец будет хранить значения от 1 до 5, используйте tinyint вместо int.
  • Можно ли повысить производительность, добавив или удалив индексирование? В зависимости от контекста это может быть так. Индексация не гарантирует волшебным образом более быстрое время поиска. Например, если вы нарушите свойство Первая нормальная форма, индексация в некоторых случаях приведет к снижению производительности.
  • Можете ли вы отображать полученные данные на стороне сервера? Вообще говоря, быстрее выполнять все запросы на сервере, чем выполнять для них дополнительные циклы взаимодействия между браузером и сервером. Рендеринг на стороне сервера не всегда применим, но если он есть, то должен быть.
  • Могут ли запросы возвращать меньше данных? При масштабировании возврат слишком большого количества данных по запросу снижает производительность.

Проверьте наличие потенциальных сбоев безопасности

  • Проверяйте сообщения об ошибках, содержащие чрезмерную информацию. Будьте информативными, но не слишком информативными. Иногда эти сообщения могут дать злоумышленнику информацию, необходимую для взлома.
  • Проверка открытых секретов среды. Поощряйте использование хороших методов управления секретами в вашей организации. Как только секрет среды раскрывается в удаленной ветке, он всегда будет в Интернете. Его нужно менять немедленно.
  • Убедитесь, что авторизация и аутентификация обрабатываются правильно:Всегда используйте https. Рассмотрите возможность использования разных ключей API для разных ролей и уровней разрешений.

‍

Тестируемость

  • Проходят ли тесты? Будь то модульные тесты, сквозные тесты или и то, и другое… Убедитесь, что они проходят успешно. Если уже существующий поток пользователей изменился, обновите тесты соответствующим образом.‍

Первоначально опубликовано на https://www.watermelontools.com.