Revisión de código con pruebas y un historial
Los equipos de ingeniería reciben una revisión de cada cambio, con la documentación y la corrección adjuntas. La misma revisión se ejecuta desde el terminal, el editor, la API y un servicio automatizado, por lo que una revisión tiene el mismo significado independientemente de dónde se inicie.
- SectorHerramientas para desarrollo
- Tipo de trabajoProducto de Koca Ventures, desarrollado y propiedad de la propia empresa
- EstadoEn uso activo, en fase de desarrollo continuo
Un motor detrás de cada forma de solicitar una revisión
Los equipos de ingeniería reciben los resultados relativos a la seguridad, el rendimiento y la calidad de un cambio propuesto, cada uno con una solución sugerida, siguiendo una cola ordenada que se va procesando desde el principio.
El mismo motor se ejecuta tanto si la solicitud procede de un comando de terminal, un editor, la API o un servicio en segundo plano que supervisa un repositorio de forma programada. Los cuatro comparten un mismo historial, por lo que una revisión iniciada desde el teclado es la misma que se muestra posteriormente en el panel de control, y una solicitud de incorporación de cambios (pull request) mantiene un único comentario que se actualiza en el mismo lugar. Koca Ventures ha desarrollado y es propietaria de la plataforma. Funciona tanto con modelos alojados localmente en el propio hardware de la organización como con proveedores externos, por lo que un cliente puede adoptarla sin necesidad de crear un sistema de revisión personalizado ni de ajustar sus propios modelos de revisión.
Revisión automatizada que los ingenieros dejan de leer
Las organizaciones de ingeniería que adoptan la revisión automatizada se enfrentan a tres problemas. La plataforma se ha diseñado para hacer frente a cada uno de ellos.
Ruido que cuesta más de lo que aporta
Una herramienta que señala los cambios de formato, las importaciones reordenadas y las suposiciones sin verificar enseña al equipo a revisar por encima el resultado de su trabajo. Una vez que se revisa por encima el resultado de la revisión, la única conclusión que importaba pasa desapercibida junto con el resto.
Los problemas detectados que no se solucionan se convierten en incidencias
Un comentario de revisión que describe un problema y devuelve el trabajo a un ingeniero que ya estaba ocupado. Aún hay que elaborar el código corregido, y a menudo se pospone la resolución del problema.
Comportamiento irregular en las distintas superficies
Las revisiones en la terminal, en el editor, en una solicitud de incorporación de cambios y en una programación eran herramientas independientes, con un comportamiento y un historial distintos. Un mismo cambio podía pasar una revisión y fallar en otra.
Qué hace la plataforma
Una revisión allí donde se solicite, con las pruebas que un ingeniero necesita para evaluar cada hallazgo.
La misma revisión, independientemente del lugar en el que trabaje el equipo
Un equipo realiza una revisión desde la terminal, el editor, la API o un servicio programado y obtiene el mismo resultado con el mismo historial. Una revisión iniciada desde el teclado es la misma que se muestra posteriormente en el panel de control.
- Un comando de terminal, una integración con el editor, una API con actualizaciones en vivo y un servicio en segundo plano ejecutan la misma revisión
- Un historial compartido: la revisión iniciada en el teclado es la que el panel muestra después
- Funciona con modelos alojados localmente en el propio hardware del cliente o con proveedores externos, seleccionados en la configuración
Hallazgos que llegan con la corrección
Cada incidencia tiene asignado un nivel de gravedad y una de estas tres acciones: «corregir ahora», «corregir pronto» o «revisar más adelante», de modo que el equipo aborda el informe empezando por la parte superior. El código corregido se adjunta, por lo que una incidencia se considera trabajo realizado en lugar de una incidencia abierta.
- Cada resultado incluye un código de sustitución
- Cada hallazgo apunta a una ruta real en el repositorio
- Un resultado sigue siendo identificable a pesar de los cambios de formato
Conclusiones que un ingeniero puede evaluar
Los resultados se presentan acompañados de pruebas que los respaldan y de su estado de revisión, de modo que los ingenieros puedan ver qué se ha confirmado y qué no ha podido confirmar la plataforma.
- Los cambios insignificantes no generan ruido en la revisión
- Cada hallazgo incluye su evidencia y su estado de revisión
- Un hallazgo que no se haya podido confirmar se mantiene en el informe y nunca se omite sin más.
Las vulnerabilidades se detectan y se corrigen antes de que un atacante las descubra
Cuando se solicita, la plataforma busca en el código fuente una vulnerabilidad explotable, propone el parche y comprueba que este la solucione. Cada elemento se clasifica como «verificado», «parcialmente solucionado», «aún abierto» o «falsa alarma», y un ingeniero decide qué medidas se aplican.
- De un solo golpe se abarcan varias perspectivas, desde la lógica empresarial hasta el cumplimiento normativo
- Los parches se envían como propuestas; no se añade nada al repositorio
- Los agentes se ejecutan bajo restricciones que impiden las operaciones destructivas
¿Qué cambia en la práctica?
Los ingenieros revisan los resultados, junto con las pruebas que los respaldan y las soluciones propuestas.
Una cola
Lo que produce una revisión
Los resultados de cada agente llegan en forma de una lista ordenada, que se procesa desde arriba hacia abajo.
Pruebas adjuntas
Lo que acompaña a un hallazgo
Los ingenieros consultan las pruebas y el estado de revisión asociados a cada hallazgo antes de tomar medidas al respecto.
Un ingeniero decide
Cómo entran los cambios
Las correcciones y los parches se envían como propuestas con una vista previa. No se añade nada al repositorio sin que un ingeniero lo apruebe.
Habla con nosotros sobre la revisión de código en tu empresa
Cuéntanos cómo se revisa el código actualmente y dónde surgen los atascos. Te diremos qué merece la pena automatizar y qué no.
Hablemos de su proyecto