Прибуток:
- Можливість використовувати ШІ як друге око в перевірці коду для читабельності, логіки та безпеки
- Можливість планувати етапи рефакторингу з підтримкою ШІ, не порушуючи поведінку складного коду
- Можливість перевірки огляду ШІ та рекомендацій редагування за допомогою тестування та порівняння контролю версій
У розробці програмного забезпечення код набагато більше читається, ніж пишеться. Рядок коду пишеться один раз, але читається, змінюється та добудовується десятки разів протягом місяців. Ось чому перевірка коду (перевірка чужого або вашого власного коду на логіку, читабельність і безпеку) і рефакторинг (покращення структури коду без зміни його поведінки) є основою розробки. Штучний інтелект стає потужним «другим оком» для цих двох завдань: він швидко пропонує читабельність, вказує на проблеми з логікою та безпекою, а також розбиває великий рефакторинг на менші безпечні кроки. Але є критичне правило: рефакторинг не повинен змінювати поведінку, і єдине, що гарантує це, це тестування.
У цьому розділі ми побачимо, як структуровано використовувати штучний інтелект для перевірки коду, як виправити складний код, не порушуючи його поведінку, і як керувати технічним боргом (швидкі, але дорогі рішення щодо коду).
Концепції: Технічний борг: рішення, прийняті сьогодні, кодують швидкість, що ускладнює обслуговування в майбутньому. Запах коду: Шаблони, які самі по собі не є помилками, але вказують на проблеми (занадто довгі функції, код, що повторюється). Регресія: коли зміна порушує те, що раніше працювало.
Використання ШІ в аналізі структурованого коду
Коли час обмежений, необхідно зосередитися на проблемах з найбільшим ризиком. Автоматичний форматувальник вирішує такі проблеми форматування, як відступи та інтервали; Ви повинні приділяти людську увагу логіці, безпеці та поведінці крайніх випадків. Під час огляду штучного інтелекту попросіть список пріоритетів, а не звичайний шквал відгуків.
- Дайте розмах. Який код, що робити, у якому контексті він працює.
- Вкажіть вісь пріоритету. По-перше, точність і безпека, а потім читабельність.
- Попросіть конкретну корекцію. «Чому проблема» та «рекомендоване вирішення» для кожного результату.
- Ви перевіряєте висновки. ШІ також створює помилкові спрацьовування; Перевірте кожен висновок за кодом і тестуванням.
Структурована підказка для перегляду: «Вивчіть наступну функцію як старший інженер. Перелічіть висновки в порядку важливості та позначте їх такими тегами: [КРИТИЧНА] логіка/безпека, [СЕРЕДНИЙ] периферійний випадок/продуктивність, [НИЗЬКА] читабельність/назва. Для кожного висновку: навіщо запитувати, конкретна пропозиція щодо виправлення. НЕ ПРОПУСТИТИ проблеми форматування/відступів, автоматичний інструмент вирішить це. Код: [код]"
Запит на перевірку, орієнтований на безпеку: «Перегляньте цей код лише з міркувань безпеки: відсутність перевірки введених даних, ризик ін’єкції, відсутність контролю авторизації, витік конфіденційної інформації, незахищені параметри за замовчуванням. Додайте приклад сценарію атаки до кожного результату. Якщо проблеми з безпекою немає, чітко вкажіть «Я не знайшов критичних проблем безпеки». Код: [код]»
Застереження: те, що штучний інтелект говорить «немає проблем», не є доказом того, що проблеми немає. ШІ може створювати помилкові негативи; може обійти реальну проблему безпеки. Огляд штучного інтелекту доповнює, а не замінює перевірку людьми та тестування безпеки. У критичному для безпеки коді останнє слово залишається за компетентним інженером.
Рефакторинг із збереженням тесту
Золоте правило рефакторингу: спочатку тестуйте, потім змінюйте. Перш ніж виправляти код, повинні бути тести, які блокують поточну поведінку, щоб ви одразу знали, чи зміни щось порушують. Не порушуйте порядок під час штучного інтелекту.
- Перевірте поточну поведінку. В іншому випадку попросіть ШІ провести «тест характеристики» (тест, який фіксує поточну поведінку як вона є).
- Виправляйте це невеликими кроками. Тестування має залишатися зеленим на кожному кроці.
- Запускайте його після кожного кроку. Спіймати регресію рано.
Підказка щодо безпечного плану рефакторингу: «Наступна функція з 60 рядків робить занадто багато, і її важко читати. Я хочу рефакторинг її БЕЗ зміни її поведінки. Спочатку: перелічіть, які тестові випадки мені потрібні, щоб заблокувати поточну поведінку. Потім: розбийте рефакторинг на невеликі кроки, кожен із яких можна виконати, поки тести зелені. Поки що не пишіть код, спочатку дайте план. Код: [код]»
Слабка підказка / Сильна підказка
СЛАБКО: «Зробіть цей код кращим». (Результат: незрозуміло, що покращити; штучний інтелект вносить довільні зміни, може мовчки змінювати поведінку.) СИЛЬНО: «Рефакторинг цієї функції розрахунку платежів для читабельності. ОБМЕЖЕННЯ: поведінка має залишатися незмінною, повертані значення не повинні змінюватися. Розділіть функцію long на значущі корисні функції, збільшуючи магічні числа до іменованих констант. Перерахуйте зміни по елементах і поясніть, ЧОМУ кожен елемент не змінює поведінку. Код: [код]»
Потужна підказка чітко вказує на обмеження «поведінка має залишатися незмінною» та що потрібно покращити. Без цього обмеження штучний інтелект може змінити логіку в ім’я «покращення» та створити тиху регресію.
Управління технічним боргом
Підхід
У короткостроковій перспективі
в довгостроковій перспективі
ігнорування боргу
швидкий прогрес
Параліч обслуговування, уповільнення роботи команди
все переписати
Розробка постійної функції
Невпевнений прибуток, високий ризик
Виміряний, захищений тестами рефакторинг
незначне уповільнення
Стабільна швидкість
Найздоровішим способом є третій: зробіть борг видимим (відстежуйте його у списку), починайте з того місця, де найбільше боляче, і перевіряйте кожне виправлення. AI є гарною підмогою у визначенні та пріоритетності статей боргу, але який борг сплачувати – це бізнес-рішення.
Міні-чохли
Випадок 1 — Тиха регресія. Розробник каже ШІ «спростити цю функцію»; ШІ неправильно перекладає умову, і обчислення повернення порушується. Оскільки тестування не проводиться, помилка виникає через 3 тижні після скарги клієнта. Команда виконує ту саму роботу, спочатку складаючи тест на характеристику та виявляючи помилку червоним тестом під час першого запуску.
Випадок 2 — корисне друге око. Під час перевірки коду ШІ розуміє, що авторизація користувача перевіряється лише в інтерфейсі, а не на сервері. Це вразливість несанкціонованого доступу. Інженер додає перевірку авторизації на стороні сервера; Перевірка ШІ запобігає фактичному інциденту безпеки.
Випадок 3 — Хибний результат. ШІ каже: «ця змінна ніколи не використовується, видаліть її»; Однак він використовується опосередковано через механізм змінного відображення. Якщо інженер не перевірив пропозицію на тест, її буде видалено, і виникне помилка виконання. Кожен висновок штучного інтелекту має бути підтверджений перед впровадженням.
Поширені помилки
- Рефакторинг без тестування. Немає нічого, що гарантувало б збереження поведінки.
- Застосування висновків ШІ без їх перевірки. Бувають як помилкові позитивні, так і помилкові негативні результати.
- Витрачати людський час на проблеми формату. Зосередження на завданнях, які можна вирішити за допомогою автоматизованих інструментів, затьмарює реальні ризики.
- Приймаючи відповідь «Без проблем» як гарантію. AI може обійти вразливість; необхідна перевірка людиною.
- Намагається погасити весь борг відразу. Значні перезаписи ризиковані; Кращі кроки, які виміряні та захищені тестуванням.
Підсумовуючи
Перевірка коду та рефакторинг визначають довговічність коду. AI є потужним другим оком і генератором планів: надає пріоритетні висновки, сценарії безпеки та невеликі плани рефакторингу. Але рефакторинг не повинен змінювати поведінку, і лише тестування гарантує це. Перевіряйте кожен результат штучного інтелекту відповідно до коду та тестування; Не сприймайте відповідь «немає проблем» як доказ. Зробіть технічний борг видимим і погасіть його поетапно, захищено тестами.
Аплікаційне завдання
Візьміть 40-70 рядків, дещо складну функцію, яку ви маєте (або попросіть штучний інтелект згенерувати). Спочатку дотримуйтеся підказки структурованого перегляду та відсортуйте висновки за [КРИТИЧНИМ]/[СЕРЕДНІМ]/[НИЗЬКИМ]; Вручну перевірте принаймні один висновок на код. Потім, за допомогою підказки безпечного плану рефакторингу, спочатку створіть і запустіть тести характеристики, потім застосуйте рефакторинг невеликими кроками та переконайтеся, що тести залишаються зеленими на кожному кроці.
контрольний список
- [ ] Я структурував огляд за тегами пріоритету (критичний/середній/низький).
- [ ] Я перевірив принаймні один результат штучного інтелекту на відповідність коду/тесту.
- [ ] Я перевірив поточну поведінку перед рефакторингом.
- [ ] Я вносив зміни невеликими кроками та запускав тести на кожному кроці.
- [ ] Я вказав обмеження «Поведінка має залишатися незмінною» у підказці.
- [ ] Я підтвердив, що результати безпеки потребують підтвердження людини.