Как управлять часто модифицируемым рабочим кодом?

Question

Мой проект побуждает меня внести множество изменений в производственный код. Требование продолжает удовлетворяться, и мне нужно внести изменения и развернуть его как можно скорее. Я иногда заканчиваю тем, что создаю код, работающий над патчами, потому что некоторые требования не вписываются в общий дизайн программного обеспечения. Как это может быть эффективно обработано? Любой шаблон дизайна, чтобы справиться с этим?

Answer 1

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

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

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

Да, и, как и все остальные, вам нужна техническая инфраструктура, такая как система подготовки / тестирования, процедура выпуска одним щелчком мыши и т. Д.

Answer 2

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

Редактировать: ответ на вопрос комментария.

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

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

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

Answer 3

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

Я бы спросил: «Какой процесс я могу использовать, чтобы предотвратить это?»

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

Answer 4

Я нахожусь в счастливом положении, где моя ГОЛОВКА почти всегда высвобождается. По крайней мере, один раз в неделю, у меня есть код в HEAD, который я, как разработчик, с удовольствием выпустил бы. Это не значит, что каждая выпускаемая версия действительно получает релиз, но это возможно. В моей среде еженедельный выпуск на самом деле довольно практичен и обычно делается ...

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

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

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

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

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

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

Answer 5

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

Answer 6

Вы должны наложить дисциплину на ваши требования отставания. Рискуя звучать как старая школа и капризно, скажите людям, что нет, и что им нужно сидеть с вами и изучать конкретные моменты боли и усилий для кардинальных изменений в дизайне. Для баз данных, объясните о кардинальности и как это вызывает душевную боль. Бросьте сено в клетку и настаивайте на запланированном цикле выпуска, когда вы будете участвовать только в работе каждый вторник, но только после того, как пользователь получит одобрение. Разбейте каждый запрос на сегменты по 2,4 и 8 недель и строго определите, что вы будете включать в эти сроки.

Существует множество шаблонов проектирования, которые могут помочь вам, если у вас есть определенная область проблем и способы их решения. В частности, просмотрите Командный шаблон , Стратегический шаблон и Архитектура подключаемого модуля , поскольку они помогут вам расширить набор решений. Если вы являетесь разработчиком .Net, взгляните на архитектуру плагинов Migeul Castro, которую он рассмотрел на DNRTV .

Answer 7

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

Answer 8

Это процесс, а не дизайн.

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

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

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

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

Answer 9

Очевидно, что тестирование важно. Но для меня автоматизация - это еще больше. Вы должны иметь возможность развернуть весь проект от исходного управления на производственном сервере менее чем за 3 команды. Такие инструменты, как Maven , Ant , Capistrano , (вставьте сюда свой любимый инструмент <...>), могут вам очень помочь. Также может помочь наличие системы непрерывной интеграции, которая автоматически развертывается на тестовом или интеграционном сервере каждый раз, когда происходит изменение в управлении исходным кодом.

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

Answer 10

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

Я не знаю о других системах, но у monotone есть некоторые хуки, специально предназначенные для того, чтобы тесты помечали коммиты, поэтому есть команда «дать мне последнюю версию, которая проходит все тесты»