Как управлять часто изменяемым производственным кодом? [закрытый]
Это должно исправить вашу проблему.
ReactDOM.render(
<Provider store={store}>
<Router>
<Switch>
<Route exact path="/" component={ListPage}/>
<Route path="/edit/:itemId" component={ItemPage}/>
</Switch>
</Router>
</Provider>,
document.getElementById('root')
);
12 ответов
Я видел, что это много раз происходит, и это всегда заканчивается в слезах. В прошлый раз клиент потерял миллионы долларов, прежде чем они улучшили свой процесс.
Пользователи всегда хотят, чтобы новые требования были сделаны доступными "как можно скорее", но они не понимают риски внесения изменений таким же образом, что Вы делаете. Они видят стоимость не наличия функции, но они не ожидают то, что произошло бы и сколько денег будет потеряно, если изменение повредит что-то. (Я не означаю предполагать, что Вы не хороший разработчик, просто что в любом нетривиальном программном обеспечении будут ошибки и что неконтролируемые изменения, вероятно, выставят их более быстро.)
Так, я думаю, что необходимо предпринять шаги назад и попытаться спровоцировать обычный план выпуска. Будет сопротивление, но можно быть более эффективными тот путь. Конечно, иногда будет изменение, которое должно быть сразу внесено, но если будет расписание затем, то бремя будет на пользователе для выравнивания по ширине, почему повреждение цикла выпуска имеет смысл.
О, и как все остальные предлагают, Вам нужна техническая инфраструктура как подготовка/система тестирования, процедура выпуска с одним щелчком, и т.д. (См. Тест Joel.)
При тестировании Вам нужна твердая среда тестирования, чтобы быть уверенными, что Ваши меры не повреждают ничто больше.
Править: Ответьте на вопрос комментария.
К сожалению, я не могу думать о действительно звуковом шаблоне / решение сохранить архитектуру в целости помимо занимания время для рефакторинга "взломов". Но у Вас, вероятно, уже есть мало свободного времени начиная с Вашего в производстве. Таким образом, это не легко...
Однако, что еще более важно, если архитектура становится испорченной, потому что действительно необходимо "взломать" решение в, это могло бы на самом деле быть знаком, что первоначальный проект не отвечал фактическим требованиям продукта, потому что, если это было, необходимо смочь фиксировать/исправлять в текущей платформе Архитектуры.
Так пытаясь быть положительными в целой ситуации необходимо принять во внимание меры, и как текущая Архитектура не помогает/соответствует, таким образом, Вы можете позже в будущем, когда текущие исправления начинают улаживать, иметь данные и подсказки для перепроектирования независимо от того, что части Архитектуры требуют дизайна теперь, когда у Вас есть более точные требования, которые Вы обнаружили во время производства.
Можение быть слишком основным ответа, но я думаю, что необходимо провести некоторое исследование на гибкой разработке программного обеспечения.
Помимо очевидных ответов управления версиями, модульных тестов и автоматизированной системы сборки, это кажется, что также необходимо сделать некоторый тяжелый рефакторинг. Если Ваш дизайн продолжает изменяться на основе изменяющихся требований затем, необходимо попытаться изолировать части кода, которые продолжают изменяться в их собственных модулях.
Я нахожусь в удачном положении, где моя ГОЛОВА почти всегда публикуема. По крайней мере один раз в неделю у меня есть код в ГОЛОВЕ, которую, как разработчик, я был бы рад выпустить. Это не означает, что каждая публикуемая версия на самом деле получает выпуск, но она могла. В моей среде еженедельный выпуск на самом деле довольно практичен, и обычно делается...
Сразу прежде, чем развернуться к подготовке, я способствую свой код ответвлению Выпуска. Я всегда развертываю тот же код для проживания, который был ранее протестирован на подготовке.
Любой срочные меры может затем быть сделан в ответвлении выпуска и протестирован на Подготовке, прежде чем быть развернутым. Если фиксация достаточно хороша, я могу объединить ее назад в ГОЛОВУ. Если это был ужасный взлом, я могу повторно реализовать его правильно в ГОЛОВЕ позже.
У меня есть хороший комплект тестов разработчика, которые запущены автоматически на каждой регистрации, которые подтверждают, что я не повредил ничего важного. Мое приложение также запускает внутренние тесты каждый раз, когда оно развертывается, снова делая меня уверенным.
На самом деле удача является меньше фактором, чем Вы могли бы думать. Это не просто произошло случайно; я должен был работать для позволения. Я должен был записать и поддержание хороших автоматизированных тестов, и к получению непрерывного сервера интеграции и возможности создавать-и-развертывать с одним щелчком.
Я регулярно провожу время, очищая мой код как часть моих нормальных опытно-конструкторских разработок. Это обладает двумя преимуществами. Во-первых, это означает, что моя кодовая база начинается относительно чистый, таким образом, архитектура довольно гибка. Во-вторых, это означает, что я способен осуществлять рефакторинг, так как я делаю все это время. Этим я означаю осуществлять рефакторинг в смысле создания ряда индивидуально маленьких преобразований к существующему коду, а не в смысле throw-it-all-away-and-re-implement (который несколько более опасен).
По-моему, этот "непрерывный releasability" является единственным самым большим преимуществом Гибких методологий.
Все здесь предложили довольно хорошие вещи, как тестирование, и т.д. Но я думаю, что должен указать, что можно задавать неправильный вопрос. Вы спрашиваете, существует ли "шаблон", который может помочь с этой ситуацией. Шаблон является проектным решением для решения проблем проектирования. То, что Вы по существу имеете, является проблемой "процесса".
Я спросил бы, "Какой процесс я могу использовать для предотвращения этого?"
К сожалению, (и это - то же, где я работаю), дизайн является проблемой для разработчиков и архитекторов, но процесс является проблемой для менеджеров. И это действительно берет лидерство, чтобы реализовать хороший процесс и придерживаться его. Печально этому часто недостает.
Необходимо наложить дисциплину на отставание требований. Рискуя тем, чтобы звучать как старая школа и раздражительный, скажите людям не и что они должны сидеть с Вами и изучить отдельные моменты боли и усилия для решительных конструктивных изменений. Для баз данных объясните о кардинальности и как это вызывает страдание. Бросьте свой шаг скрутки против клетки и настаивайте на запланированном цикле выпуска, когда Вы будете только роль в производство каждый вторник, но только после того, как приемлемость для пользователя имеет, происходят. Повредите каждый запрос в сегменты 2,4 и 8 недель и будьте тверды о том, что Вы будете включать в те периоды времени.
Существует много шаблонов разработки, которые могут помочь Вам, если у Вас есть определенный домен проблем и их решений. Конкретно рассмотрите Шаблон "команда", Стратегическую модель и Сменную архитектуру, поскольку они помогут Вам расширить свой набор решения более легко. Если Вы - разработчик .NET, смотрите на сменную архитектуру Migeul Castro, он рассмотрел на DNRTV.
Существует несколько жизненных циклов проекта, против которых можно скопировать подход. Этот сайт перечисляет некоторых (он кажется на использование "Кодировать-и-устранять"!), но это ни в коем случае не категорический список, больший список может быть найден здесь.
Как Robert Gould указал, у Вас действительно должна быть платформа подготовки, чтобы проверить, что Вы не собираетесь повреждать что-либо при развертывании для проживания.
два очевидных инструмента являются управлением версиями и тестированием. попытайтесь интегрировать систему выпуска с ними, таким образом, можно фиксировать изменения на каждом шаге, и когда все тесты передают (включая тех, которые для новых требований), система выпуска выбирает 'известную хорошую' версию, которая будет новой.
я не знаю о других системах, но монотонность имеет некоторые рычаги конкретно, чтобы заставить тесты отметить фиксации, таким образом, существует команда, чтобы "дать мне последнюю версию, которая проходит все тесты"
Очевидно, тестирование важно. Но для меня автоматизация еще больше. Необходимо смочь развернуть целый проект с управления исходным кодом на рабочий сервер меньше чем в 3 командах. Инструменты как Знаток, Муравей, Capistrano, (вставляют Ваш любимый инструмент здесь <...>) могут помочь Вам много. При наличии непрерывной системы интеграции, которые развертываются автоволшебно к тестовому серверу или серверу интеграции каждый раз, существует изменение в управлении исходным кодом, может также помочь.
Помещение всей этой автоматизации на месте займет время в первый раз, когда Вы делаете это...
Это - вещь процесса, не вещь дизайна.
Первая вещь, которую необходимо сделать, обучают пользователей, таким образом, у них есть некоторая идея стоимости изменяющихся требований. Это не предназначается, чтобы мешать им изменить их, но постараться не изменять их и запрашивать реализацию как можно скорее, если нет определенная бизнес-потребность. (Я предполагаю, что это - бизнес-вещь, в этом случае это - Ваше задание, чтобы сделать то, что бизнес-потребности в меру Вашей способности, и сообщить людям, что лучшая из Вашей способности, и чего функциональность стоит в полной схеме вещей.)
Вторая вещь состоит в том, чтобы установить два - фиксируют процесс для быстрых мер. Во-первых, Вы заставляете патч на месте поддерживать приложение в рабочем состоянии более или менее удовлетворительно, и затем Вы не торопитесь и придумываете реальную фиксацию. Это может также потребовать некоторого пользовательского образования, и можно найти идею "технического долга" полезной в объяснении этого.
Третья вещь состоит в том, чтобы удостовериться, что у Вас есть ресурсы. Если Вы не можете не отставать от изменений требований как это, Вы нуждаетесь в помощи, и необходимо показать почему. Если власть имущие решают не ввести больше людей, и они понимают, что ограничивает объем модификации, это хорошо также.
Теперь, это может произойти, что Ваши пользователи недоступны, что Вы не можете убедить людей, что быстрые исправления являются очень дорогими в конечном счете и так далее. В этом случае я рекомендую четвертую вещь: полируйте свое резюме и начните искать новое задание. Прямо сейчас похоже, что Вы настраиваетесь для сбоя, и это - очень плохое место, чтобы быть. Как говорится смените свою работу или смените свою работу.