Стратегии восстановления старых приложений

Question

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

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

У кого-нибудь есть какие-либо общие советы по подходу к проекту такого типа? Есть ли хорошие ресурсы на эту тему?

Существуют ли какие-либо проверенные и проверенные методики или обычные пифалы?

Answer 1

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

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

Answer 2

Тщательно обдумайте свои цели. Вы просто заинтересованы в замене фондов COM? Вы также собираетесь изменить реализации баз данных (например, с индексированных на SQL?) Экраны (с GUI на Web?) ...?

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

Для таких масштабных изменений вы можете рассмотреть возможность автоматизации изменений. Инструмент для реализации таких изменений можно найти здесь: DMS Software Reengineering Toolkit . Использование DMS для клиента с 800K SLOC кода C ++, мы реализовали большую часть транслятора с C ++ на C #, который заменил интерфейсы COM эквивалентными средствами C # (управление птичьей клеткой, тасовавшее примерно 3/4 пути через проект, потеряло интерес к транслятору, несмотря на его почти полноту).

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

Answer 3

Michael Feathers: Эффективная работа с унаследованным кодом представляет ряд методов для работы с устаревшим кодом и его замены. Я нашел это вполне читабельным; некоторые методы (и многие из хаков) были новыми для меня.

Answer 4

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

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

Answer 5

В настоящее время я делаю почти такую ​​же вещь.

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

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

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

Answer 6

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