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

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

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

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

РЕДАКТИРОВАТЬ: Предложения на данный момент: рефакторинг старого кода, создание нового кода в качестве контейнера для модулей и охват старого и нового кода в модульных тестах - все это в целом хорошие практики и вещи По возможности практикуюсь. Мне кажется, что это были бы отдельные части общей методологии.


integration legacy-code
person Aaron Thomas    schedule 08.05.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Прежде всего, вам нужно понять, как старое приложение работает изнутри. Как он управляет рабочим процессом, сеансами, привилегиями пользователей и т. Д.

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

person Erich Kitzmueller    schedule 22.06.2009

arrow_upward
0
arrow_downward

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

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

person alphazero    schedule 09.05.2009

arrow_upward
0
arrow_downward

Фаулер рекомендует провести рефакторинг старого кода. Это займет некоторое время, но:

А) будет проще интегрировать этот код с вашим новым кодом;

Б) вы и ваша команда лучше поймете старый код.

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

person Roman    schedule 09.05.2009