Прикладные способности и мысли

Совсем недавно я пришел к идее, названной Шаблоном Strangler Application. Насколько я понимаю, это решение проблемы с большими устаревшими системами. Идея состоит в том, чтобы создать новое приложение вокруг старого приложения. Стоимость и риск этого будут намного меньше, чем полная перезапись системы. Медленно, со временем новое приложение будет делать все больше и больше работы и, в конечном итоге, задушить старое устаревшее приложение. В то же время разработчики приступают к работе в чистой новой системе с более высокой эффективностью и, надеюсь, производят гораздо лучший код.

Теперь, когда я работаю, мы пришли к выводу, что новые функциональные возможности, даже кажущиеся тривиальными, требуют много времени для разработки, с высоким риском взлома чего-то. Мы сидим около миллиона строк кода, с охватом unit test, возможно, 1-2%. Система представляет собой SOA-систему, использующую веб-службы (на самом деле это не так) и более процедурная по стилю, чем объектно-ориентированная. Система - это как веб, так и выигрыш, все написанные на языках программирования .net.

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

Литература:

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

Старое название школы для этого - "обертка". Это звучит здорово; кто хочет возиться со старым приложением, когда вы можете написать что-то новое и чистое, чтобы его изолировать? Проблема в том, что он создает слой goo, и незадолго до того, как кто-то решит, что сама оболочка грязная. Какое решение для этого? Еще одна обертка? Как я вижу, такие обертки и "душители" в основном заканчиваются бронированием оригинального приложения и в конечном итоге делают вашу жизнь труднее. Но люди часто выбирают краткосрочные решения, которые являются субоптимальными в долгосрочной перспективе. В конце концов, никто не заметит, пока вы не уйдете.

Ответ 4

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

Что может пойти не так?

Организации могут обнаружить, что может быть трудно сохранить долгосрочные проекты обновления инфраструктуры, финансируемые в результате новых проектов которые обещают новые возможности, конкурентные преимущества, потенциал дохода, или увеличить уровень рынка - особенно для организаций, которые ориентированных на продукт или услугу. Это один из тех видимые проблемы, и, хотя его легкий козел отпущения, его обычно не единственная угроза.
Когда система заменяется слишком тесно связана с заменой системы, это может существенно увеличить технические трудности - это может быть в порядке, чтобы они имели одну конкретную точку интеграции, но больше, чем проблема. Когда команда отвлекается на технологические проблемы, которые они создали для себя, theyre not более эффективная работа и сроки выполнения проекта контроль.
Технологические команды, которые организованы по горизонтали, могут иметь особенно трудное время с шаблоном StranglerApplication, поскольку вертикальные срезы, необходимые для завершения работы, требуют интеграции с несколько отделов или команд для завершения, и каждая группа имеет свои собственные циклов выпуска, целей и организационного давления.
Если есть замена основного технического или управленческого персонала в ходе проекта, иногда новые люди, которые наследуют проект, находят, что они не нравится новая система, лучше, чем та, которую она заменяет - что привело к потенциальной третьей системе.
Иногда вы можете частично, и создать новую версию системы, но когда она приходит время, чтобы вернуться и перезаписать системы с более низким значением, чтобы начать используя новую систему, люди слишком заняты, делая классные новые вещи с новой системы. Теперь у вас две системы. Или, если вы уже сделали это однажды, у вас будет три.

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

Ответ 5

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

Привет