¿Para qué sirve la refactorización de bases de datos? ¿Qué riesgos conlleva y cómo puedo evitarlos? ¿Es realmente beneficiosa para mis sistemas? Cameron Raw, software craftsperson en Codurance, responde a estas preguntas en una sesión en la que también presenta varias estrategias de mitigación de riesgos, junto con ejemplos y recomendaciones que puedes empezar a aplicar en tu equipo de desarrollo.
Beneficios de la refactorización de bases de datos
Las razones para refactorizar las bases de datos pueden ser muy similares a las que nos llevan a refactorizar el código de las aplicaciones.
- Mejorar el rendimiento de la base de datos.
- Reducir la complejidad.
- Añadir funcionalidad al sistema.
- Eliminar la deuda técnica.
Riesgos de la refactorización de bases de datos
Por muy grandes que sean los beneficios de una refactorización, debemos tener mucho cuidado con el gran riesgo que supone cuando se hace de forma incorrecta ya que podría llevar a algunos de errores:
- Pérdida de datos. Riesgo muy elevado, especialmente en función de la industria y los riesgos legales asociados, como en el sector sanitario.
- Error de aplicación. Las características de la aplicación lanzan error.
- Problemas de rendimiento.
- Tiempo de inactividad. Puede formar parte de tu estrategia o convertirse en un riesgo cuando provoca la caída del sistema.
- Refactorización incompleta. Si tienes estados incoherentes en toda la base de datos, se producirán problemas de funcionalidad.
¿Cómo obtener los beneficios y evitar los riesgos?
La refactorización de una base de datos es una operación de gran envergadura en la que intervienen equipos técnicos y no técnicos. Cameron explica que es fundamental contar con un plan de acción claro centrado tanto en el área de negocio como en el área técnica.
El plan de acción centrado en la empresa consiste en una comunicación constante con los stakeholders para que comprendan los riesgos que implica el proyecto, los pasos que hay que tomar, las competencias necesarias, los plazos de entrega, etc. Al mismo tiempo, esta conversación y planificación también es valiosa para que el equipo de desarrollo unifique el proceso a seguir y determine múltiples variables como los KPIs, los plazos, las prácticas a utilizar, etc. En esta línea, el craftsperson ofrece consejos sobre cómo gestionar con éxito ambos planes de acción:
Consejos para el plan de acción enfocado en el negocio
- Comunicación constante con los stakeholders.
- Comprender cuándo es el mejor moment para llevar a cabo la refactorización (con el fin de tener el menor impacto en las operaciones habituales).
- Definir de forma clara y precisa lo que esperamos de la refactorización y lo que consideraríamos una refactorización satisfactoria.
Consejos para el plan de acción enfocado en el área técnica
- Comprender en profundidad el estado actual de la base de datos y tener una idea clara de cuál es la línea de base con respecto a las métricas.
- Dedicar mucho tiempo a planificar y probar los procesos de recuperación en caso de que ocurra lo peor.
- Contar con una estrategia de pruebas sólida para poder juzgar con mayor precisión si las cosas funcionan según lo esperado.
La importancia del Testing
Antes de refactorizar, debemos asegurarnos de tener una estrategia de testing sólida que nos aporte confianza durante todo proceso de refactorización. También debemos mantenernos en contacto permanente con el equipo de control de calidad (QA), ya que ellos saben cómo inspeccionar mejor nuestro sistema a medida que se aplican los cambios.
Los test, como en cualquier refactorización, son esenciales para garantizar que el sistema mantiene el comportamiento deseado.
- Cameron Raw, software craftsperson en Codurance
Las pruebas automatizadas pueden tener una complejidad añadida si nos estamos moviendo a través de una refactorización iterativa, pero es importante recordar que aprovechando el poder de los pipelines de testing modernos, podemos producir soluciones de testing creativas que nos harán sentirnos seguros en nuestra refactorización de bases de datos, explica Cameron.
Recomendaciones finales
Refactorizar bases de datos no es, desde luego, un proceso sencillo ni corto, pero si se mantiene un buen flujo de comunicación y una estrategia en la que todas las partes estén en la misma página y alineadas, la tarea será más fácil de manejar. Cameron ofrece algunos consejos finales a tener en cuenta:
- Mantener una comunicación constante y transparente con todos los stakeholders, miembros del equipo de desarrollo y QA.
- Establecer un entendimiento común del rendimiento actual de la base de datos para poder comparar con precisión las mejoras y métricas a lo largo del camino.
- ¡Estrategia de testing, estrategia de testing, estrategia de testing!
Si deseas revisar más blogs sobre metodologías, lenguajes de programación y gestión de equipos, visita nuestros Insights. Aquí tienes también nuestro playlist sobre Testing y TDD por si quieres profundizar tus conocimientos en testing.
