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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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