Прибуток:
- Можливість налаштувати тестову мережу безпеки, яка фіксує поточну поведінку перед рефакторингом
- Можливість вимагати від штучного інтелекту невеликі одноетапні трансформації, що зберігають поведінку, і перевіряти кожен крок
- Здатність ідентифікувати та визначати пріоритетність технічної заборгованості в бізнес-контексті
Рефакторинг покращує внутрішню структуру коду без зміни його зовнішньої поведінки: робить його більш читабельним, простішим і придатнішим для обслуговування. З іншого боку, технічний борг — це компроміс, зроблений заради швидкого вирішення проблеми, який повертається «з відсотками» з часом — кожен кут, який ви зрізаєте сьогодні, завтра повернеться як уповільнення або помилка. Штучний інтелект є потужним помічником, який прискорює повторювані та механічні завдання рефакторингу; Але є одне золоте правило рефакторингу, і штучний інтелект сам по собі не може його гарантувати: поведінка не повинна змінюватися.
У цьому розділі ми навчимося робити безпечний рефакторинг за допомогою штучного інтелекту: невеликі та оборотні кроки, захист за допомогою тестів, виявлення запахів коду та визначення пріоритетів технічної заборгованості. Критичний момент полягає в наступному: проходження тестів, а не слово штучного інтелекту, доводить, що поведінка збережена.
Золоте правило рефакторингу: поведінка залишається незмінною
Що робить рефакторинг небезпечним, так це несвідома зміна поведінки, коли ви говорите «Я вдосконалююся». Відкидання граничного випадку під час спрощення умови, порушення порядку під час перетворення циклу, відсутність побічного ефекту під час розбиття функції — все це призводить до «чистого вигляду», але несправного коду.
Ось чому тестування є обов’язковою умовою рефакторингу: перш ніж змінювати, ви повинні мати тести, які фіксують існуючу поведінку. Ці тести є «сіткою безпеки»; Якщо ви випадково зламаєте щось під час рефакторингу, вони зламатимуть і попередять вас. Якщо у вас немає тестів, спочатку напишіть тести, які виправляють існуючу поведінку (як ми навчилися в блоці 5) — саме тут штучний інтелект починає швидко.
Застереження: рефакторинг за допомогою ШІ без тестової мережі є одним із найпідступніших джерел помилок. Легко сказати «Я зберіг поведінку»; Доказом є те, що ті самі тести проходять до і після зміни.
Крок за кроком: безпечний процес рефакторингу
- Встановіть захисну сітку. Нехай будуть тести, які фіксують поточну поведінку коду, який ви будете рефакторювати; Якщо ні, спочатку запишіть їх (і подивіться, як вони пройдуть).
- Назвіть запах. Що ви покращуєте і чому? «Ця функція робить 3 речі», «та сама логіка повторюється в 4 місцях», «імена вводять в оману».
- Попросіть робити маленькі, однокрокові кроки. Попросіть штучний інтелект виконати одне перетворення (наприклад, просто «розділити цю функцію навпіл»), а не переписувати весь файл.
- Виконайте тести. Після кожного кроку. Якщо він зелений, продовжуйте, якщо він червоний, заберіть його назад.
- Прочитайте різн. Підтверджуйте рядок за рядком, що зміна справді зберігає поведінку; Коли говорити, що штучний інтелект — це «просто структура», може виникнути логічна помилка.
- З'єднати на невеликі шматочки. Великі одноразові рефакторингові PR є ризикованими та неперевіреними.
Три міні-чохли
Випадок 1 — 220-рядкова функція безпечно розділена. Одна команда мала функцію обробки замовлень із 220 рядків. Перші 14 тестів були написані (за допомогою ШІ), які фіксували поточну поведінку, усі вони пройшли. Потім функція була розділена на 5 менших функцій крок за кроком ШІ; Тести проводилися після кожного кроку. Два тести були зламані за один крок — штучний інтелект пропустив віддачу в граничному випадку. Тести це відразу виявили та виправили. Без мережі помилка могла б дійти до виробництва.
Випадок 2 — Катастрофа без тестової мережі. Інший розробник «підчистив» модуль обчислення дати, який не мав тестів з ШІ. Код виглядав краще, але обчислював високосний рік неправильно; Помилка з’явилася через два тижні зі скаргою клієнта. Втрати значно перевищили час, заощаджений на рефакторингу. Урок: рефакторинг без тестування — азартна гра.
Випадок 3 — Пріоритезація технічного боргу. Одна команда дала штучному інтелекту відставання приблизно в 30 «покращих» балів і оцінила кожен з них за віссю «частота змін × ризик × зусилля». У отриманій таблиці потворний модуль, який рідко торкався, насправді мав низький пріоритет, тоді як модуль середньої складності, який часто змінювався, мав високий пріоритет. Команда спрямувала свою енергію куди потрібно.
Чотири шаблони, які можна копіювати
Виявлення запаху коду та пріоритезація:
Список кандидатів на рефакторинг «пахне» в цьому коді: довга функція, повтор (DRYViolation), оманлива назва, глибоко вкладена умова, прихований побічний ефект, магічне число. Для кожного: місце розташування, причина проблеми, рекомендований малий крок, оцінений ризик (низький/середній/високий). НЕ ЗМІНЮЙТЕ код, просто плануйте.{{code}}
Одноетапна трансформація, що зберігає поведінку:
ПРОСТО зробіть це: {{одиничне перетворення, напр. Розділіть цю функцію на 3 менші функції з назвами}}. ЗМІНИТИ видиму поведінку, підпис і значення, що повертаються. Напишіть одним реченням, чому все, що ви змінили, зберігає поведінку.{{code}}
Мережа безпеки перед рефакторингом (тестування характеристик):
Напишіть тести, які фіксують ПОТОЧНУ поведінку цієї функції (правильну чи ні); Мета полягає в тому, щоб виявити, чи змінюється поведінка під час рефакторингу. Включіть типові записи + краї. Напишіть очікування на основі поточного результату функції.{{function}}
Генерація запису технічної заборгованості (бэклог):
Додайте наступний список запахів до таблиці пріоритетів: речовина, зона впливу, частота зміни (мої відомості: {{...}}), ризик, передбачувані зусилля, рекомендований пріоритет. Помістіть сильні удари + низькі зусилля вгору. {{smell_list}}
Слабка підказка / Сильна підказка
Слабкий: «Очистіть цей код і покращте його».
Сильно: «Розділіть цю 90-рядкову функцію на 3 менші функції з єдиною відповідальністю, не змінюючи її зовнішню поведінку та підпис. Зберігайте побічні ефекти (записи в БД) у поточному порядку. У мене є тести, поведінка має залишатися незмінною. Укажіть різницю та поясніть одним реченням, чому кожне розділення зберігає поведінку. [код]»
Потужна версія; Він вимагає єдиного конкретного перетворення, явно накладає обмеження поведінки та підпису та вимагає обґрунтування. Розпливчасті запити на кшталт «зробіть краще» призводять до неконтрольованих і ризикованих змін.
Тип рефакторинга
Надійність ШІ
Передумова
перейменувати
висока
Чи правильний обсяг?
Поділ функцій
середньо-високий
Testnet є обов'язковим
Спільне повторення
середній
Різниця в поведінці може бути прихованою
Зміна алгоритму/структури
низький
Широке тестування + перевірка людьми
Архітектурна перепланування
низький
Керується людиною, підтримується ШІ
Управління технічним боргом, а не його відновлення
Технічна заборгованість — це не все погано; Іноді усвідомлене запозичення (достроково) є правильним рішенням. Мета полягає не в ліквідації боргу, а в тому, щоб зробити його видимим і керованим. Штучний інтелект швидко виявляє борги та визначає їх пріоритети, але для прийняття рішення, «який борг потрібно сплатити, а який — відмовитися», потрібен бізнес-контекст: як часто змінюється цей модуль, на скільки людей він впливає, який ризик? Це рішення приймається командою, яка знає базу коду та продукт; AI лише уточнює варіанти.
Порада: тримайте свій рефакторинг PR окремо від PR, які передбачають зміну поведінки. Можливість сказати, що «цей PR – це просто рефакторинг, поведінка та сама» полегшує розслідування та дозволяє швидко звузити причину, якщо виникне проблема.
Поширені помилки
- Рефакторинг без тестової мережі. Вам не залишається нічого, щоб довести, що поведінка збереглася.
- Це означає «очистити весь файл». Великі, неконтрольовані зміни приховують помилку і не можуть бути перевірені.
- Прийняття Diff без його читання. Можливо, штучний інтелект дещо втратив логіку, коли сказав «просто структура».
- Плутання рефакторингу зі зміною поведінки. Виконання обох в одному PR унеможливлює відстеження першопричини.
- Намагається виправити кожен запах. Потворний код, який рідко змінюється, часто має низький пріоритет; Виділіть енергію тому місцю, яке часто змінюється.
Підсумовуючи
Єдине правило рефакторинга полягає в тому, що поведінка залишається незмінною, і доказом цього є тести. AI потужний у виявленні запахів коду, одноетапних перетвореннях і визначенні пріоритетів технічної заборгованості; але ви повинні налаштувати мережу безпеки, запустити тести та читати різницю після кожного кроку. Робіть маленькі оборотні кроки; відрізняти рефакторинг від зміни поведінки; і нехай команда, яка знає бізнес-контекст, вирішить, який борг сплатити.
Аплікаційне завдання
Виберіть функцію зі свого коду, яка здається вам довгою або складною. Перші тести друку, які фіксують його поточну поведінку за допомогою шаблону "захисної сітки", і перевіряють, чи всі вони пройдуть. Потім відрефакторіть функцію одним способом (наприклад, розділивши навпіл) за шаблоном «однокрокове перетворення, що зберігає поведінку», і знову запустіть тести. Якщо тест зламався, дізнайтеся, чому; Якщо він взагалі не порушується, прочитайте різницю рядок за рядком, щоб переконатися, що поведінка справді збережена.
контрольний список
- [ ] Я знаю, що рефакторинг не повинен змінювати поведінку, і є тести, які це підтверджують.
- [ ] Я встановлюю мережу безпеки, яка фіксує поточну поведінку перед рефакторингом.
- [ ] Мені потрібні невеликі одноразові трансформації від ШІ, а не великі.
- [ ] Після кожного кроку я запускаю тести та читаю різницю.
- [ ] Я продовжую рефакторинг PR окремо від PR зі зміною поведінки.
- [ ] Я встановлюю пріоритет технічного боргу з бізнес-контекстом, а не намагаюся сліпо обнулити його.