Сохраните качество своей кодовой базы за счет активного участия

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

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

1 - Определение «Готово» для разработчиков

Вы будете удивлены, что одних только хороших практик недостаточно, чтобы что-то предпринять.

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

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

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

Пример контрольного списка

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

  • Требования реализованы без каких-либо затяжных незаданных вопросов (постарайтесь, по крайней мере, известные неизвестные)
  • Если практикующий BDD, сценарии определены, чтобы гарантировать, что требования поддаются проверке.
  • Если проект кроссплатформенный, все платформы прошли проверку на работоспособность.
  • Были добавлены или обновлены модульные тесты для новых или измененных функций. Существующие модульные тесты не были нарушены в процессе. Уже известные тесты, ожидающие каких-то действий
  • Вам приходилось что-то взламывать, чтобы что-то работало? Если это не произошло, отметили ли вы взлом с помощью комментария к коду с возможностью поиска?
  • Для новых файлов использовался инструмент форматирования кода (с общими настройками вашей команды)
  • Файлы изображений были оптимизированы для минимального сжатия без потерь перед фиксацией
  • Большие двоичные файлы проверяются с помощью расширения системы управления версиями без раздувания (например, с помощью git lfs, git fat или git-application).
  • Непрерывная интеграция: задачи сборки передаются на машины CI. Модульные тесты проходят на машинах CI, а не только на вашей машине.
  • Выполните обратную интеграцию из целевой ветки (если вы не перебазировали перед отправкой), разрешите конфликты слияния и повторно запустите CI, при необходимости проверьте работоспособность

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

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

2 - Упреждающая самооценка

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

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

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

3 - Парное рассмотрение

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

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

4 - Стратегия ветвления и слияния

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

На вашем компьютере разработчика локальные личные ветки доступны для всех - делайте, что хотите, при условии, что вы никому не причиняете вреда. Когда приходит время объединяться в ветки, на которые полагаются другие, вы должны убедиться, что они это сделают. У вашей команды должна быть четко определенная стратегия ветвления.

Существуют разные типы ветвей, с разным сроком службы и разным уровнем устойчивости. Таким образом, к фиксации и слиянию следует подходить по-разному. В духе хорошей практики ветки используются, чтобы препятствовать передаче кода непосредственно в master / mainline / trunk, который должен принимать изменения только путем слияния.

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

Bugfix ветки: короткое время жизни

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

Ветки функций: средний срок службы

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

Ветви совместной работы функций: от короткого до среднего срока службы

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

Эпические ветки: долгая жизнь

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

Основная ветка: постоянная

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

  • Никогда прямо не передавайте мастеру (за исключением разумных исключений)
  • Никогда не объединяйте в мастеринг ничего, что не компилируется на CI.
  • Никогда не объединяйте ничего, что нарушает или блокирует самые основные функции.
  • Должны быть приложены разумные усилия для того, чтобы модульные тесты проходили через master; сбои должны решаться быстро
  • Автоматизация пользовательского интерфейса должна запускаться из этого на регулярной основе, если не на CI
  • В идеале без незаконченных работ; обычно следует объединять только те функции, которые соответствуют определению разработчика.

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

Когда кто-то ломает хозяина, должно быть немного легкого или игривого стыда :) Ничего слишком серьезного, потому что все делают ошибки, но мы также не хотим давать понять, что это нормально, чтобы сделать это привычкой.

Стабильная ветка: постоянная

Это более зрелая версия от мастера, поэтому больше подходит для не разработчиков, таких как QA. Наличие этого буфера между главной и релизной ветвями должно позволять периоды «замораживания кода», не блокируя прогресс в мастере.

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

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

Stable может перейти к выпуску после завершения всех тестов для следующего выпуска.

Ветки выпуска: постоянные

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

  • Когда все функции или исправления, которые должны быть выпущены, завершены и прошли приемку QA и PO (и / или UAT)
  • Когда стабильный продукт прошел полное регрессионное тестирование QA

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

Стратегия именования

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

Заключение

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