Рефакторинг
Рефакторинг (англ. refactoring) — перетворення програмного коду, зміна внутрішньої структури програмного забезпечення для полегшення розуміння коду і легшого внесення подальших змін без зміни зовнішньої поведінки самої системи[1]. Слово «рефакторинг» пішло від терміну «факторинг» в структурному програмуванні, який означав декомпозицію програми на максимально автономні та елементарні частини.
Зміст |
[ред.] Причини рефакторингу
Існує міф про те, що правильно організований процес розробки продукту методично дотримується поставлених вимог, визначає однозначний, стабільний список обов’язків програми, і при цьому програмний код може бути написаний майже лінійно — від початку до закінчення, кожна ділянка — один раз написана, відтестована і забута. Згідно з цим міфом, єдиний випадок, коли наявний код може змінюватись, — це в процесі підтримки і адміністрування програми, коли початкова версія продукту уже здана замовнику.
Однак реальність є дещо інакшою. Насправді код еволюціонує в процесі розробки продукту. Як правило, кодування, відлагодження та модульне тестування займають в середньому 30–65% зусиль від загального часу існування проекту (залежно від величини проекту). Навіть на добре організованих проектах вимоги змінюються в середньому на 1–4% за місяць, що неминуче спричиняє зміни до програмного коду — як дрібні, так і досить серйозні.[2]
Також, на відміну від старіших методик розробки програмних продуктів, де основний акцент ставився на мінімізації змін до коду, сучасна методика вбачає великий потенціал у внесенні змін. Вона є більш сфокусованою на коді (code-centered) і під час розробки можна очікувати, що код буде вдосконалюватися більше, ніж зазвичай.
[ред.] Підстави для проведення рефакторингу
- Код дублюється.
- Це нерідко призводить до необхідності вносити паралельні зміни до кількох скопійованих ділянок коду одночасно (що не відповідає принципам «DRY» (Don’t Repeat Yourself) та «Copy And Paste is a Design Error»).
- Підпрограма занадто довга.
- Хоча питання, яку максимальну довжину може мати підпрограма, є досить суперечливим, однак загальноприйнятим неофіційним стандартом є написання підпрограм довжиною не більше, ніж один екран коду.
- Цикл занадто довгий, або рівень вкладеності тіла циклу занадто великий.
- Клас має багато обов’язків, слабо пов’язаних між собою.
- В такому випадку краще розділити клас на кілька атомарних класів.
- Інтерфейс класу не забезпечує достатній рівень абстракції.
- Функція має занадто багато параметрів.
- Потрібно одночасно змінювати кілька паралельних ієрархій класів.
- Для вирішення цієї проблеми можна, наприклад, скористатися шаблоном «Міст».
- Споріднені дані, які використовуються разом, не організовані в клас.
- Клас не виконує ніяку роботу самостійно, а тільки передоручає обов’язки іншим класам.
- Назва класу чи методу має ім’я, яке недостатньо точно відповідає змісту.
- Клас має занадто багато відкритих (public) членів.
- Нестатичний клас складається тільки з даних або тільки з методів.
- В ланцюжку викликів методів передається багато зайвих даних.
- Занадто поширене використання глобальних змінних.
[ред.] Прийоми рефакторингу
- Прийоми, що дозволяють розбити код на дрібніші, зрозуміліші частини.
- Відокремлення методу (Extract Method).
- Відокремлення базового класу (Extract Superclass).
- Прийоми, що дозволяють забезпечити додаткову абстракцію.
- Інкапсуляція поля (Encapsulate Field) — замінює прямий доступ до поля на доступ через методи-аксесори (або властивості в C#).
- Узагальнення типу (Generalize Type) — заміна типів, з якими працює клас, на більш узагальнені.
- Заміна блоків перевірки типів на шаблони «Стан» (State) або «Стратегія» (Strategy).
- Заміна умовних операторів поліморфізмом.
- Створення поля або локальної змінної (Introduce Field/Introduce Local Variable).
- Прийоми, що змінюють назви членів та їх розташування.
- Переміщення методу/поля (Move Method/Field) в інші класи або файли коду.
- Перейменування члена (Rename) — зміна імені, з автоматичною заміною всіх посилань на старе ім’я в коді.
- Переміщення члену до базового/дочірнього класу (Pull Up/Push Down).
[ред.] Автоматизований рефакторинг
На сьогоднішній день багато інтегрованих середовищ розробки містять вбудовані механізми рефакторингу коду. Крім інтегрованої функціональності, існує також багато продуктів сторонніх виробників, які, як правило, реалізовані у вигляді додатків (plugins) до відповідного IDE. Приклади таких пакетів:
| Пакет | Мова | Середовище |
|---|---|---|
| Microsoft Visual Studio | C# | Microsoft Visual Studio (вбудований) |
| Java Development Tooklit | Java | Eclipse (вбудований) |
| IntelliJ IDEA | Java | IntelliJ IDEA (вбудований) |
| NetBeans | Java | NetBeans (вбудований) |
| Visual Assist | C#, C++, VB, VB.NET | Microsoft Visual Studio |
| Photran | Fortran | Eclipse |
