Обновление документации

Унаследованные приложения

Рефакторинг

Часто усовершенствование программы требует не просто изменения отдельных строк кода, а приложения гораздо больших усилий, не достигающих, однако, мас­штабов полного реинжиниринга. Иногда этот процесс называют рефакторингом (refactoring). Фаулер рассматривает пример проекта для магазина видео­фильмов – этот проект не слишком хорош, но вполне пригоден для конкретной простой задачи. Затем он показывает, как можно переделать проект под новые требования, например добавить возможность формирования новых типов отче­тов. Этот процесс включает экстракцию метода (то есть создание метода, заме­няющего имеющийся фрагмент кода).

Унаследованные системы (legacy systems) – это приложения, решающие сущест­вующие задачи. Иногда термин legacy трактуется как устаревшие и применяется к программам, которые не стоят того, чтобы их модифицировать.

Беннетт перечисляет возможные действия с унаследованными системами.

♦ Продолжать сопровождение;

♦ Прекратить сопровождение и:

♦ заменить на покупной продукт;

♦ заменить на собственный продукт, полученный обратным проектирова­нием или разработкой с нуля. Возможна поэтапная замена;

♦ присоединить к новому приложению. Сопровождение заморозить;

♦ инкапсулировать и использовать как сервер.

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

При инкапсуляции исходное приложение практически не изменяется. Новое приложение создается полностью независимо, а в процессе его выполнения вы­зывается функциональность унаследованного приложения. Это может осуществ­ляться как напрямую (метка ed), так и через обертку (метка ew). Обертка – это программное обеспечение, предоставляющее интерфейс для обращения клиен­тов к унаследованному приложению. В частности, обертка может сделать любое приложение внешне объектно-ориентированным.

Рис. 2.6.Использование унаследованных приложений

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