Reviseu el codi generat amb IA

Llegiu el requisit abans del resum

Comenceu pel comportament demanat i els criteris d’acceptació. Després inspeccioneu la comparació real de canvis. El resum d’un agent pot ajudar a orientar-vos, però pot ometre canvis o descriure les comprovacions de manera inexacta.

Confirmeu la branca i el commit que esteu revisant. Comproveu els canvis de configuració, dependències, infraestructura i proves, a més del codi de l’aplicació. Una funcionalitat visible petita pot incloure un gran canvi en els permisos o el comportament del desplegament.

Reviseu primer el comportament amb les conseqüències més importants. El format i els noms importen, però no han de distreure d’un límit de dades que falta.

Seguiu la identitat fins al recurs

Considereu aquest endpoint fictici i incomplet. L’exemple il·lustra un problema de revisió; no és codi de producció.

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

La funció obté un usuari autenticat. No mostra cap decisió d’autorització per a la factura. Qui revisa el codi ha d’inspeccionar si una altra capa fa complir aquesta decisió. El valor d’usuari no utilitzat és un motiu per investigar, no una prova per si mateix d’un defecte explotable.

Seguiu la petició a través del sistema real. Identifiqueu l’usuari i l’organització fiables. Comproveu com la consulta limita l’accés al registre demanat. Inspeccioneu el comportament dels errors i les proves de peticions prohibides.

No suposeu que amagar un botó protegeix l’API. Es pot enviar una petició sense utilitzar la interfície. No suposeu que un identificador de registre vàlid concedeix accés.

Pregunteu quines evidències podrien rebutjar el canvi

Una prova superada pot utilitzar dades de prova d’un administrador o simular l’autorització. Comproveu si posa a prova el límit important. Afegiu un cas amb una altra organització i un recorregut real d’autorització quan sigui pertinent.

Per a un canvi d’interfície, inspeccioneu el resultat renderitzat. Comproveu el funcionament amb teclat, els estats buits, el comportament de càrrega i els errors. Una comprovació de tipus no pot acreditar que un diàleg es pugui utilitzar amb teclat.

Per a un canvi de dependència, verifiqueu per què és necessari. Reviseu la versió, la llicència i els problemes de seguretat detectats. No accepteu una actualització no relacionada només perquè l’agent l’ha generada durant la tasca.

Manteniu la revisió independent

Un segon model pot identificar problemes útils. També pot repetir les hipòtesis de la implementació. Proporcioneu a qui revisa el requisit i la comparació de canvis. Eviteu dir-li que el canvi ja és correcte.

Exigiu que les observacions identifiquin una via concreta de fallada i el codi rellevant. Tracteu els avisos sense fonament com a preguntes per investigar. Tracteu una aprovació expressada amb seguretat com una altra opinió fins que les afirmacions importants tinguin evidències.

La revisió humana continua sent una decisió de responsabilitat. Qui revisa el canvi l’ha d’entendre prou per explicar-ne el comportament, els riscos i la verificació. Si el conjunt de canvis és massa gran, reduïu-ne l’abast o dividiu-lo en canvis que es puguin revisar.

Tanqueu la revisió sobre la versió final

Després d’una correcció, torneu a executar les comprovacions afectades. Inspeccioneu si la correcció crea un problema nou. Assegureu-vos que la revisió requerida s’aplica a la revisió final segons la política del repositori.

Escriviu la decisió d’acceptació en termes de comportament i evidències. Registreu qualsevol limitació restant amb un responsable i una acció següent. No convertiu un problema no resolt en una afirmació que totes les comprovacions han passat.

Utilitzeu l’exercici de revisió de codi per practicar la identificació de la decisió que falta abans d’examinar un canvi real.