|
Estoy seguro de que como desarrollador de software piensas que en tu empresa se pueden hacer mejor las cosas en lo que se refiere al código. Conozco muy pocas personas que piensen que en su empresa todo es de color de rosa. Es habitual leer o escuchar excusas de tipo hay que cumplir fechas, el cliente no sabe lo quiere, el cliente cambia los requisitos, el código es un desastre y ya ni hablemos del testing. Eso esa muy bien, pero te estás enfocando en lo externo. La pregunta que deberías hacerte es: ¿Qué puedes hacer tú para mejorar el desarrollo de software en tu empresa con ese contexto? Y además, si consigues encontrar soluciones a los problemas en el proceso de desarrollo, ¿lo harías público? Pues eso es lo que hizo Etsy. Etsy, la popular plataforma de comercio electrónico para productos hechos a mano, encontraron su talón de Aquiles. Su conjunto de tests automatizados era tan lento y frágil que los desarrolladores dejaron de confiar en él. La suite de tests tardaba horas en ejecutarse, lo que retrasaba la entrega de nuevas funcionalidades. Se producían falsos positivos y falsos negativos, lo que llevaba a los desarrolladores a ignorar los fallos o a gastar mucho tiempo investigándolos sin razón. Esto generaba una gran resistencia a hacer cambios en el código, porque los tests fallaban incluso cuando no había errores reales. Los ingenieros de Etsy empezaron a hacer despliegues manuales sin ejecutar todos los tests, aumentando el riesgo de errores en producción. Perdieron agilidad y confianza en su software, lo que afectó su capacidad de innovar rápidamente. El crecimiento de la empresa se ralentizó, ya que cada cambio requería demasiado esfuerzo para validarse correctamente. ¿Cómo lo solucionaron? Etsy abordó el problema adoptando una estrategia radical: - Refactorización de los tests
- Se enfocaron en los tests que no se rompían fácilmente y que generaban más confianza
- Mejora en la velocidad de ejecución
- Apostaron por la cultura de confianza en los tests
Este cambio permitió a Etsy implementar Continuous Deployment con confianza, logrando más de 50 despliegues al día sin miedo a romper producción. La clave para conseguirlo fue una mejora radical en la suite de tests. Este caso muestra cómo una suite de tests mal diseñada puede generar pérdidas indirectas al ralentizar el desarrollo, aumentar el riesgo de errores en producción y generar resistencia al cambio en los equipos de desarrollo. Todo esto lo tienen documentado en diferentes charlas, presentaciones y en su blog. Saber crear los mínimos tests que generen la máxima confianza es crucial para adoptar prácticas como Continuous Deployment. Saber crear estos tests, es lo que te enseño a hacer en mi master class. Recuerda que si compras antes de que quite la master class de la venta (el 14 de febrero), te llevas un regalo (el 15 de febrero). Un audio donde respondo a dudas que me han hecho llegar alumnos sobre la master class. Si te interesa mejorar los problemas en tu día a día con el código: Master Class - Testing Basado en Pilares Pd: La master class estará disponible hasta el 14 de febrero. Al día siguiente quitaré la master class de la venta y enviaré el audio respondiendo a las dudas que he recopilado de alumnos. Un audio que no volveré a mandar. Pd2: Si te gustan mis emails, habla bien y comparte xurxodev.com para que otros lo disfruten. Pd3: Si no te gustan mis emails, habla mal y comparte xurxodev.com para evitar que otros lo sufran.
|