Добици:
- Способност постављања тестне сигурносне мреже која бележи тренутно понашање пре рефакторисања
- Способност да затражите од АИ за мале трансформације у једном кораку, које чувају понашање и потврдите сваки корак
- Способност идентификовања и одређивања приоритета техничког дуга у пословном контексту
Рефакторинг је побољшање унутрашње структуре кода без промене његовог спољашњег понашања: чини га читљивијим, једноставнијим, лакшим за одржавање. Технички дуг је, с друге стране, компромис дизајна направљен ради брзог решења и отплаћен „са каматама“ током времена — сваки угао који пресечете данас ће се вратити као успоравање или грешка сутра. Вештачка интелигенција је моћан помоћник који убрзава задатке који се понављају и механичког преправљања; Али постоји једно златно правило рефакторисања, а АИ сама то не може гарантовати: понашање се не сме променити.
У овој јединици учимо како да урадимо безбедно рефакторисање помоћу вештачке интелигенције: мали и реверзибилни кораци, заштита тестовима, откривање мириса кода и одређивање приоритета техничког дуга. Критична тачка је следећа: пролазни тестови, а не реч вештачке интелигенције, доказује да је понашање очувано.
Златно правило рефакторинга: Понашање остаје константно
Оно што рефакторинг чини опасним је несвесно мењање понашања док се говори „Ја се побољшавам“. Испуштање ивичног случаја када се поједностављује услов, кршење редоследа при трансформисању петље, изостанак споредног ефекта приликом раздвајања функције — све то производи код „чистог изгледа“, али покварен.
Зато је тестирање предуслов за рефакторисање: пре промене, морате имати тестове који хватају постојеће понашање. Ови тестови су „заштитна мрежа“; Ако случајно нешто покварите током рефакторисања, они ће покварити и упозорити вас. Ако немате тестове, прво напишите тестове који поправљају постојеће понашање (као што смо научили у јединици 5) — ту АИ добија брз почетак.
Опрез: Рефакторисање уз помоћ вештачке интелигенције без тестнета је један од најподмуклијих извора грешака. Лако је рећи „сачувао сам понашање“; Доказ је да исти тестови пролазе пре и после промене.
Корак по корак: сигуран ток рефакторисања
- Поставите заштитну мрежу. Нека постоје тестови који хватају тренутно понашање кода који ћете рефакторисати; Ако не, прво их запишите (и погледајте како пролазе).
- Именујте мирис. Шта побољшавате и зашто? „Ова функција ради 3 ствари“, „иста логика се понавља на 4 места“, „имена су обмањујућа“.
- Затражите мале кораке у једном кораку. Замолите АИ за једну трансформацију (нпр. само „подели ову функцију на пола“), а не да преписује целу датотеку.
- Покрени тестове. После сваког корака. Ако је зелено, настави, ако је црвено, врати га назад.
- Прочитајте Дифф. Потврдите ред по ред да промена заиста чува понашање; Може доћи до логичког клизања када се каже да је АИ „само структура“.
- Комбинујте на мале комаде. Велики једнократни рефакторинг ПР-и су и ризични и непрегледни.
Три мини кућишта
Случај 1 — функција од 220 линија безбедно подељена. Један тим је имао функцију обраде налога од 220 линија. Написано је првих 14 тестова (уз помоћ АИ) који су обухватили тренутно понашање, сви су прошли. Затим је функција АИ подељена на 5 мањих функција корак по корак; Тестови су вођени након сваког корака. Два теста су прекинута у једном кораку — АИ је пропустио повратак у ивичном случају. Тестови су ово одмах ухватили и поправили. Без мреже, грешка је могла ићи све до производње.
Случај 2 — Катастрофа без тестнета. Други програмер је "почистио" модул за израчунавање датума који није имао тестове са АИ. Код је изгледао боље, али је погрешно рачунао преступну годину; Грешка је изашла две недеље касније са жалбом корисника. Губитак је далеко надмашио време уштеђено од преправљања. Поука: рефакторисање без тестирања је коцкање.
Случај 3 — Технички приоритет дуга. Један тим је дао АИ заостатак од 30 или више „поправљивих“ поена и сваки је постигао на оси „фреквенција промене × ризик × напор“. У резултујућој табели, ружни модул који се ретко додиривао био је заправо ниског приоритета, док је модул средње сложености који се често мењао био високог приоритета. Тим је своју енергију усмерио на право место.
Четири шаблона за копирање
Откривање мириса кода и одређивање приоритета:
Кандидат за рефакторисање листе „мирише“ у овом коду: дуга функција, понављање (ДРИВиолатион), погрешно име, дубоко угнежђено стање, скривени споредни ефекат, магични број. За сваки: локација, зашто је проблем, предложени мали корак, процењени ризик (низак/средњи/висок). НЕ МЕЊАЈТЕ код још увек, само планирајте.{{цоде}}
Трансформација која чува понашање у једном кораку:
САМО урадите ово: {{појединачна конверзија, нпр. Поделите ову функцију на 3 мање именоване функције}}. ПРОМЕНИ видљиво понашање, потпис и повратне вредности. Напишите у једној реченици зашто све што сте променили чува понашање.{{цоде}}
Сигурносна мрежа пре рефактора (тестирање карактеристика):
Напишите тестове који хватају ТРЕНУТНО понашање ове функције (тачно или не); циљ је ухватити да ли се понашање мења током рефакторисања. Укључује типичне + ивице уносе. Напишите очекивања на основу тренутног излаза функције.{{фунцтион}}
Генерисање техничке евиденције дуга (заосталих предмета):
Сипајте следећу листу мириса у табелу приоритета: супстанца, област на коју утиче, учесталост промена (моје знање: {{...}}), ризик, процењени напор, препоручени приоритет. Ставите оне са високим ударцем + малим напором на врх. {{смелл_лист}}
Слаби промпт / Јаки промпт
Слабо: „Очистите овај код и учините га бољим.“
Снажно: "Подели ову функцију од 90 редова на 3 мање функције са једном одговорношћу, без промене њеног спољашњег понашања и потписа. Задржи нежељене ефекте (ДБ пише) у тренутном редоследу. Имам тестове, понашање треба да остане исто. Дајте разлику и објасните у једној реченици зашто свака подела чува понашање. [код]"
Моћна верзија; Захтева једну специфичну трансформацију, експлицитно намеће ограничење понашања и потписа и захтева оправдање. Нејасни захтеви попут „уради боље“ доводе до неконтролисаних и ризичних промена.
Рефакторинг тип
АИ поузданост
Предуслов
преименовати
висока
Да ли је опсег тачан?
Подела функција
средње висок
Тестнет је обавезан
Дељење понављања
средње
Разлика у понашању може бити скривена
Промена алгоритма/структуре
ниско
Опсежно тестирање + људска валидација
Архитектонско преуређење
ниско
Предвођен људима, подржан АИ
Управљање техничким дугом, а не његово ресетовање
Технички дуг није лош; Понекад је свесно позајмљивање (да би се испунила испорука) права одлука. Циљ није елиминисати дуг, већ учинити га видљивим и управљивим. АИ је брз у откривању и одређивању приоритета дуга, али одлучивање „који дуг треба платити, а који треба напустити“ захтева пословни контекст: колико често се овај модул мења, на колико људи утиче, који је ризик? Ову одлуку доноси тим који познаје базу кода и производ; АИ само појашњава опције.
Савет: Држите свој рефакторски ПР одвојен од ПР-а који укључују промену понашања. Могућност да кажете „овај ПР је само рефакторисање, понашање је исто“ олакшава истрагу и омогућава вам да брзо сузите узрок ако се појави проблем.
Уобичајене грешке
- Рефакторинг без тестне мреже. Немате ништа да докажете да је понашање очувано.
- То значи "обрисати целу датотеку". Велике, неконтролисане промене скривају грешку и не могу се испитати.
- Прихватање разлике без читања. АИ је можда промашио логику када је рекао "само структура".
- Бркање рефакторинга са променом понашања. Радити обоје у истом ПР-у онемогућава праћење основног узрока.
- Покушавам да поправим сваки мирис. Ружан код који се ретко мења често је ниског приоритета; Доделите енергију месту које се често мења.
Укратко
Једино правило рефакторисања је да понашање остане константно, а доказ томе су тестови. АИ је моћна у откривању мириса кодова, трансформацијама у једном кораку и одређивању приоритета техничког дуга; али морате да подесите заштитну мрежу, покренете тестове и прочитате разлику након сваког корака. Правите мале, реверзибилне кораке; разликовати рефакторинг од промене понашања; и нека тим који познаје пословни контекст одлучи који дуг ће платити.
Задатак апликације
Изаберите функцију из базе кода која вам изгледа дугачка или сложена. Прво одштампајте тестове који бележе његово тренутно понашање помоћу шаблона „сигурносне мреже“ и видите да ли су сви прошли. Затим извршите рефакторисање функције на један начин (нпр. раздвајање на пола) са шаблоном „трансформација у једном кораку, очување понашања“ и поново покрените тестове. Ако се тест поквари, сазнајте зашто; Ако се уопште не поквари, прочитајте разлику ред по ред да бисте потврдили да је понашање заиста очувано.
контролна листа
- [ ] Знам да рефакторисање не би требало да промени понашање и постоје тестови који то доказују.
- [ ] Постављам заштитну мрежу која хвата тренутно понашање пре рефактора.
- [ ] Желим мале трансформације у једном кораку од АИ, а не велике једнократне.
- [ ] После сваког корака покрећем тестове и читам дифф.
- [ ] Држим да рефакторишем ПР одвојено од ПР-а промене понашања.
- [ ] Дајем приоритет техничком дугу са пословним контекстом, а не слепо покушавајући да се смањим на нулу.