Ինչպես Aviator-ը 4 անգամ ավելի AI կոդ է վերանայում՝ ամեն տողը չկարդալով

Aviator-ը ասում է, որ նույն ինը ինժեներները 4 անգամ ավելի փոփոխությունների հարցում են միացրել՝ կոդի վերանայումը հում diff-երի ընթերցումից փոխելով նպատակի, ընդունման չափանիշների, ինվարիանտների, որոշումների և կոնկրետ ապացույցների ստուգման։ Միացման միջին ժամանակը 2.1 օրից իջել է մինչև 3.4 ժամ, հետադարձումները նվազել են 40%-ով, և յուրաքանչյուր փոփոխության հարցում դեռ հաստատում է մարդը։

Խնդիրը՝ կոդի վերանայումը չի մասշտաբվում AI-ի հետ

Թիմի կոդը շրջվել է մարդու կողմից գրված՝ AI-ի օգնությամբ, վիճակից AI-ով ստեղծված՝ մարդու օգնությամբ վիճակի։ Շաբաթական միացված փոփոխությունների հարցումները մոտ 100-ից դարձել են ավելի քան 400, իսկ AI-ով ստեղծված փոփոխության հարցման միջին չափը հասել է 640 տողի՝ անցնելով 400 տողի սահմանը, որը լայնորեն համարվում է սխալների հայտնաբերման անկման սահման։

Սխալների որսումը երբեք կոդի վերանայման հիմնական նպատակը չի եղել։ Microsoft-ի 2013 թվականի Bacchelli-ի և Bird-ի ուսումնասիրության մեջ վերանայման մեկնաբանությունների միայն 14%-ն էր վերաբերում թերություններին։ Վերանայումը այն ձևն է, որով ինժեներները գիտելիք են փոխանակում և համակարգի մասին իրենց մտավոր մոդելը թարմ են պահում, և հենց դա է արժե պաշտպանել։ Երբ գործակալները գրում են կոդի մեծ մասը, հենց այդ մասն է ամենամեծ վտանգի տակ։ Հարցին՝ արդյոք նրանք պարզապես դադարել են վերանայել, թիմը պատասխանում է՝ ոչ, նրանք դադարել են վերանայել diff-ը։ Նրանց եզրակացությունն այն է, որ որոշումները մարդ են պահանջում, իսկ diff-ը վատագույն տեղն է դրանք կայացնելու համար։

Ինչ փոխվեց՝ ստուգել նպատակը, ոչ թե տողերը

Կոդի վերանայումը նախկինում մի քանի աշխատանք էր անում միաժամանակ՝ որսում էր սխալներ, պարտադրում թիմի կոնվենցիաները, կայացնում նախագծային որոշումներ և բոլորի համակարգի ըմբռնումը թարմ էր պահում։ Թիմը այդ աշխատանքները բաժանեց և յուրաքանչյուրին ավելի լավ տեղ տվեց։

Նպատակը և ընդունման չափանիշները վերցվում են գործակալի հետ ծրագրավորման սեսիայից, այլ ոչ թե գրվում են որպես նախապես սահմանված սպեցիֆիկացիա։ Ամեն անգամ, երբ ինժեները ուղղում է գործակալին կամ պատասխանում նրա հարցին, ստեղծվում է չափանիշ։ Թիմն ասում է, որ նախկինում սեսիայի ավարտին դրանք դեն էին նետում։ Նպատակը պատասխանում է, թե ինչու է փոփոխությունը կատարվում, իսկ ընդունման չափանիշները՝ թե ինչպես այն պետք է իրեն պահի։ Առանց չափանիշների նպատակը չի կարող ստուգվել, իսկ առանց նպատակի չափանիշները չեն կարող դատվել։

Այդ երկրորդ կեսը հենց այն է, ինչ diff կարդացող վերանայողը երբեք չէր ստուգի։ Ոչ բոլոր չափանիշներն են պահանջում դիտարկիչ. API պայմանագիրը ապացուցվում է գրանցված հարցումով և պատասխանով, իսկ կոդի կանոնը՝ ast-grep համընկնմամբ կամ ֆայլի և տողի հղումով։ Խորհուրդն այն է, որ ընտրեն ամենաէժան ապացույցը, որը լուծում է հարցը։ Կանաչ CI ստուգումը միայն ասում է, որ այն թեստերը, որոնք մտածել էիք, անցել են։

Որոշումները գալիս են երեք տեղից՝ ծրագրավորման սեսիայից, գործակալների փաստարկից և ձախողված ստուգման աշխատանքներից։ Փոփոխության հարցումը թվարկում է բոլորը, թե որտեղից են եկել և ով է լուծել։ Մի փոփոխության հարցման մեջ, որը ավելացրել էր կրկնակի փորձեր ձախողված webhook առաքումների համար, հինգ որոշումներից չորսը լուծվել էին. գործակալները համաձայն չէին, թե արդյոք պետք է հեռացնել կրկնվող առաքումները, այդ մեկը լուծեց մարդը։

Ինժեներները դադարում են ընթերցել ամեն տող։ Նրանք պատասխանատու են այն կանոնների համար, որոնք ստուգում են ամեն տող, և համակարգի ըմբռնումը պահում են նպատակը, ապացույցները և որոշումները ընթերցելով։

Արդյունքները

Վերանայման աշխատանքը չի անհետացել։ Այն տեղափոխվել է ինվարիանտների կատարելագործման, որոշումների քննարկման և ստուգման բարելավման։ Անցումը կարող է ցավոտ լինել. առաջին ամիսը կրկնակի աշխատանք է, երկրորդ ամսին ինվարիանտները բավականաչափ են հասնում, որ վերանայումները փոքրանան, իսկ երրորդ ամսին մարդիկ կարդում են նպատակն ու ապացույցները, ոչ թե կոդը։

Աղբյուրներ։ The New Stack