РЕФАКТОРИНГ, РЕИНЖИНИРИНГ И ОПТИМИЗАЦИЯ

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

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

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

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

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

Если рефакторинг кода не меняет поведения программы, то реинжиниринг на такое способен.

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

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

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

Основные проблемы, которые следует исправить в процессе рефакторинга кода.

1. Повторяющийся код.

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

2. Длинный метод (процедура).

Длинные методы (процедуры) сложны для понимания и сопровождения, так что есть смысл в их упрощении и уменьшении.

В 99% случаев применяется извлечение метода (разбиение на несколько процедур).

3. Большой класс.

Когда класс пытается отвечать за все, вылезает огромное количество его экземпляров, а отсюда недалеко и до повторяющегося кода.

Решение – извлечение класса.

4. Длинный список параметров.

Длинные списки параметров неудобны в обращении: их трудно понимать и их постоянно приходится менять при смене информации, которая нужна методу (процедуре).

5. Различное изменение класса.

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

6. Зависть к чужим членам.

Если метод заинтересован в членах класса, отличного от того, к которому он принадлежит гораздо больше, чем в членах своего класса. Тогда перемещение метода – очевидное решение.

7. Пучки данных.

Данные нередко группируются вместе: то некоторый набор данных возникает как поля класса, то как параметры метода. Такой набор имеет смысл выделить в отдельный объект с помощью извлечения класса.

8. Операторы выбора.

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

9. Параллельные иерархии наследования.

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

10. Ленивый класс (процедура).

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

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

11. Спекулятивная общность.

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

12. Цепочки вызовов.

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

13. Промежуточный сервер.

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

14. Неполная библиотека.

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

15. Класс данных.

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

Надо применить инкапсулирование поля. Если есть коллекция, надо проверить правильность ее инкапсулирования.

16. Отказ от наследства.

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

Контрольные вопросы

1. Дайте определение понятия «рефакторинг программного кода».

2. Охарактеризуйте рефакторинг программного кода.

3. Какие проблемы необходимо исправить в процессе рефакторинга?

4. Дайте определение понятия «реинжиниринг программного кода».

5. Охарактеризуйте реинжиниринг программного кода. В чем его отличие от рефакторинга?

6. Дайте определение понятия «оптимизация программного кода».

7. Охарактеризуйте процесс оптимизации программного кода. Взаимосвязь рефакторинга и оптимизации.