Добици:
- Могућност коришћења вештачке интелигенције као другог ока у прегледу кода ради читљивости, логике и безбедности
- Способност планирања корака рефакторисања уз подршку АИ без ометања сложеног понашања кода
- Могућност верификације прегледа АИ и уређивања препорука уз тестирање и поређење контроле верзија
У софтверском инжењерству, код се чита много више него што се пише. Ред кода се пише једном, али се чита, модификује и надограђује на десетине пута током месеци. Зато су преглед кода (прегледање туђег или вашег сопственог кода ради логике, читљивости и сигурности) и рефакторинг (побољшање структуре кода без промене његовог понашања) у срцу инжењеринга. АИ постаје моћно „друго око“ за ова два задатка: брзо сугерише читљивост, указује на занемарене логичке и безбедносне проблеме и разбија велико рефакторисање на мање безбедне кораке. Али постоји критично правило: рефакторисање не би требало да промени понашање, а једина ствар која то гарантује је тестирање.
У овој јединици ћемо видети како да користимо вештачку интелигенцију на структурисан начин за преглед кода, како да поправимо сложени код без нарушавања његовог понашања и како да управљамо техничким дугом (брзе, али скупе одлуке кода).
Концепти: Технички дуг: Одлуке о кодовима донете данас за брзину које отежавају одржавање у будућности. Мирис кода: обрасци који сами по себи нису грешке, али указују на проблеме (предугачке функције, понављајући код). Регресија: Када промена поквари нешто што је раније функционисало.
Коришћење вештачке интелигенције у прегледу структурисаног кода
Када је време ограничено, потребно је фокусирати се на питања највећег ризика. Аутоматски формататор решава проблеме форматирања као што су увлачење и размаци; Људску пажњу морате посветити логици, безбедности и понашању на ивичним случајевима. Када имате АИ преглед, тражите листу приоритета, а не обичну салву рецензија.
- Дајте обим. Који код, шта да се ради, у ком контексту функционише.
- Одредите приоритетну осу. Прецизност и сигурност на првом месту, читљивост друго.
- Тражите конкретну корекцију. „Зашто проблем“ и „препоручено решење“ за сваки налаз.
- Ви проверите налазе. АИ такође производи лажне позитивне резултате; Проверите сваки налаз у односу на код и тестирање.
Структурирани упит за преглед: „Проучите следећу функцију попут старијег инжењера. Наведите налазе по редоследу важности и означите их овим ознакама: [КРИТИЧНО] логика/безбедност, [СРЕДЊА] ивица/перформансе, [НИСКА] читљивост/име. За сваки налаз: зашто питати, конкретан предлог за исправку. НЕМОЈТЕ ПРЕСКОЧИТИ проблеме са алатком за аутоматизацију кода, [аутоматско форматирање кода]:
Упит за преглед усредсређен на безбедност: „Прегледајте овај код само у безбедносне сврхе: недостатак провере ваљаности уноса, ризик од убризгавања, недостатак контроле ауторизације, цурење поверљивих информација, несигурна подразумевана подешавања. Додајте пример сценарија напада сваком налазу. Ако нема безбедносног проблема, јасно наведите „Нисам пронашао критичне безбедносне проблеме“. Код: [шифра]“
Опрез: Само зато што АИ каже „нема проблема“ није доказ да нема проблема. АИ може произвести лажне негативне резултате; може заобићи прави безбедносни проблем. АИ преглед допуњује, а не замењује, људски преглед и безбедносно тестирање. У безбедносно-критичном коду, надлежни инжењер има последњу реч.
Тест-Пресервед Рефацторинг
Златно правило рефакторисања: прво тестирајте, а касније промените. Пре поправљања кода, требало би да постоје тестови који закључавају тренутно понашање тако да одмах знате да ли промена нешто поквари. Немојте кршити редослед када имате АИ рефакторинг.
- Ставите на тест тренутно понашање. У супротном, нека АИ произведе „тест карактеризације“ (тест који приказује тренутно понашање какво јесте).
- Поправите га у малим корацима. Тестирање мора остати зелено на сваком кораку.
- Покрените га након сваког корака. Рано ухватите регресију.
Упозорење плана за безбедно рефакторисање: „Следећа функција од 60 редова ради превише и тешко је читати. Желим да је рефакторишем БЕЗ промене њеног понашања. Прво: наведите које тестне случајеве требам да закључам тренутно понашање. Затим: разбијте рефакторисање на мале кораке, од којих сваки може да се изврши док су тестови зелени. Не дајте још код плана први код.“:
Слаба порука / јака промпт
СЛАБО: "Учините овај код бољим." (Резултат: нејасно шта треба побољшати; АИ прави произвољне промене, може да промени понашање тихо.) СНАЖНО: „Рефакторизујте ову функцију израчунавања плаћања ради читљивости. ОГРАНИЧЕЊА: понашање мора остати потпуно исто, повратне вредности се не смеју мењати. Поделите дугу функцију на смислене услужне функције, повећавајући магичне бројеве на именоване константе. Наведите промене ставку по ставку и објасните понашање ВХИ.
Моћни промпт јасно каже да „понашање мора остати потпуно исто“ ограничење и шта треба побољшати. Без овог ограничења, АИ може променити логику у име „побољшања“ и произвести тиху регресију.
Управљање техничким дугом
Приступ
У кратком року
на дуге стазе
игнорисање дуга
брз напредак
Парализа одржавања, тим успорава
преписати све
Развој сталних карактеристика
Несигуран повратак, висок ризик
Измерено, тестом заштићено рефакторисање
мање успоравање
Одржива брзина
Најздравији начин је трећи: учините дуг видљивим (пратите га на листи), почните тамо где највише боли и тестирајте сваку исправку. АИ је добра помоћ у идентификацији и одређивању приоритета ставки дуга, али који дуг треба платити је пословна одлука.
Мини Цасес
Случај 1 — Тиха регресија. Програмер каже АИ да „поједностави ову функцију“; АИ погрешно преводи услов и обрачун поврата је покварен. Пошто нема тестирања, грешка се јавља након 3 недеље уз жалбу корисника. Тим ради исти посао тако што прво напише тест карактеризације и ухвати грешку црвеним тестом при првом покретању.
Случај 2 — Корисно друго око. У прегледу кода, АИ схвата да се ауторизација корисника проверава само у интерфејсу, а не на серверу. Ово је рањивост неовлашћеног приступа. Инжењер додаје проверу ауторизације на страни сервера; АИ инспекција спречава стварни безбедносни инцидент.
Случај 3 — Лажно позитиван. АИ каже "ова променљива се никада не користи, избришите је"; Међутим, користи се индиректно кроз механизам променљиве рефлексије. Ако инжењер није верификовао предлог у односу на тест, он би био обрисан и појавила би се грешка у току рада. Сваки АИ налаз мора бити потврђен пре имплементације.
Уобичајене грешке
- Рефакторинг без тестирања. Ништа више не може да обезбеди очување понашања.
- Примена налаза вештачке интелигенције без њихове валидације. Лажни позитивни и лажни негативни се дешавају.
- Губљење људског времена на проблеме са форматом. Фокусирање на задатке који се могу решити аутоматизованим алатима засењује стварне ризике.
- Узимајући одговор "Нема проблема" као гаранцију. АИ може заобићи рањивост; потребан је људски преглед.
- Покушава да отплати цео дуг одједном. Велика преписивања су ризична; Пожељни су кораци који се мере и штите тестирањем.
Укратко
Преглед и рефакторисање кода одређују дуговечност кода. АИ је моћан генератор другог ока и плана: пружа приоритетне налазе, безбедносне сценарије и планове за рефакторисање у малим корацима. Али рефакторисање не би требало да промени понашање, а само тестирање то гарантује. Потврдите сваки налаз АИ у односу на код и тестирање; Не узимајте одговор "нема проблема" као доказ. Учините технички дуг видљивим и отплатите га у одмереним, тестом заштићеним корацима.
Задатак апликације
Узмите линију 40-70, донекле сложену функцију коју имате (или имате АИ да генерише). Прво следите структурирани упитник за преглед и сортирајте налазе као [КРИТИЧНО]/[СРЕДЊЕ]/[НИСКО]; Ручно проверите најмање један налаз у односу на код. Затим, уз промпту безбедног плана рефакторисања, прво генеришите и покрените тестове карактеризације, а затим примените рефакторисање у малим корацима и проверите да ли тестови остају зелени у сваком кораку.
контролна листа
- [ ] Структурирао сам рецензију са ознакама приоритета (критично/средње/ниско).
- [ ] Проверио сам најмање један налаз АИ у односу на код/тест.
- [ ] Тестирао сам тренутно понашање пре рефакторисања.
- [ ] Направио сам промене у малим корацима и извршио тестове на сваком кораку.
- [ ] Навео сам ограничење „Понашање мора остати исто“ у промпту.
- [ ] Потврдио сам да безбедносни налази захтевају људску потврду.