Меню

Рефакторинг коду: що потрібно про це знати

code refactoring what you need know about it

Спробуйте Наш Інструмент Для Усунення Проблем

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

Термін «рефакторинг» в основному використовується для позначення необхідного очищення / переробки коду.

У цьому посібнику ми розберемося з визначенням рефакторингу, обговоримо необхідність рефакторингу коду та розглянемо вплив коду рефакторингу на різних членів команди проекту. Ми також обговоримо відповідь на найважливіше питання - Як випробовувач, чому ви повинні знати про рефакторинг?

Крім того, ми також обговоримо декілька тематичних досліджень для уточнення концепції.

Рефакторинг коду

Що ви дізнаєтесь:

Вступ до рефакторингу

Для початку давайте спочатку зрозуміємо, що таке насправді рефакторинг.

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

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

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

Якщо ми зберігаємо оригінальну функціональність програми або модуля, виникає запитання: Чому ми взагалі турбуємось рефакторингом? Ну, є безліч причин, за якими певний модуль або фрагмент коду може бути необхідним для реконструкції, наприклад:

  1. Код пахне
  2. Технічний борг
  3. Швидкий підхід до розробки програмного забезпечення тощо.

Ми детально обговоримо ці моменти в наступних розділах.

# 1) Запах коду:

Ми всі можемо зрозуміти, що коли їжа починає пахнути, це вказує на те, що вона, швидше за все, стає поганою - це стосується і коду! Запахи коду вказують на те, що в коді може існувати набагато серйозна проблема.

Нижче наведено деякі загальні запахи коду:

  • Наявність надлишкового або ідентичного коду.
  • Оголошена змінна, яка не використовується ніде в решті коду.
  • Надскладний дизайн коду.
  • Клас коду, який робить занадто мало і не виправдовує існування визначеного класу. Такі класи відомі як ледачий клас або халява.
  • Існує занадто багато умов та циклів, які можуть бути розбиті та спрощені.
  • Код побудований таким чином, що зміна однієї частини коду вимагає впровадження змін і в інших місцях.

Запахи коду стають більш очевидними з часом. У міру зростання додатків або систем, з часом ці запахи коду починають впливати на розробку, обслуговування коду та навіть продуктивність системи в екстремальних сценаріях.

# 2) Технічний борг:

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

Розглянемо функцію, яку потрібно додати до існуючого модуля. Після обговорення команда звужує 2 підходи, щоб додати цю функцію. Підхід А, який вимагає 2 спринтів, буде затвердженим довгостроковим підходом. Підхід B займає лише 5 днів, щоб забезпечити безладний жорстко закодований хак, який призначений просто обслуговувати модуль у короткий термін.

Якщо на команду чиниться тиск, щоб вона надала функцію протягом обмеженого часу, тоді вона може погодитися дотримуватися підходу B поки що та додати підхід A у відставанні на майбутнє. Роблячи це, ця команда просто створила собі технічний борг.

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

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

Читати далі=> Що таке Технічний відділ

# 3) Дотримуючись гнучкого підходу до розробки програмного забезпечення:

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

Ці відносини зображені на діаграмі нижче

Швидкий підхід до розробки програмного забезпечення

Рекомендуємо прочитати => Найкращі засоби аналізу коду

Чому перевірка якості повинна знати про рефакторинг?

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

Тоді, чому ми обговорюємо цю не пов’язану концепцію в Довідковому співтоваристві тестування програмного забезпечення? Продовжуйте читати решту цього посібника, щоб отримати відповідь на це питання.

# 1) Для Unit Testers / Developers

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

# 2) Для тестувальників

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

  • Як тестер, рефакторинг коду приблизно означає: поглиблене тестування + регресійне тестування. Поглиблене тестування повинно включати всі існуючі потоки користувачів, щоб гарантувати, що всі функціональні можливості працюють як раніше. Регресійне тестування всієї програми (або постраждалих областей) необхідний для того, щоб оновлення модуля ненавмисно не порушило функціональність інших модулів.
  • Тести прийняття користувачами будуть важливими, і ці тести потрібно пройти, перш ніж збірку можна буде оголосити готовою до випуску.
  • Крім того, будь-який інший необхідний тест, такий як навантаження, тест безпеки тощо також потрібно буде впроваджувати за необхідності.

# 3) Інженери-автоматизатори

Рефакторинг коду може спричинити збій функціональних та нефункціональних сценаріїв автоматизації.

Це може статися з таких причин:

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

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

Будучи розробником тестів автоматизації, інженерам тестів автоматизації також потрібно думати як розробник і прагнути створити чистий і простий в обслуговуванні код. Більшість IDE, такі як IntelliJ IDEA, Eclipse тощо, включають вбудоване меню рефакторингу із загальновживаними методами рефакторингу для зручності.

Нижче скріншот меню рефакторингу в IntelliJ IDEA (Community Edition).

як використовувати сортування в Java - -

меню рефакторингу

# 4) Для тестових потенційних клієнтів / потенційних клієнтів

  • Тестові потенційні клієнти / Потенційні клієнти можуть вимагати співпраці з рештою команди, включаючи розробників, аналітика продуктів та, можливо, навіть зацікавлені сторони, щоб забезпечити ретельне планування тестування для таких проектів.
  • Важливо розуміти існуючі функціональні можливості. Виходячи з існуючих функціональних можливостей, бізнес-кейси, потоки користувачів та тести прийнятності користувачів повинні бути задокументовані. Коли тестується реконструйований код, усі ці сценарії повинні бути перевірені, разом з регресійним тестуванням уражених областей.
  • Будьте ініціативними під час планування тестового підходу та плани випробувань . Якщо ви передбачаєте вимогу до кількох тестових середовищ або нових інструментів для тестування, надішліть заявку достроково, щоб запобігти затримкам після початку етапу тестування.
  • Не соромтеся залучати членів команди, що не є проектом, або кінцевих користувачів для участі у тестуванні.

Тематичні дослідження

Зараз ми обговоримо деякі реальні тематичні дослідження, над якими я мав можливість або безпосередньо працювати, або непрямо робити внески.

Тематичне дослідження №1

Завдання: Рефакторіть модуль для заміни жорстко закодованих значень змінними та додайте коментарі до нового автоматизованого засобу генерації технічної документації.

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

Тестовий підхід :Виконано тестові випадки для модуля, що реконструюється, та відносно відомих уражених ділянок. Будь-які дефекти були повідомлені та усунені до випуску.

Приклад №2

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

Збережена процедура в цьому сценарії була старою збереженою процедурою, яка була розроблена кілька років тому, враховуючи вимогу, згідно з якою додаток використовувало свою збережену процедуру як внутрішню програму з менше 10 одночасними сесіями.

Тепер компанія хотіла продати цю програму як Програмне забезпечення як послугу (SaaS), очікуваний обсяг 300 паралельних сесій спочатку.

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

Деякими проблемами, визначеними за допомогою цієї збереженої процедури, були декілька підзапитів в межах одного запиту, важкі об’єднання з поданнями замість таблиць, використання select * замість вибору конкретного стовпця тощо. Через ці проблеми з кодуванням програма отримувала більше даних, ніж було дійсно необхідним, тим самим спричиняючи уповільнення програми та врешті-решт збій.

Проблеми:

# 1) Керівник проекту / аналітик продуктів

  • Збір вимог - Оскільки ця збережена процедура була застарілим кодом, при її розробці не було жодних документованих вимог. Також для ітерацій, зроблених за останні кілька років, не було журналу змін, щоб вказати ділові правила та логіку, додані або видалені з модуля.
  • Графік проекту - Оскільки вимоги не були чітко визначені, а залежності коду ще не були повністю визначені, складно було повідомити попередній графік.

# 2) Для розробників

  • Відсутність чітких вимог та бізнес-правил.
  • Очищення коду без втрати його функціональних можливостей.
  • Невідомі зони впливу та / або залежності коду.
  • Неможливо надати конкретні оцінки часу розробки.
  • Потрібно створити нові модульні тести.

# 3) Для тестувальників

  • Відсутність чітких вимог та бізнес-правил планування випробувань впливу.
  • Невідомі зони ураження планують випробування впливу, особливо для регресійних випробувань.
  • Неможливо надати конкретні оцінки випробувань.

# 4) Зацікавлені сторони

  • Відсутність чітких документованих вимог та / або потоків користувачів + стислі терміни = Вищий ризик несправності.

Підхід, який дотримується команда для зменшення ризиків та вирішення проблем :

(i) Команда застосовувала спільний підхід для збору вимог : Менеджер проектів / аналітик продуктів та тестувальники тісно співпрацювали з внутрішніми кінцевими користувачами, щоб зрозуміти та задокументувати основну функціональність та потік користувачів.

Розробники також переглянули код та додали відповідну інформацію до документа з вимогами. Це було зроблено перед початком дня спринту.

(ii) Альтернативне тестове середовище було створено для тестування змін, що впроваджуються : Давайте назвемо ці середовища гаммою та фі. Gamma мав би старий код, а Phi - постійно розгорнуту останню реконструйовану збережену процедуру.

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

Команда надала вимоги до альтернативного тестового середовища, яке було надане до дати початку спринту.

(iii) Кінцеві користувачі та зацікавлені сторони, залучені до тестування на ранніх стадіях : Були виявлені будь-які очевидні проблеми, про які повідомлялося рано, надаючи команді більше часу для розгортання та тестування необхідного виправлення.

(iv) Визначення критеріїв виходу та дотримання його: Критерії виходу були визначені на початкових етапах планування - випробувано 80% потоків користувачів, жодна критична помилка не усунена, демонстрація та підпис від зацікавлених сторін перед випуском.

(v) Встановлення попередньої дати випуску: Встановлення випуску дати випуску та мотивація команди працювати до спільної кінцевої точки. Виходячи з обсягу проекту, команда рекомендувала дотримуватися 3-тижневого спринту замість звичайного 2-тижневого спринту, щоб команда мала достатньо часу для виконання проекту.

Висновок

Підводячи підсумок, рефакторинг коду - це процес очищення / спрощення конструкції модуля без зміни його функціональних можливостей. Процес рефакторингу може бути простим, наприклад, додаванням коментарів, додаванням правильних відступів, видаленням статичної змінної тощо, або може бути складним для складних застарілих систем.

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

Для тестувальників рефакторинг коду приблизно означає: поглиблене тестування + тестування регресії.

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

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

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

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

Рекомендована література

^