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