38 lines
3.1 KiB
Markdown
38 lines
3.1 KiB
Markdown
# Auditoría de Código y Mejores Prácticas
|
|
|
|
Este documento consolida los hallazgos de los agentes de validación (Calidad de Código y Mejores Prácticas Django) tras analizar el ERP.
|
|
|
|
## 🔴 Riesgos Críticos (Corregir Inmediatamente)
|
|
|
|
### 1. Peligro de Pérdida de Datos Financieros
|
|
Se están utilizando relaciones de base de datos con `on_delete=models.CASCADE` en registros críticos.
|
|
- **Riesgo**: Si se elimina un Proveedor, Django eliminará silenciosamente todas las Órdenes de Compra asociadas a él. Si se elimina el perfil de un Empleado, se borrarán todos sus registros de sueldo (`SalarySlip`) del sistema.
|
|
- **Solución**: Cambiar a `models.PROTECT` para prohibir la eliminación de entidades si tienen transacciones asociadas, o implementar un modelo de *Soft-Delete* (borrado lógico).
|
|
|
|
### 2. Cuellos de Botella (Consultas N+1)
|
|
Supabase (y las bases de datos en la nube en general) son muy sensibles a la latencia de red. El código actual realiza demasiadas consultas ocultas a la base de datos:
|
|
- **`project_list.html`**: La vista hace el trabajo correcto al usar `.annotate(total_expenses=Sum(...))` para calcular los gastos totales de un proyecto en una sola consulta. Sin embargo, **el template HTML ignora esta anotación** y llama a `{{ project.total_expenses_clp }}`, el cual es un `@property` del modelo que dispara un `.aggregate()` por cada proyecto en la pantalla. Si hay 50 proyectos, se hacen 100 consultas SQL a Supabase en lugar de 1.
|
|
- **CSV Export**: Falta hacer `select_related('vendor')`, lo que dispara consultas N+1 al exportar los gastos.
|
|
|
|
### 3. Excepciones Silenciosas (Código Traga-Errores)
|
|
En `expenses/views.py` y `expenses/forms.py` se abusa de `except Exception: pass`.
|
|
- **Riesgo**: Si falla la eliminación de un archivo en S3 o si hay un error de validación, el código falla silenciosamente. Será imposible encontrar el error porque no quedará registrado en ningún Log.
|
|
- **Solución**: Capturar excepciones específicas y utilizar el módulo `logging`.
|
|
|
|
---
|
|
|
|
## 🟡 Deuda Técnica (Refactorización)
|
|
|
|
### 1. Desorden en la Raíz del Proyecto
|
|
La carpeta raíz del proyecto tiene mucha "basura" (`seed_all.py`, `patch_models.py`, `refactor_oop.py`).
|
|
- **Solución**: Mover todos los scripts de parcheo a una carpeta temporal, y los scripts de inicialización de datos (seeds) refactorizarlos hacia Comandos de Administración de Django (`management/commands/`).
|
|
|
|
### 2. Plantillas Faltantes (Templates 404)
|
|
El módulo de Adquisiciones (`procurement/views.py`) intenta renderizar `requisition_detail.html` y `purchase_order_detail.html`, pero estos **archivos no existen**. Al navegar a esas rutas, la aplicación se caerá con un error `TemplateDoesNotExist`.
|
|
|
|
### 3. Índices de Base de Datos
|
|
Falta añadir `db_index=True` a campos de búsqueda intensiva, como la `fecha` de los Gastos o el `status` de las órdenes.
|
|
|
|
### 4. Falta de consistencia en Herencia
|
|
Algunos módulos (Nóminas y Adquisiciones) reescriben los campos `created_at` y `updated_at` manualmente en cada modelo, en lugar de heredar del `TimeStampedModel` base que ya se programó en la App de Gastos.
|