¿Qué herramientas de revisión de código y métodos deberíamos usar para el código entregado por una agencia?

Al pasar herramientas estáticas no te fijes solo en los estándares de código, revisa también las reglas SAST centradas en seguridad. La inyección SQL, las referencias directas a objetos no seguras (IDOR) y los puntos de validación de entrada deficientes caen fácilmente con reglas automáticas. Revisa también la cobertura de tests; si la agencia no hizo pruebas unitarias, refactorizar ese código será un infierno.

El año pasado recibimos el backend móvil de un proyecto de 40.000 dólares en una situación parecida. Los escaneres automáticos daban luz verde porque la sintaxis estaba impoluta. Pero dos semanas después de salir a producción, la base de datos se bloqueó; resulta que la agencia no había puesto claves foráneas ni índices en ninguna tabla. Eso una herramienta no lo ve jamás.

Nosotros pagamos 2.500 dólares a un arquitecto senior independiente en la fase de entrega para que hiciera una revisión profunda de 15 horas. Nos sacó 4 errores principales de arquitectura que impedían el escalado y 8 fallos de autorización expuestos. Valio muchísimo la pena.

En los trabajos de agencia no os fiéis a ciegas de los informes de herramientas automáticas. A veces las agencias, con tal de que las herramientas de análisis no den avisos, dividen las funciones en mil partes y escriben un código "limpio" de cara a la galería, pero la lógica de negocio es un verdadero desastre. Las herramientas no confirman que el código funcione bien, solo te dicen si cumple las reglas de sintaxis.

Lo primero que podéis hacer mañana mismo: revisad el historial de versiones del repositorio (git log). ¿La agencia ha subido todo el trabajo con prisas y pánico en los últimos 3 días, o ha ido avanzando durante 4 meses con commits regulares y mensajes explicativos? La disciplina con las versiones es el mayor indicador de la calidad interna del código.

Checklist para entregas de agencias: 1) ¿Se han olvidado claves de API de servicios externos dentro del código? 2) ¿Las licencias de las librerías de código abierto son aptas para uso comercial? 3) ¿Los pasos de despliegue (deployment) y configuración local funcionan al 100% siguiendo un único documento?

mirad sí o sí si han escrito tests. las agencias casi siempre dicen q no les dio tiempo y no hacen tests unitarios luego cambias una sola línea de código y se cae toda la arquitectura.

tened un poco de paciencia con el senior que acabáis de contratar. heredar el código de otra persona es la tarea más frustrante del mundo para un desarrollador. las herramientas automáticas al menos evitan que las discusiones se vuelvan personales y las centran en métricas objetivas.

Tomo nota, gracias.

Yo también tengo curiosidad.

Estoy siguiendo esto.

Buen trabajo. La respuesta varía mucho según el sector no hay una regla general.

Lo dejo como nota por si sirve.

el camino que parece baraot suele salir caro a la larga pero al tomar decisiones escribe también el peor escenario no solo el mejor.

si intentas cambiarlo todo a la vez, nada termina de asentarse. si escribís el resultado aquí, también servirá de ayuda a otros.

Después de vivir eso, mi perspectiva cambió. El código sin documentación de instalación, aunque lo tengas, no es tuyo.

Si escribís el resultado aquí, también servirá de ayuda a otros.

Estoy de acuerdo.

Hace mucho que oímos eso, pero a nosotros nunca nos pasó así. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Yo seguiría por ese camino.

Yo pasé por esto, déjenme contarlo. Un informe semanal por escrito funciona mucho mejor que preguntar por fechas.

A nosotros también nos pasa. Todos los que se apresuran con herramientas de revisión de código se atascan en el mismo punto.

Empezad con una pequeña prueba, no lo integréis todo de golpe. Yo seguiría por ese camino.