Что важно помнить при реинжиниринге устаревшего приложения?

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

6 голосов | спросил jellyfishtree 28 TueEurope/Moscow2010-12-28T02:38:22+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 02:38:22 +0300 2010, 02:38:22

7 ответов


15

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

ответил Robert Harvey 28 TueEurope/Moscow2010-12-28T02:41:11+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 02:41:11 +0300 2010, 02:41:11
10

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

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

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

ответил Macneil 28 TueEurope/Moscow2010-12-28T03:18:17+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 03:18:17 +0300 2010, 03:18:17
4
  1. Поймите, что делает существующая база кода. В любом старом унаследованном приложении может быть большое количество особых случаев, ожидающих пользователей, опасайтесь их и только намеренно и рационально изменяете существующее поведение.
  2. В сочетании с 1. вы также должны проверить, что новая функциональность делает то, что предназначено (исходя из понимания того, что она сейчас делает или будет меняться).
  3. Если это большое приложение или кодовая база, планируйте инкрементное внесение изменений, это должно уменьшить опасность одного большого выпуска и показать прогресс.
  4. Будьте особенно осторожны при работе в среде, которая неоднородна в версиях программного обеспечения: остерегайтесь форматов файлов, сетевых протоколов, форматов общей памяти. Проверьте и убедитесь в совместимости версий.
  5. Если вы меняете систему хранения данных, будьте готовы зеркально копировать записи в новую систему, чтобы протестировать нагрузку и постепенно переход читается в новую систему, сохраняя при этом записи в старую систему. После того как новая система станет надежной, добавьте новую функциональность.
ответил Alaric 28 TueEurope/Moscow2010-12-28T03:32:32+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 03:32:32 +0300 2010, 03:32:32
3

Попытка придумать то, что еще не было сказано:

  1. Безопасное участие в управлении. Помните, что успех проекта с высоким уровнем риска часто зависит от участия в управлении. Удостоверьтесь, что у вас есть законные и активные заинтересованные стороны, которые хотят этого плохо. Если нет, вы можете обнаружить серьезные препятствия, если вы встретите сопротивление изменениям, а при смене систем вы встретите сопротивление изменениям. В одном проекте, в котором мы перемещали людей в новую систему, все, о чем они могли говорить, было то, насколько лучше была старая система. Руководство дало людям возможность попасть на борт, и если бы были серьезные инакомыслящие, они были освобождены. Печальная правда состоит в том, что были части старой системы, которые были действительно лучше (длинная история, которая слишком удручающая для меня, чтобы пересказывать здесь), но поскольку руководство было серьезным, команда внедрения получила необходимую поддержку.
  2. Защитите чемпиона на стороне пользователя для проекта. Если менеджер продуктов предыдущего приложения находится на борту и активно участвует, это плюс. Если нет, эксперт-пользователь, которого уважают в сообществе, будет иметь важное значение. Демарко и Листер что-то говорили однажды: «Каждый раз, когда приходит новая система, кто-то получает власть, а кто-то теряет власть». Если хороший лидер на стороне пользователя находится на борту с вещами, они потенциально могут сгладить путь для принятия пользователем.
  3. Относитесь к новой системе, как к новому проекту, и у вас есть хороший аналитик. Этот аналитик может быть старшим разработчиком, но что бы вы ни делали, вы не хотите делать ошибку, говоря: «О, это будет легко, просто делайте то, что делает старая система, но лучше». Проблема в том, что если старая система похожа на большинство из корпоративной Америки, то точное определение «то, что старая система» может быть не так просто, как кажется ... есть, вероятно, устаревшая, если таковая имеется, документация и партии о жестоких старых способах делать вещи в системе, которые могут быть даже не актуальны. Много раз системы делают что-то просто потому, что так оно и было сделано в старом ручном процессе, и вы можете сэкономить много работы и уничтожить много запутанной логики, удалив ненужные осложнения. Иногда лучший код - это строка, которую вы не пишете.
  4. Сначала посмотрите на компонент отчетности. Отчеты часто забываются или остаются законченными как запоздалая мысль, но это проигрывает отличный инструмент для информации. Отчеты старой системы могут рассказать вам, какие пользователи больше всего нужны, и могут стать хорошей отправной точкой для проверки того, что должно быть результатом новой системы. Будьте осторожны, хотя для проверки каждого отчета ... вероятно, некоторые из них даже не используются.
ответил Bernard Dy 28 TueEurope/Moscow2010-12-28T04:38:45+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 04:38:45 +0300 2010, 04:38:45
2

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

ответил Andrew T Finnell 28 TueEurope/Moscow2010-12-28T06:14:14+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 06:14:14 +0300 2010, 06:14:14
2

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

Вот мои мысли:

  • Создайте свою тестовую систему! . Шансы на то, что в текущем проекте их нет, и это прекрасное время для начала. Это также позволяет легко проверить код.

  • Определить успех upfront . Когда вы узнаете, что проект завершен? Без этого вы могли бы в конечном итоге воспроизвести большую часть исходной системы, но погрязли в « еще одном» 'дополнениях к функциям.

  • Скажите НЕТ для заданий синхронизации! . Я потратил 2 года на мою жизнь, очистив беспорядок, сделанный в одной компании, пытающейся запустить бок о бок системы. Плохое планирование и отсутствие коммерческого бай-ина создали эти задания, а в конце значительно замедлили окончательное время разработки.

ответил mpeterson 28 TueEurope/Moscow2010-12-28T07:26:51+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 07:26:51 +0300 2010, 07:26:51
0

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

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

ответил IAbstract 28 TueEurope/Moscow2010-12-28T03:59:36+03:00Europe/Moscow12bEurope/MoscowTue, 28 Dec 2010 03:59:36 +0300 2010, 03:59:36

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132