Що таке рефакторинг коду і чому він важливий для тестувальників

Рефакторинг коду – це процес, який передбачає редагування та очищення раніше написаного програмного коду без зміни його функцій.

Основна мета – зробити код більш ефективним і зручним для обслуговування, уникнути його «псування», а саме дублювання коду, незліченних виправлень тощо. Також погіршення якості коду може відбуватись через те, що кожен розробник має власний стиль написання.

Основні техніки і правила рефакторингу

Red-Green-Refactor

Ця техніка найбільш популярна та використовується у Agile-розробці, яка керується тестуванням.

Основні етапи:

1. Зупинитися і розглянути, що потрібно розробити. [RED].
2. Забезпечити проходження базового тестування. [GREEN]
3. Впровадити поліпшення. [REFACTOR]

Рефакторинг шляхом абстрагування

Цей метод найкраще підходить для рефакторингу у великих обсягах. Цей метод допомагає зменшити надлишковий код у роботі шляхом вилучення підкласів, згортання ієрархії тощо.

• Pull-Up/Push-Down. Цей метод розбиває клас на два, один з яких прив’язаний до суперкласу, а інший – до підкласу;
• Pull-Up метод збирає частини коду в суперклас і допомагає усунути дублювання коду;
• Push-Down метод бере частину коду з суперкласу та переміщує його вниз у підкласи.

Метод композиції

На етапі розробки розробники часто пишуть довгі методи, які дуже важко змінити. Компонування передбачає впорядкування коду з метою зменшення дублювання. Це робиться за допомогою різних процесів, до яких належить екстракція та вбудований рефакторинг.

Спрощуючий метод

Важливо позбутися старого коду та спростити логіку. Одним із таких способів є консолідація умовних виразів і методів.

Переміщення властивостей між об'єктами

Ця техніка створює нові класи та безпечно переміщує функціональність між старими та новими класами.

Підготовчий рефакторинг

Цей метод має місце коли розробник помічає необхідність рефакторингу під час додавання нової функції. Фактично це частина оновлення програмного забезпечення, а не окремий процес рефакторингу.

Як рефакторинг коду впливає на роботу тестувальника?

Розглянемо це питання на прикладі мануального тестувальника та автоматизатора.

Оскільки основна логіка ПЗ залишається незмінною, задачами мануального тестувальника після рефакторингу будуть:

• поглиблене тестування (тестування ПЗ як кінцевий користувач продукту);
• регресійне тестування (перевірка того, що оновлення нічого не зламало та не змінило).

Для автоматизаторів справа буде трішки складнішою, оскільки рефакторинг часто призводить до того, що скрипти (автоматизовані сценарії) перестають працювати. Причиною цього є:

• зміна положення об'єктів на сторінках, ідентифікатори яких було зафіксовано у тестових перевірках Selenium. При повторному «прогоні» будуть виникати помилки;
• виконані технічні зміни, які були перенесені у версію після рефакторингу.

Переваги та недоліки рефакторингу

Рефакторинг коду означає своєрідний апгрейд програмного забезпечення, перевагами якого є: 

1. Спрощення підтримки та оновлення коду. Чистий код набагато простіше оновлювати і покращувати. 
2. Заощадження часу та коштів у майбутньому. Тобто шанс появи помилок буде мінімальним, а впровадження нового функціоналу буде простішим та без тривалого розбору коду. Новим співробітникам у команді буде набагато простіше працювати з кодом.
3. Легкість обслуговування та масштабованості. Уявіть себе на місці розробника, якому потрібно внести зміни в «брудний» код. Є велика ймовірність того, що ви не будете знати, до чого може призвести та чи інша його модифікація. Усунення цієї проблеми є однією з переваг рефакторингу коду.

Погодьтеся, набагато краще почистити код зараз, ніж потім платити за дорогі помилки. 

Саме тому рефакторинг коду відбувається на регулярній основі.

Коли потрібно робити рефакторинг коду? Краще всього робити це перед додаванням будь-яких оновлень або нових функцій до існуючого коду. Це не тільки поліпшить якість самого продукту, але і полегшить майбутнім розробникам роботу з вихідним кодом.

Правило Трьох:

1. Коли ви робите щось вперше, ви просто це робите.
2. Другого разу вам не подобається необхідність повторення, але все-таки повторюєте те саме.
3. Коли ви робите щось схоже втретє, ви починаєте рефакторинг.

Переваги рефакторингу ми вже обговорили. Як щодо недоліків?

1. Неточний рефакторинг може викликати нові баги та помилки в коді.
2. Немає чіткого визначення «охайного коду».
3. Покращений код часто важко розпізнати клієнту, оскільки функціональність залишається незмінною, тобто переваги не є самоочевидними.

Підводячи підсумок, перестаратися з рефакторингом так само погано, як і не робити його взагалі. Варто знайти золоту середину і виділити декілька днів чи годин для рефакторингу на початку спринту або в його кінці. Вплив такого інкрементного рефакторингу приємно здивує.