Рефакторинг — це послідовна зміна внутрішньої структури програми без зміни її зовнішньої поведінки. Мета проста: зробити код зрозумілішим, підтримуваним та готовим до розвитку. Зазвичай це ряд невеликих еквівалентних перетворень, кожне з яких зберігає функціональність. Такі кроки легко контролювати, а в сукупності вони помітно покращують архітектуру та читабельність проекту.
Цілі рефакторингу
Головне завдання — полегшити розуміння коду. Якщо після роботи над структурою код залишається заплутаним, мета не досягнута. Важливо чітко відрізняти рефакторинг від інших завдань: оптимізація продуктивності може прискорювати програму, але часто робить код складнішим, тоді як рефакторинг прагне до простоти та прозорості. Рефакторинг також відрізняється від реінжинірингу, який зазвичай додає або переобладнує функціональність; іноді рефакторинг готує код до таких масштабних змін.
Причини застосування рефакторингу
Типові мотиви для рефакторингу включають наступні випадки:
- потреба додати нову функціональність, яку поточна архітектура погано підтримує;
- складні або приховані помилки, причини яких важко виявити;
- труднощі у командній роботі через заплутану логіку коду.
Рефакторинг допомагає адаптувати структуру під нові вимоги, виявити та спростити проблемні місця і зробити спільну роботу менш болісною.
Ознаки поганого коду (Code Smells)
Існує ряд очевидних симптомів, які зазвичай вказують на необхідність рефакторингу:
- дублювання коду;
- довгий метод;
- великий клас;
- довгий список параметрів;
- «жадібні» функції;
- зайві тимчасові змінні;
- класи даних;
- незгруповані дані.
Ці «запахи» не завжди означають термінову проблему, але часто ускладнюють підтримку та розвиток системи.
Процес рефакторингу коду
Рефакторинг передбачає зміну коду без зміни його поведінки. У гнучких методологіях розробки він вбудований у цикл: нові тести та функціональність чергуються з рефакторингом для підтримки читабельності та логічності. Автоматизовані юніт-тести тут виступають страховкою — вони підтверджують, що зміни не зламали існуючу поведінку.
Рефакторинг не призначений для виправлення помилок або додавання функціональності в рамках одного кроку; він готує код, щоб подальші зміни були простішими та безпечнішими. Часто це переміщення поля між класами, виділення фрагмента у окремий метод або перестановка частин коду за ієрархією. Кожна дія може здаватися тривіальною, але у сукупності вони суттєво покращують проект.
Методи рефакторингу
Нижче перелічено поширені прийоми, які далі розглядаються детальніше:
- зміна сигнатури методу;
- інкапсуляція поля;
- виділення методу;
- переміщення методу;
- заміна умовного оператора поліморфізмом;
- виділення класу;
- виділення інтерфейсу;
- вбудовування;
- введення фабрики;
- підйом методу;
- спуск методу;
- перейменування методу;
- заміна успадкування делегуванням;
- заміна коду типу підкласами.
Детальний розгляд деяких методів
Зміна сигнатури методу
Суть методу — змінити набір параметрів: додати, видалити або змінити типи. Після цього потрібно оновити всі виклики методу. Іноді такі зміни зачіпають зовнішній інтерфейс, і за відсутності доступу до зовнішніх клієнтів потрібна формальна координація та випуск нової версії.
Інкапсуляція поля
Якщо поле публічне, його роблять приватним і вводять методи доступу. Це дає контроль над доступом і змінами даних і часто поєднується з переміщенням методів для кращої організаційної структури.
Виділення методу
Коли фрагмент методу занадто довгий або потребує пояснення, його виносять у окремий метод, а на місці залишають виклик. Правило зручності: метод не повинен займати більше одного екрану — якщо займає, частину логіки, ймовірно, варто виділити.
Переміщення методу
Якщо метод частіше працює з даними іншого класу, його переміщують туди. Це покращує зв'язність і зменшує зчеплення між компонентами.
Заміна умовного оператора поліморфізмом
Коли в коді є великий умовний оператор з багатьма гілками, його можна замінити ієрархією: базовий клас та підкласи, кожен реалізує свою гілку. Тоді вибір реалізації відбувається поліморфно, без громіздких умов. Цей прийом близький до шаблонів «Стратегія» або «Стан».
Основні кроки:
- Створити базовий клас і потрібну кількість підкласів.
- За потреби виділити метод із частини умовного оператора.
- Перемістити умовний оператор на вершину ієрархії, якщо це потрібно.
- У кожному підкласі реалізувати поліморфний метод, що відповідає гілці.
- Замість вихідного умовного оператора викликати поліморфний метод.
Переваги рефакторингу
Регулярний рефакторинг приносить проекту та команді відчутні переваги:
- покращення читабельності коду;
- спрощення підтримки;
- спрощення додавання нової функціональності;
- зменшення кількості помилок;
- підвищення продуктивності команди;
- покращення дизайну програмного забезпечення.
Ці ефекти зменшують витрати часу на рутинну роботу та підвищують стійкість системи до змін.
Коли слід і не слід проводити рефакторинг
Рефакторинг — корисний інструмент, але застосовувати його потрібно усвідомлено.
Коли слід рефакторити
Підстави для рефакторингу:
- перед додаванням нової функціональності, якщо поточна структура заважає;
- під час пошуку причин помилок, коли логіка неочевидна;
- під час огляду коду під час виявлення «запахів»;
- постійно, маленькими кроками, інтегруючи рефакторинг у робочий процес.
Коли не слід рефакторити
Приклади ситуацій, коли рефакторинг краще відкласти:
- коли код не працює і потрібні виправлення функціональності;
- коли немає надійних автоматичних тестів;
- за умов суворих строків, якщо це критично для релізу;
- коли ділянка коду скоро буде видалена або замінена.
Рефакторинг і тестування
Надійний набір тестів — основа безпечного рефакторингу. Тести підтверджують, що зміни не змінили зовнішньої поведінки системи. Без автоматизованих тестів рефакторинг стає ризикованим. Часто розробники працюють за схемою: написати тест, зробити код, що проходить тест, потім рефакторинг, підтримуючи проходження тестів.
Проблеми, що виникають під час проведення рефакторингу
Часті труднощі під час рефакторингу:
- зміни в базі даних, що потребують синхронізації схеми;
- зміни публічних інтерфейсів із великою кількістю залежностей;
- складність під час переработки фундаментального дизайну системи.
Для рефакторингу баз даних та великих архітектурних змін потрібні спеціальні підходи та обережне планування.
Засоби автоматизації рефакторингу
Сучасні IDE пропонують інструменти, які автоматизують багато рефакторингових операцій. Це прискорює і робить процес безпечнішим. Технічні критерії для таких інструментів включають:
Технічні критерії для інструментів:
- доступ до метаданих програми;
- наявність дерев синтаксичного розбору;
- точність внесених змін.
Практичні критерії для інструментів:
- швидкість виконання операцій;
- можливість легко скасувати зміни;
- інтеграція з системами контролю версій та тестування.
