Правярайце код, згенераваны AI

Чытайце патрабаванне перад рэзюмэ

Пачніце з запытаных паводзін і крытэрыяў прыёмкі. Затым вывучыце фактычны diff. Рэзюмэ агента можа дапамагчы арыентавацца, але можа прапускаць змены або недакладна апісваць праверкі.

Пацвердзіце галіну і commit, якія правяраеце. Акрамя кода праграмы, праверце змены канфігурацыі, залежнасцей, інфраструктуры і тэстаў. Невялікая бачная функцыя можа ўключаць вялікую змену дазволаў або паводзін разгортвання.

Спачатку правярайце паводзіны з найбольш істотнымі наступствамі. Фарматаванне і назвы маюць значэнне, але не павінны адцягваць ад адсутнай мяжы даных.

Прасочвайце ідэнтычнасць да рэсурсу

Разгледзім гэты няпоўны выдуманы endpoint. Прыклад ілюструе праблему праверкі; гэта не код для production.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

Функцыя атрымлівае аўтэнтыфікаванага карыстальніка. Яна не паказвае рашэння аб аўтарызацыі для рахунку-фактуры. Рэцэнзент павінен вывучыць, ці забяспечвае іншы ўзровень выкананне гэтага рашэння. Нявыкарыстанае значэнне user — падстава для даследавання, а не самастойны доказ дэфекту, які можна эксплуатаваць.

Прасочыце запыт праз фактычную сістэму. Вызначце даверанага карыстальніка і арганізацыю. Праверце, як запыт да базы абмяжоўвае доступ да патрэбнага запісу. Вывучыце паводзіны пры памылках і тэсты для забароненых запытаў.

Не лічыце, што схаваная кнопка абараняе API. Той, хто робіць выклік, можа адправіць запыт без выкарыстання інтэрфейсу. Не лічыце, што карэктны ID запісу дае доступ.

Спытайце, якія доказы могуць стаць падставай для адхілення змены

Тэст, які праходзіць, можа выкарыстоўваць тэставыя даныя адміністратара або заглушку аўтарызацыі. Праверце, ці выпрабоўвае ён істотную мяжу. Калі дарэчы, дадайце выпадак з іншай арганізацыяй і рэальным шляхам аўтарызацыі.

Для змены інтэрфейсу карыстальніка вывучыце адлюстраваны вынік. Праверце працу з клавіятурай, пустыя станы, паводзіны пры загрузцы і памылкі. Праверка тыпаў не можа пацвердзіць, што дыялогавае акно можна выкарыстоўваць з клавіятурай.

Для змены залежнасці праверце, навошта яна патрэбная. Вывучыце версію, ліцэнзію і выяўленыя праблемы бяспекі. Не прымайце не звязанае з задачай абнаўленне толькі таму, што агент стварыў яго падчас працы.

Захоўвайце незалежнасць праверкі

Другая мадэль можа выявіць карысныя праблемы. Яна таксама можа паўтарыць дапушчэнні рэалізацыі. Дайце рэцэнзенту патрабаванне і diff. Не кажыце яму, што змена ўжо правільная.

Патрабуйце, каб заўвагі ўказвалі канкрэтны шлях да збою і адпаведны код. Разглядайце непацверджаныя папярэджанні як пытанні для даследавання. Лічыце ўпэўненае ўхваленне яшчэ адной думкай, пакуль істотныя сцверджанні не маюць доказаў.

Праверка чалавекам застаецца рашэннем аб адказнасці. Рэцэнзент павінен дастаткова разумець змену, каб растлумачыць яе паводзіны, рызыкі і праверку. Калі diff занадта вялікі, паменшыце абсяг або падзяліце яго на змены, якія можна праверыць.

Завяршайце праверку на канчатковай рэвізіі

Пасля выпраўлення паўторна запусціце закранутыя праверкі. Вывучыце, ці не стварае выпраўленне новую праблему. Пераканайцеся, што неабходная праверка датычыцца канчатковай рэвізіі паводле палітыкі рэпазіторыя.

Запішыце рашэнне аб прыёмцы праз паводзіны і доказы. Зафіксуйце кожнае астатняе абмежаванне з адказным і наступным дзеяннем. Не ператварайце нявырашаную праблему ў сцверджанне, што ўсе праверкі прайшлі.

Выкарыстоўвайце практыкаванне па праверцы кода, каб патрэніравацца выяўляць адсутнае рашэнне перад вывучэннем рэальнай змены.