Печалби:
- Възможност за използване на AI като второ око при преглед на код за четливост, логика и сигурност
- Възможност за планиране на стъпки за рефакторинг с поддръжка на AI, без да се нарушава сложното поведение на кода
- Възможност за проверка на препоръките за преглед и редактиране на AI с тестване и сравнение на контрола на версиите
В софтуерното инженерство кодът се чете много повече, отколкото се пише. Един ред код се пише веднъж, но се чете, модифицира и надгражда десетки пъти в течение на месеци. Ето защо прегледът на кода (преглед на чуждия или вашия собствен код за логика, четливост и сигурност) и рефакторингът (подобряване на структурата на кода без промяна на поведението му) са в основата на инженерството. AI се превръща в мощно „второ око“ за тези две задачи: той бързо предлага четливост, посочва пренебрегвани проблеми с логиката и сигурността и разбива голям рефакторинг на по-малки безопасни стъпки. Но има критично правило: рефакторингът не трябва да променя поведението и единственото нещо, което гарантира това, е тестването.
В този модул ще видим как да използваме AI по структуриран начин за преглед на код, как да коригираме сложен код, без да нарушаваме поведението му, и как да управляваме технически дълг (бързи, но скъпи решения за код).
Концепции: Технически дълг: Кодирайте решенията, взети днес за скорост, която затруднява поддръжката в бъдеще. Миризма на код: Модели, които сами по себе си не са грешки, но показват проблеми (твърде дълги функции, повтарящ се код). Регресия: Когато промяната повреди нещо, което преди това е работело.
Използване на AI в преглед на структуриран код
Когато времето е ограничено, е необходимо да се съсредоточите върху най-рисковите проблеми. Автоматичният формататор се справя с проблеми с форматирането като отстъпи и интервали; Трябва да отделите човешко внимание на логиката, сигурността и поведението на крайния случай. Когато правите преглед на AI, поискайте списък с приоритети, а не обикновена порция от прегледи.
- Дайте обхвата. Какъв код, какво да се направи, в какъв контекст работи.
- Посочете приоритетната ос. Точността и сигурността на първо място, четливостта на второ място.
- Поискайте конкретна корекция. „Защо проблемът“ и „препоръчително решение“ за всяка констатация.
- Вие проверявате констатациите. AI също произвежда фалшиви положителни резултати; Проверете всяка констатация спрямо код и тестване.
Подкана за структуриран преглед: „Разгледайте следната функция като старши инженер. Избройте констатациите по ред на важност и ги маркирайте с тези тагове: [КРИТИЧНО] логика/сигурност, [СРЕДНО] граничен случай/производителност, [НИСКА] четливост/име. За всяка констатация: защо да питате, конкретно предложение за корекция. НЕ ПРОПУСКАЙТЕ проблемите с форматирането/отстъпа, автоматизираният инструмент ще се справи. Код: [код]“
Подкана за преглед, фокусиран върху сигурността: „Прегледайте този код само за целите на сигурността: липса на проверка на входа, риск от инжектиране, липса на контрол на оторизацията, изтичане на поверителна информация, несигурни настройки по подразбиране. Добавете примерен сценарий на атака към всяка констатация. Ако няма проблем със сигурността, ясно посочете „Не открих критични проблеми със сигурността“. Код: [код]“
Внимание: Само защото AI казва „няма проблем“ не е доказателство, че няма проблем. AI може да произведе фалшиви негативи; може да заобиколи истински проблем със сигурността. AI прегледът допълва, а не замества човешкия преглед и тестването за сигурност. При критичен за сигурността код компетентният инженер има последната дума.
Тест-запазено рефакторинг
Златното правило на рефакторинга: първо тествайте, променяйте по-късно. Преди да коригирате кода, трябва да има тестове, които заключват текущото поведение, така че да знаете незабавно дали промяната нарушава нещо. Не нарушавайте реда, когато извършвате AI рефакторинг.
- Тествайте текущото поведение. В противен случай накарайте AI да произведе „тест за характеризиране“ (тест, който улавя текущото поведение такова, каквото е).
- Поправете го с малки стъпки. Тестването трябва да остане зелено на всяка стъпка.
- Пуснете го след всяка стъпка. Хванете регресията рано.
Подкана за безопасен план за рефакторинг: „Следната 60-редова функция прави твърде много и е трудна за четене. Искам да я рефакторирам БЕЗ да променя поведението й. Първо: избройте какви тестови случаи трябва да заключа, за да заключа текущото поведение. След това: разделете рефакторинга на малки стъпки, всяка от които може да бъде изпълнена, докато тестовете са зелени. Не пишете кода още, дайте първо плана. Код: [код]“
Слаба подкана / Силна подкана
СЛАБ: "Направете този код по-добър." (Резултат: неясно какво да се подобри; AI прави произволни промени, може да промени поведението безшумно.) СИЛНО: „Рефакторинг на тази функция за изчисляване на плащането за четливост. ОГРАНИЧЕНИЕ: поведението трябва да остане абсолютно същото, връщаните стойности не трябва да се променят. Разделете дългата функция на значими полезни функции, увеличавайки магическите числа до наименувани константи. Избройте промените елемент по елемент и обяснете ЗАЩО всеки елемент не променя поведението. Код: [код]"
Мощната подкана ясно посочва ограничението „поведението трябва да остане абсолютно същото“ и какво трябва да се подобри. Без това ограничение AI може да промени логиката в името на „подобрение“ и да произведе тиха регресия.
Управление на техническия дълг
подход
В краткосрочен план
в дългосрочен план
игнориране на дълга
бърз напредък
Парализа на поддръжката, екипът се забавя
пренапишете всичко
Постоянно развитие на функцията
Несигурна доходност, висок риск
Измерен, защитен от тестове рефакторинг
незначително забавяне
Устойчива скорост
Най-здравословният начин е третият: направете дълга видим (проследете го в списък), започнете оттам, откъдето боли най-много, и тествайте всяка поправка. AI е добра помощ при идентифицирането и приоритизирането на дългови елементи, но кой дълг да се плати е бизнес решение.
Мини калъфи
Случай 1 — Тиха регресия. Разработчикът казва на AI "да опрости тази функция"; AI превежда условие неправилно и изчислението на връщането е нарушено. Тъй като няма тестване, грешката възниква след 3 седмици с оплакване от клиент. Екипът върши същата работа, като първо пише тест за характеризиране и улавя грешката с червен тест при първото изпълнение.
Случай 2 — Полезно второ око. При преглед на кода AI осъзнава, че авторизацията на потребителя се проверява само в интерфейса, а не на сървъра. Това е уязвимост при неоторизиран достъп. Инженерът добавя проверка на авторизация от страна на сървъра; AI инспекцията предотвратява действителен инцидент със сигурността.
Случай 3 — Фалшив положителен резултат. AI казва "тази променлива никога не се използва, изтрийте я"; Въпреки това, той се използва индиректно чрез механизъм за променливо отражение. Ако инженерът не провери предложението спрямо теста, то ще бъде изтрито и ще възникне грешка по време на изпълнение. Всяка констатация на AI трябва да бъде потвърдена преди прилагането.
Често срещани грешки
- Рефакторинг без тестване. Не е останало нищо, което да гарантира, че поведението е запазено.
- Прилагане на констатации на AI, без да ги валидирате. Случват се както фалшиви положителни, така и фалшиви отрицателни резултати.
- Губене на човешко време за проблеми с формата. Фокусирането върху задачи, които могат да бъдат решени с автоматизирани инструменти, засенчва реалните рискове.
- Приемане на отговора „Няма проблем“ като гаранция. AI може да заобиколи уязвимостта; изисква се преглед от човек.
- Опитвате се да изплатите целия дълг наведнъж. Основните пренаписвания са рискови; Предпочитат се стъпки, които са измерени и защитени чрез тестване.
В обобщение
Прегледът на кода и рефакторингът определят дълголетието на кода. AI е мощно второ око и генератор на планове: предоставяне на приоритизирани констатации, сценарии за сигурност и планове за рефакторинг на малки стъпки. Но рефакторингът не трябва да променя поведението и само тестването гарантира това. Валидирайте всяко откритие на AI спрямо код и тестване; Не приемайте отговора „няма проблем“ като доказателство. Направете техническия дълг видим и го изплатете на премерени, защитени от тест стъпки.
Задача за приложение
Вземете 40-70 ред, донякъде сложна функция, която имате (или накарайте AI да генерира). Първо следвайте подканата за структуриран преглед и сортирайте констатациите като [КРИТИЧНИ]/[СРЕДНИ]/[НИСКИ]; Проверете ръчно поне една констатация спрямо кода. След това, с подканата за план за безопасно преработване, първо генерирайте и стартирайте тестовете за характеризиране, след това приложете преработването на малки стъпки и проверете дали тестовете остават зелени на всяка стъпка.
контролен списък
- [ ] Структурирах прегледа с етикети за приоритет (критичен/среден/нисък).
- [ ] Проверих поне една констатация на AI спрямо кода/теста.
- [ ] Тествах текущото поведение преди рефакторинг.
- [ ] Направих промените на малки стъпки и проведох тестове на всяка стъпка.
- [ ] Посочих ограничението „Поведението трябва да остане същото“ в подканата.
- [ ] Потвърдих, че констатациите за сигурност изискват потвърждение от човек.