opencodecode-reviewcalidadequiposbest-practices

OpenCode para Code Review: Automatización de Revisiones de Código

By Binary Core

El code review manual es lento y propenso a inconsistencias. OpenCode puede actuar como primer revisor automático: detecta anti-patrones, verifica convenciones, sugiere optimizaciones y encuentra vulnerabilidades de seguridad antes de que un humano revise el código.

Este tutorial asume que dominas el flujo Plan/Build, el debugging y la generación de tests. Aquí nos enfocamos en code review automatizado.

Code Review Pre-Commit

Análisis local antes de commitear

Antes de crear un PR, pide a OpenCode que revise tus cambios:

[Plan Mode]

Revisa estos cambios como si fueras un senior engineer:

Archivos modificados:
- @src/services/PaymentService.ts
- @src/api/payments.ts
- @src/components/PaymentForm.tsx

Busca:
1. Lógica de negocio que debería estar en tests
2. Tipos de TypeScript que podrían ser más restrictivos
3. Código duplicado que podría extraerse
4. Dependencias nuevas innecesarias
5. Violaciones de convenciones del proyecto
6. Problemas de seguridad

Contexto: @AGENTS.md

OpenCode generará un reporte estructurado:

## Issues Críticos
- [Security] @src/api/payments.ts:45 - El token de Stripe está expuesto en logs
- [Bug] @src/services/PaymentService.ts:78 - Race condition posible en procesamiento concurrente

## Issues Moderados
- [Type Safety] @src/components/PaymentForm.tsx:23 - `any` type en handler
- [Duplication] @src/services/PaymentService.ts:120 - Lógica de validación duplicada de @src/utils/validator.ts

## Sugerencias
- Extraer validación a función reutilizable
- Añadir tests para el edge case de payment timeout
- Usar Result<T, E> en lugar de throw/catch

Verificación de convenciones

OpenCode puede verificar que el código sigue las convenciones del proyecto:

Verifica que estos cambios siguen las convenciones documentadas
en @AGENTS.md:

- TypeScript: ¿Hay `any` types? ¿Faltan tipos de retorno?
- React: ¿Hay "use client" innecesario? ¿Lógica en componentes?
- Testing: ¿Hay lógica de negocio sin tests?
- Naming: ¿Los nombres siguen el estilo del proyecto?

Archivos: @src/services/AuthService.ts @src/middleware/auth.ts

Code Review de Pull Requests

Análisis completo de PR

Para PRs más grandes, usa un prompt más detallado:

[Plan Mode]

Revisa este PR exhaustivamente:

Contexto del PR:
- Añade autenticación con JWT
- Modifica 8 archivos
- Añade 3 nuevas dependencias

Archivos:
- @src/services/AuthService.ts (nuevo)
- @src/middleware/auth.ts (nuevo)
- @src/api/auth.ts (modificado)
- @src/controllers/AuthController.ts (modificado)
- @src/types/auth.ts (nuevo)
- @src/hooks/useAuth.ts (nuevo)
- @src/app/login/page.tsx (modificado)
- @src/app/dashboard/page.tsx (modificado)

Revisa:
1. **Arquitectura**: ¿La separación de concerns es correcta?
2. **Security**: ¿JWT está configurado correctamente? ¿Secrets no están hardcodeados?
3. **Type Safety**: ¿Todos los tipos son correctos y restrictivos?
4. **Error Handling**: ¿Todos los errores están manejados apropiadamente?
5. **Performance**: ¿Hay operaciones innecesarias o ineficientes?
6. **Testing**: ¿Hay tests para la nueva funcionalidad?
7. **Documentation**: ¿El código está bien documentado?
8. **Breaking Changes**: ¿Este cambio rompe algo existente?

Usa @AGENTS.md como referencia de convenciones.

Detección de anti-patrones

OpenCode identifica patrones problemáticos:

Busca anti-patrones comunes en estos cambios:

- Callback hell
- Promesas no awaiteadas
- Mutación de estado inmutable
- Side effects en funciones puras
- Magic numbers y strings
- Deep nesting
- Funciones demasiado largas (>50 líneas)
- Clases con demasiadas responsabilidades

Archivos: @src/services/OrderService.ts @src/lib/calculator.ts

Análisis de Seguridad

Vulnerabilidades comunes

[Plan Mode]

Revisa @src/api/auth.ts y @src/middleware/auth.ts por
vulnerabilidades de seguridad:

1. **Injection**: ¿Hay concatenación de strings en queries?
2. **XSS**: ¿El input del usuario se sanitiza antes de renderizar?
3. **CSRF**: ¿Hay protección CSRF en endpoints mutantes?
4. **JWT**: ¿Los tokens se validan correctamente? ¿Expiración adecuada?
5. **Secrets**: ¿Hay secrets hardcodeados?
6. **Rate Limiting**: ¿Hay protección contra brute force?
7. **Authorization**: ¿Se verifica que el usuario tenga permisos?
8. **Sensitive Data**: ¿Hay datos sensibles en logs o errores?

Sugiere fixes específicos para cada problema encontrado.

OpenCode detectará problemas como:

typescript
// ❌ Problema detectado
const query = `SELECT * FROM users WHERE email = '${email}'`;

// ✅ Fix sugerido
const query = 'SELECT * FROM users WHERE email = $1';
await db.query(query, [email]);

Hardcoded secrets

Busca secrets hardcodeados en el código:

- API keys
- Database URLs
- JWT secrets
- Passwords
- Tokens

Archivos: @src/ completo

Análisis de Performance

Optimizaciones sugeridas

[Plan Mode]

Analiza @src/components/DataTable.tsx y sugiere optimizaciones
de performance:

1. ¿Hay re-renders innecesarios?
2. ¿Se puede memoizar cálculos pesados?
3. ¿Hay operaciones en render que deberían ser en useEffect?
4. ¿Se puede usar virtualization para listas largas?
5. ¿Hay lazy loading posible?
6. ¿Se pueden usar React.memo en componentes hijos?

Mide el impacto de cada sugerencia.

Análisis de complejidad

Calcula la complejidad ciclomática de estas funciones:

- @src/services/PaymentService.ts:processPayment
- @src/lib/calculator.ts:calculateTax
- @src/utils/formatter.ts:formatDate

Si alguna función tiene complejidad > 10, sugiere cómo
reducirla extrayendo funciones.

Verificación de Tests

Cobertura de tests

[Plan Mode]

Verifica que los cambios en @src/services/UserService.ts
tienen tests adecuados:

1. ¿Todos los métodos nuevos tienen tests?
2. ¿Los tests cubren casos de éxito y error?
3. ¿Hay tests de edge cases?
4. ¿Los tests son independientes?
5. ¿Los tests usan datos realistas?

Si faltan tests, genera los tests necesarios.

Calidad de tests

Revisa los tests en @tests/unit/UserService.test.ts:

1. ¿Los nombres de tests son descriptivos?
2. ¿Los tests siguen Given-When-Then?
3. ¿Los mocks son apropiados?
4. ¿Los tests prueban comportamiento, no implementación?
5. ¿Hay tests duplicados?

Sugiere mejoras.

Code Review Diferencial

Comparación antes/después

[Plan Mode]

Compara la versión anterior y nueva de @src/lib/api.ts:

Versión anterior: @src/lib/api.ts (git HEAD)
Versión nueva: @src/lib/api.ts (modificado)

Analiza:
1. ¿Qué cambió?
2. ¿Los cambios son necesarios?
3. ¿Se introdujieron bugs?
4. ¿Se mejoró el código?
5. ¿Hay cambios que podrían revertirse?

Sugiere qué cambios mantener y cuáles revertir.

Impacto en dependientes

[Plan Mode]

Este cambio en @src/types/User.ts modifica la interfaz User.

Busca todos los archivos que dependen de User y verifica:
1. ¿Se rompe algo?
2. ¿Qué necesita actualizarse?
3. ¿Hay breaking changes no documentados?

Lista de archivos a actualizar:
- @src/services/UserService.ts
- @src/components/UserCard.tsx
- @src/api/users.ts

Workflows de Code Review

Workflow 1: Self-Review antes de PR

1. Hacer cambios
2. [Plan Mode] Pedir self-review a OpenCode
3. Corregir issues encontrados
4. Repetir hasta que OpenCode no encuentre issues críticos
5. Crear PR
6. Incluir en descripción: "Revisado con OpenCode, issues críticos: 0"

Workflow 2: Review de PR de otro desarrollador

1. Abrir PR
2. [Plan Mode] Pedir review completo a OpenCode
3. OpenCode genera reporte de issues
4. Revisor humano revisa el reporte
5. Revisor verifica issues críticos manualmente
6. Revisor aproueba o pide cambios basado en reporte

Workflow 3: Review de seguridad

1. Para PRs que tocan auth, payments, o datos sensibles
2. [Plan Mode] Pedir review de seguridad específico
3. OpenCode busca vulnerabilidades específicas
4. Si hay issues de seguridad, bloquear merge hasta corregir
5. Documentar fixes en commit message

Integración con CI/CD

Automatización en pipeline

[Plan Mode]

Genera un script de CI que ejecute OpenCode en cada PR:

1. Instalar OpenCode en CI
2. Ejecutar review automático en archivos cambiados
3. Si issues críticos > 0, fallar el build
4. Generar reporte en artefactos de CI
5. Comentar el reporte en el PR

Script: @scripts/opencode-review.sh

bash
#!/bin/bash
# @scripts/opencode-review.sh

CHANGED_FILES=$(git diff --name-only origin/main...HEAD)
CRITICAL_ISSUES=0

for file in $CHANGED_FILES; do
  if [[ $file == *.ts || $file == *.tsx ]]; then
    echo "Reviewing $file..."
    opencode review "$file" --critical-only
    if [ $? -ne 0 ]; then
      CRITICAL_ISSUES=$((CRITICAL_ISSUES + 1))
    fi
  fi
done

if [ $CRITICAL_ISSUES -gt 0 ]; then
  echo "Found $CRITICAL_ISSUES critical issues"
  exit 1
fi

Errores Comunes en Code Review

ErrorCausaSolución
False positivesOpenCode no entiende contexto del proyectoAñade más contexto en AGENTS.md
Issues genéricosPrompt demasiado amplioEspecifica qué revisar exactamente
Ignora convencionesNo se referencia AGENTS.mdSiempre incluye @AGENTS.md en prompts
No detecta bugsCambios muy complejosDivide review en partes más pequeñas
Sugerencias irrelevantesOpenCode no conoce dominioDocumenta dominio en AGENTS.md

Métricas de Code Review

OpenCode puede generar métricas:

[Plan Mode]

Analiza este PR y genera métricas:

- Líneas de código añadidas
- Líneas de código eliminadas
- Complejidad ciclomática promedio
- Número de funciones modificadas
- Coverage de tests de archivos modificados
- Número de dependencias añadidas
- Número de dependencias eliminadas
- Tiempo estimado de review humano

Compara con el promedio del proyecto.

Conclusión

El code review con OpenCode requiere:

  1. Contexto rico: AGENTS.md bien documentado es esencial
  2. Prompts específicos: Define exactamente qué revisar
  3. Juicio humano: OpenCode es asistente, no reemplazo
  4. Iteración: Usa feedback para mejorar prompts
  5. Integración: Automatiza en CI/CD para consistencia

En Binary Core, redujimos el tiempo de code review en un 50% y detectamos 40% más bugs antes de merge usando OpenCode como primer revisor. La clave no es reemplazar humanos, sino amplificar su capacidad: OpenCode encuentra lo obvio, humanos enfocan en lo complejo.

¿Listo para especializar tu flujo? Aprende workflows especializados por dominio.

Serie completa:

  1. Instalación y primeros pasos
  2. Flujo de trabajo Plan/Build
  3. Configuración avanzada
  4. Debugging
  5. Refactors
  6. Generación de tests
  7. Code review (este artículo)

Binary Core

Equipo Binary Core

← Back to blog