Как узнать правильный подход к реализации половины функций? [закрыто]

12

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

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

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

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

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

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

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

Нильс Бринч
источник
«Существующие функции, конечно же, все еще должны работать» - в зависимости от контекста, термин для такого требования может быть обратной совместимостью или отсутствием ошибок регрессии
gnat
1
Различные типы автоматического тестирования могут снизить риск ошибок при изменении кода. Проверьте. Я ищу подход для использования в качестве разработчика, который должен реализовать большую функцию, которая может включать 75% изменений в существующем коде и 26% нового кода (дополнительный процент есть для дополнительной загадки).
Нильс Бринч
1
@Niels: У вас должны быть замечательные разработчики, чтобы иметь возможность иметь рабочий код в конце каждого дня, который можно проверить в основной ветке и пройти все тесты. Либо это, либо они получают только минимум, так что они могут проверить свой код к концу дня.
Данк
они бы не назвали это «Особенной веткой». Вы вносите свои изменения в ветку, а затем сливаете ветку обратно в мастер, когда функция завершена. Вам не следует представлять наполовину реализованные функции в демоверсиях, поэтому я не понимаю, почему это не сработает.
DELTREE

Ответы:

14

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

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

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

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

Я знаком с двумя инструментами, которые хорошо поддерживают такие процессы. Если ваша структура разработки проста, то git с git-flow реализует хорошую структуру ветвления, которая хорошо работает в небольших и средних командах (возможно, 20 разработчиков).

Для более крупных групп разработчиков или в тех случаях, когда необходима более сложная стратегия ветвления для поддержки нескольких «спинов» вашего продукта, лучше всего использовать accurrev. Разработчики, не участвующие в управлении изменениями, будут жаловаться, что они сложнее, чем подверсии и т. Д., Но поддерживают сложные среды разработки.

Майкл Шоу
источник
Мне было бы очень интересно узнать больше о стратегии ветвления, на которую вы ссылаетесь. У вас есть ссылка на статью или что-то еще, что более подробно объясняет концепцию, на которую вы ссылаетесь?
Нильс Бринч
2
вот nvie.com/posts/a-successful-git-branching-model для потока мерзавцев
Майкл Шоу,
Ключевой характеристикой git flow является его четко определенная стратегия ветвления, что делает его хорошим выбором для продукта, который имеет только один выпуск. Accurrev не применяет стратегию ветвления, но обладает гибкостью и предоставляет инструменты для эффективного управления гораздо более сложным деревом ветвей.
Майкл Шоу
6

Здесь есть две проблемы: одна реализует половину функции; Другой способ доставки продукта во время непрерывного развития.

Реализация половины функции

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

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

Сохранение доставки товара

Здесь есть несколько вариантов:

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

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

Алекс Фейнман
источник
Достаточно просто отключить новую функцию, которая еще не полностью готова. Это хороший совет. Таким образом, основная проблема в поставляемом продукте заключается в том, что СУЩЕСТВУЮЩИЕ функции могут сломаться, если люди не используют правильный подход при изменении существующего кода.
Нильс Бринч
2
Вот тут-то и начинается хорошее тестирование. Если у вас нет достаточного покрытия для вашей кодовой базы, возможно, это могло бы послужить толчком к этим усилиям?
Алекс Фейнман
Но может ли ответ на мой вопрос просто «выполнить хорошую практику кода и выполнить модульные тесты» и т. Д.?
Нильс Бринч
1

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

Обучая их. (Дух)

Обучение будет включать итерацию: пробовать что-то, видеть, как это работает, а затем модифицировать их подход для достижения лучших результатов. Для такого рода вещей я бы рекомендовал дизайн / обзоры кода. Вы увидите, как разработана / реализована эта полуфункция, и сможете высказать свое мнение. «Это и это не сработает, потому что они сломают наш CI; как насчет XYZ?», «Хорошая работа здесь, это действительно чисто».

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

Telastyn
источник
Я полностью согласен с этим. Но точно так же, как я могу научить кого-то, как проводить модульные тесты ИЛИ отсылать их к книге «Искусство модульного тестирования» - есть ли аналогичный ресурс, на который я могу сослаться по этой теме?
Нильс Бринч
1

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

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

Фактически этот подход к конфигурации описан Мартином Фаулером как переключение функций.

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

glenatron
источник
У меня сложилось впечатление, что фиксация всего кода в одной и той же ветке и постоянное развертывание всего моего кода является частью хорошей стратегии непрерывной интеграции?
Нильс Бринч
Читая больше в Непрерывной Доставке, это, конечно, часть этого. Я несколько вздрогнул при мысли об этом - вы хотите развернуть наполовину написанный код, даже если он должен быть деактивирован? Может быть, это хорошо работает в сценарии, где безопасность не важна, но это звучит как подход с высоким риском для многих областей применения. Это, вероятно, помечает меня как старомодного дурака, обнимающего охрану.
Гленатрон
Кажется, есть две конкурирующие стратегии, где у одной есть одна основная ветвь, а у другой есть ветвь для каждой задачи и множество слияний ... Я не уверен, что лучше или лучше - или это затрагивает суть моих вопросов.
Нильс Бринч
Я думаю, это во многом зависит от того, что вы делаете - я бы больше склонялся к веткам, если бы у меня был какой-то приоритет в безопасности и я не хотел рисковать на самом деле развертыванием непроверенного кода там, где кто-то может его найти или это может быть случайно включен. Поэтому, если бы я работал на банковском сайте, я не думаю, что CD подойдет, но, может быть, если бы у меня был высокоразвитый сайт для случайных / случайных посетителей, он мог бы быть идеальным.
Гленатрон