Busca en todas las páginas de la documentación
La revisión de código es el principal bucle de enseñanza del equipo para la artesanía en Python: tipos, trampas asíncronas, seguridad SQL y lagunas de pruebas. Una cultura de alta señal significa estándares claros, retroalimentación respetuosa y plazos de entrega predecibles, no un perfeccionismo que bloquea la entrega.
Tarjeta de receta de referencia rápida, lista para copiar y pegar.
## Plantilla de descripción de PR
**Intención:** una frase
**Riesgo:** indicador de migración / rendimiento / seguridad
**Evidencia de prueba:** ruta de pytest, captura de pantalla, nota de carga
**Reversión:** plan de indicador o reversión
## Niveles de comentarios de revisión
🔴 Debe arreglarse - corrección, seguridad, pérdida de datos
🟡 Debería arreglarse - claridad, prueba faltante (el autor puede posponer con un ticket)
🟢 Detalle menor - estilo; a discreción del autorCuándo recurrir a esto:
# El autor aborda la revisión con un comentario de intercambio explícito
# REVISIÓN: se mantuvo el ORM síncrono aquí intencionalmente - RFC-042 fase 1 de solo lectura.
# La migración asíncrona se rastrea en ENG-4412.
def get_catalog_item(item_id: str) -> dict[str, object]:
...## Lista de verificación del revisor (Python)
- [ ] Tipos en funciones públicas / modelos Pydantic validados
- [ ] No hay I/O bloqueante en async def sin asyncio.to_thread
- [ ] Consultas a la base de datos parametrizadas; sin concatenación de SQL con cadenas
- [ ] Las pruebas cubren la ruta feliz + un modo de fallo
- [ ] El registro está estructurado; sin PII en los mensajesLo que esto demuestra:
uv run pytest.| Tamaño de la PR | Respuesta inicial objetivo |
|---|---|
| < 200 LOC | Mismo día hábil |
| 200-500 LOC | 24 horas |
| > 500 LOC | El autor debería dividir |
# pyproject.toml - dejar que CI aplique el estilo para que la revisión se centre en el diseño
[tool.ruff]
line-length = 100
select = ["E", "F", "I", "UP", "B", "ASYNC"]| Alternativa | Usar Cuándo | No Usar Cuándo |
|---|---|---|
| Programación en parejas | Código nuevo complejo | CRUD simple con pruebas |
| Sesión de revisión en grupo | Cambio de arquitectura | PRs pequeñas diarias |
| Bots de aprobación automática | Error tipográfico en documentación | Lógica de aplicación |
| Inspección formal | Seguridad regulada | Velocidad normal del producto |
Uno para lo rutinario; dos para seguridad, migraciones o bibliotecas compartidas.
Para cambios arriesgados sí; de lo contrario, confíe en CI si las pruebas son exhaustivas.
El autor responde con el razonamiento; escalar al líder técnico si hay un punto muerto.
Sí - verificar el bloqueo del bucle, la configuración del pool y el indicador de reversión.
Revisar las entradas y plantillas del generador, no cada línea de salida.
Centrarse en la fuga de datos, la no determinismo y la ruta de promoción a producción.
Límite blando de 400 LOC cambiados; las excepciones necesitan enlace RFC.
Nunca ser el único aprobador; el autor puede fusionar solo después de la aprobación de otro.
Tiempo hasta la primera revisión, relación de niveles de comentarios, tasa de defectos posteriores a la fusión.
Usar para pasar la lista de verificación; el humano es responsable de la seguridad y la corrección del dominio.
Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.
Revisado por Chris St. John·Última actualización: 16 jul 2026