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