Este episodio del podcast Bri Show, presentado por @jpblancodb⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ y ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@matheusmarabesi, se centra en las ventajas y desventajas del Desarrollo Guiado por Pruebas (TDD). Los presentadores discuten los numerosos beneficios del TDD, incluyendo:

● Reducción de errores: El TDD ha demostrado reducir los errores en el código, con datos que respaldan esto tanto en entornos estudiantiles como profesionales.

● Mejora en el diseño: Aunque reconocen que las opiniones difieren sobre la influencia del TDD en el diseño, los presentadores sugieren que puede llevar a mejores diseños al requerir que los desarrolladores consideren la capacidad de prueba desde el principio.

● Mayor mantenibilidad y refactorización: El TDD fomenta la creación de código modular y acoplado de manera flexible, lo que facilita su refactorización y mantenimiento. Los presentadores destacan que la refactorización es casi imposible sin pruebas.

● Mejor trabajo en equipo: El TDD promueve una mejor comunicación y colaboración en los equipos de desarrollo. Trabajar juntos en las pruebas ayuda a los equipos a construir una comprensión compartida de la base de código, lo que facilita la identificación y solución de posibles problemas.

● Mayor confianza y reducción de riesgos: El TDD proporciona una red de seguridad, lo que permite a los desarrolladores realizar cambios con confianza. Esto se debe a que las pruebas actúan como una suite de regresión, asegurando que la funcionalidad existente permanezca intacta a medida que se agrega o modifica nuevo código.

Sin embargo, existen desafíos y conceptos erróneos con el TDD:

● Inversión de tiempo: Los presentadores reconocen que el TDD requiere un compromiso inicial de tiempo, lo que podría ser una barrera para algunos desarrolladores o equipos. No obstante, argumentan que esto se compensa a largo plazo con una reducción en la depuración y un aumento en la calidad del código.

● Curva de aprendizaje: El TDD puede ser difícil de aprender, especialmente para desarrolladores nuevos en las pruebas. Los presentadores recomiendan comenzar con enfoques de prueba más simples, como escribir pruebas después de la implementación, para luego hacer la transición gradual al TDD.

● Uso excesivo y obsesión: Aunque abogan por el TDD, los presentadores advierten contra su uso excesivo o la obsesión con las métricas de cobertura de código. Enfatizan usar el TDD con juicio, centrándose en pruebas que brinden el mayor valor y evitando pruebas innecesarias.

● Resistencia cultural: Implementar el TDD de manera efectiva a menudo requiere un cambio en la cultura del equipo y en las prácticas organizacionales. Los presentadores subrayan la necesidad de obtener el apoyo de todos, incluido el liderazgo, para garantizar que la adopción del TDD esté alineada con los objetivos y prioridades del negocio.

Como siempre, nuestras redes:

Juan Pablo Blanco: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@jpblancodb⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

Matheus Marabesi: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@matheusmarabesi

En este episodio, Matheus Marabesi y Pela regresan después de una pausa para discutir temas relacionados con el rol del Product Manager (PM) en el desarrollo de software. Exploran las diferencias entre el Product Manager estratégico y el más operativo, destacando la importancia de aportar verdadero valor en el contexto en que se encuentran. A lo largo de la conversación, abordan la relevancia de evaluar continuamente el impacto de las decisiones de producto y la necesidad de eliminar características que no generen valor. También reflexionan sobre las responsabilidades y retos de los PMs, incluyendo la importancia de entender tanto el aspecto técnico como el impacto a largo plazo de sus decisiones.

Como siempre, nuestras redes:

Javier Chacana: @jchacana

Juan Pablo Blanco: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@jpblancodb⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

Matheus Marabesi: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@matheusmarabesi

Como siempre, nuestras redes:

Javier Chacana: @jchacana

Juan Pablo Blanco: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@jpblancodb⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

Matheus Marabesi: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@matheusmarabesi