Hablemos sobre deuda técnica
Contenido del curso
Escribiendo pruebas
Pruebas Unitarias
Integration Test & E2E
UI Test
Automatizar
Hablemos sobre deuda técnica
Hablemos sobre deuda técnica
Contenido del curso
Edgar Mauricio Pérez Rojas
Cesar Enrique Velasquez Galvis
Carlos Vera
Oscar Fuentes Esteves
Iván Antonio Bustos Calderón
Rubens Gomez
Jimer Samuel Espinoza
Nicolas Molina
Profesor
Marco Antonio Alducin Garcia
Jefred Bedoya
Jose Tellez
Deuda Técnica Igual que en las finanzas, las deudas no son buenas ni malas, solo son una estrategia para alcanzar algo y luego se paga.
haciendo pruebas se maneja el riesgo
El momento y pruebas dependen de la fase en la que se encuentra la compañía:
La deuda de deficiencia del desarrollador puede ser alta porque en la fase de tracción, la compañía busca velocidad > precisión , de modo que en esta etapa el testing no se valora, ya que buscan lanzar, lanzar, lanzar...
Cuando se entra a la fase de inflexión, hay más usuarios y se empiezan a escribir más pruebas, curando la deuda.
¿Y si la compañía somos nosotros mismos como developers? se me ocurre que cuando estamos dando nuestros primeros pasos en software es importante tener tracción y avanzar rápido para no aburrirnos o frustarnos, con el tiempo vamos reduciendo nuestra propia deuda técnica en los proyectos que desarrollamos.
Muy interesante la forma en la que lo ves estimado.
Un video del profe @gndx donde explica la deuda técnica.
Excelente clase Nicolás!, estos temas son tal vez, más importantes que solo preocuparnos de hacer buen código.
me gusto el grafico de madurewz de la compa;ia, pero falto mas detalle de la escala y expansion ?
Entonces en la etapa de traccion es mas probable encontrarse bugs/ fallos en produccion?
Si es esa parte, es más importante la velocidad que sobre precisión, entonces es normal que haya mayor probabilidad de bugs, ya que no se han implementado todos esos sistemas aun.
Lo que puedo entender, es que la deuda técnica es aquella que se paga, a medida de que mientras no se hagan pruebas de lo que se está desarrollando y nos aseguramos de una buena calidad, funcionamiento y una buena usabilidad en el producto, se va acumulando un costo a largo plazo donde afecta las finanzas de la empresa, en el punto en qué, si sale un error en algún módulo, o no funcione alguna sección, por ejemplo, un pago no se haga, o que no entre a la aplicación o no inicie sesión, o que no entre o algo más grave, se le cae el sistema, las pérdidas económicas serán caóticas y serán negativas para la misma, por ejemplo, se pierda un cliente potencial que pueda pagar el producto y/o servicio, o que se pierda dinero en el proceso o algo así. Espero y alguien me comenté que si mi percepción es correcta.
¿Qué es la Deuda Técnica?
Es la diferencia entre la solución rápida (pero subóptima) y la solución ideal (arquitectónicamente correcta). Es un préstamo que pides al futuro: entregas valor hoy a cambio de pagar "intereses" (esfuerzo extra) después.
Gestión de la Deuda
El costo de los intereses
Si no pagas la deuda refactorizando, el código se vuelve rígido y frágil. Los intereses se acumulan: cada nueva funcionalidad es más lenta y costosa de implementar.
La clave no es evitar la deuda, es gestionarla. Si la deuda supera tu capacidad de pago, tu proyecto colapsa.
Esta clase me hizo dudar sobre si debería seguir con este curso. En la startup en la que estoy estamos en fase de lanzar, lanzar, lanzar y lanzar cosas. Venía con la idea de que el testing podría ayudarme a agilizar el hacer pruebas para detectar bugs, pero ya tendré que ver si me lleva mucho tiempo hacer los test, quizá dejarlos para un poco más adelante