УДК 621.395

К. э. н., зав. отделением КП СПКБ АСУВ , инженер-программист 2-кат.

Рефакторинг программного кода при решении некоторых организационно-экономических задач

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

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

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

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

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

НЕ нашли? Не то? Что вы ищете?

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

Первые публикации о методах проведения рефакторинга (реорганизации программного кода с сохранением его функциональности) относятся к 90-м годам 20-го века и носят несистематический характер [см. 1, с.377-380]. А первое описание стандартных подходов к проектированию программного обеспечения на английском языке вышло в 1995 году, первый перевод на русский – 2001, см. [3].

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

Начало формализации процессов рефакторинга (наряду с известной формализацией процесса разработки и тестирования, см., например, [4]) свидетельствует о том, что разработка программного обеспечения все более приобретает черты конструкторской деятельности из «стандартных частей». (Косвенным подтверждением сказанного является, на наш взгляд, и то, что слово «конструирование» является главным в названии одной из самых ярких монографий современности, посвященной разработке ПО, см. [5].)

Главной целью выполнения рефакторинга является облегчение процесса дальнейшего внесения изменений в программный код (облегчение программирования для добавления новой функциональности) [1, c.13-14,65-68].

Если рефакторинг выполнен перед добавлением новой функциональности в объеме, достаточном для добавления этой функциональности, то сокращаются объемы тестирования новой функциональности и регрессионного тестирования и, следовательно, сокращается время, необходимое для их проведения [там же, с.378-379, 386-389]. (А, значит, уменьшается и стоимость опытной эксплуатации и стоимость внедрения в промышленную эксплуатацию.)

Следует отметить, что успешное применение рефакторинга, при котором он позволяет снизить стоимость разработки и сопровождения ПО, требует наличия хороших регрессионных тестов. (То есть, рефакторинг снижает объем регрессионного тестирования, но не отменяет его, более того, нуждается в качественном его выполнении первый раз). [2, с. 184;5 ,с.101]

В Специальном проектно-конструкторском бюро АСУ водоснабжением (КП СПКБ АСУВ) в ходе разработки и опытной эксплуатации подсистемы «Учет основных средств» несколько раз успешно выполнялся рефакторинг программного кода и базы данных.

Например, в ходе разработки программный код, ответственный за выполнение расчетов амортизации, был преобразован при помощи типовых решений (паттернов) проектирования «Обертка» и «Стратегия», описанных в [3, c.141,300]. Проведение этого рефакторинга позволило спустя год на стадии опытной эксплуатации сделать механизм расчета автономным от команд пользователя и ввести в программу отчеты «Ведомости движения», необходимость которых выяснилась только в ходе тесного взаимодействия с заказчиком.

В начале опытной эксплуатации был выполнен рефакторинг кода, в ходе которого большинство текстов запросов к базе данных было перенесено в отдельный класс, согласно требованиям паттерна «Обертка» и принципа объектно-ориентированного программирования «выделение ответственного» (Information Expert) [4, с.228].

Этот рефакторинг, совместно с рефакторингом по разделению источников данных на «хранящие данные для отображения» и на «получающие данные из базы данных» и отделение их друг от друга, позволил многократно (с 15 минут до 2-х, без изменения аппаратного обеспечения и объема данных) ускорить работу отчета «Ведомости движения».

Таким образом, практика разработок в КП СПКБ АСУВ подтверждает, что рефакторинг программного кода необходимо проводить перед внесением новой функциональности.

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

Список использованных источников

1. Рефакторинг: улучшение существующего кода. – Пер. с англ. – СПб: Символ-Плюс, 2005. – 432 с., ил.

2. Бек, Кент Экстремальное программирование: разработка через тестирование. Библиотека программиста. СПб: Питер, 2003. – 224 с.: ил.

3. Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб: Питер, 2003. – 368 с.: ил. (Серия «Библиотека программиста»)

4. Ларман, Крэг Применение UML и шаблонов проектирования: введение в объектно-ориентированный анализ, проектирование и унифицированный процесс. 2- е издание.: Пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 624 с.: ил. – Парал. тит. англ.

5. Мейер, Бертран Объектно-ориентированное конструирование программных систем/ Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2005. – 1232 с.: ил.