DEV Community

Cover image for Formas sencillas de prevenir o reducir la deuda técnica
Gabriel Manzur for JavaScript Chile

Posted on

Formas sencillas de prevenir o reducir la deuda técnica

El origen de la deuda técnica es una mezcla de distintos fenómenos en variadas proporciones:

  1. Herramientas obsoletas o en proceso de quedar obsoletas (entiéndase que ya no reciben nuevas actualizaciones).
  2. Bajos estándares de desarrollo.
  3. Problemas de liderazgo.
  4. Diseño deficiente.
  5. Tiempos de entrega mal calculados.
  6. Estrés.
  7. Poca experiencia del desarrollador.
  8. El simple paso del tiempo.
  9. Rotación en el equipo.
  10. Mezcla de tecnologías.

Y seguramente podríamos pensar en muchas más...

Todos en una empresa de tecnología pueden colaborar de una forma u otra en la creación de un ambiente propicio para la expansión descontrolada de la deuda técnica.

A pesar de que sea un fenómeno inevitable en el mundo del software, cada miembro del equipo puede, según su posición, contribuir significativamente a reducir la velocidad en que la deuda técnica crece, y a reducirla cuando sea propicio.

En mi experiencia estas son las principales acciones que pueden realizar los programadores, según su rol y experiencia, para intentar controlar la deuda técnica, y que no requieren un esfuerzo demasiado significativo:

Desarrolladores Trainee/Junior:

  • Antes de comenzar a programar una tarea buscar entender el problema. Si la solución no es obvia entonces buscar de forma temprana la opinión general de alguien más senior. Esta búsqueda de opinión y consejo debe dejar explícito de que haz hecho una investigación previa significativa.
  • Si en el proyecto en que trabajas existe más de una forma de solucionar parte de tu tarea pregunta a tu equipo cual es la preferible.
  • Una vez que el código funciona y los tests están escritos el trabajo aún no termina: ahora es el momento de revisar con detalle tu trabajo, mejorar la legibilidad y estandarizar las prácticas en relación a las recomendaciones y usos de tu equipo.
  • Nunca agregar nuevas librerías/herramientas sin antes consultar a alguien más senior.
  • Usar bien el tiempo y comenzar tempranamente a desarrollar la feature: El apuro produce malos resultados.

Desarrolladores Semi-senior/Senior

  • Siempre dejar el código en mejor estado de cómo lo encontraste
  • Evitar abstracciones y soluciones complejas cuando sea posible.
  • Aprender a decir "SI, PERO". Si tus manos ya están ocupadas en una feature y te piden comenzar otra, deja claro que la primera quedará en pausa y su fecha de entrega será atrasada, o cómo el aumento de carga puede perjudicar el resultado final.
  • Al diseñar una nueva feature, siempre intentar ser lo más generalista posible, intentando prever nuevos requerimientos que puedan aparecer en el futuro, y no limitarse a satisfacer los requerimientos mínimos que están siendo solicitados. Esto no quiere decir que debemos programar de más, sino que nuestros diseños deben estár preparados para extenderse y cubrir nuevos casos sin grandes refactorizaciones. Por ejemplo si en nuestra aplicación nos piden que se puedan crear configuraciones para TODOS o para UN usuario, no olvidar que en el futuro nos podrían pedir crear una configuración para un GRUPO determinado de usuarios.

Líderes técnicos y similares

  • Proteger al equipo de desarrollo frente al resto de la empresa. No permitir que los equipos de ventas/soporte/etc les hagan solicitudes si no es pasando por ti como intermediario.
  • Procurar que la creación de test unitarios robustos sea una práctica requerida en el equipo, y que estos corran de manera automatizada al realizarse el pull request.
  • Al momento de elegir nuevas herramientas y tecnologías es sano evitar soluciones muy novedosas. Siempre es más seguro elegir herramientas que, aunque parezcan complicadas a primera vista, poseen una gran comunidad de desarrolladores y de soporte detrás de ellas, lo que asegura que seguirán vigentes por un tiempo razonable.
  • Si el problema de la deuda técnica es muy recurrente en las reuniones de equipo, retros, etc... Probablemente es tiempo de tener a un programador dedicado a este tema, o implementar algún tipo de rotación en este rol. Esto es, al largo plazo, una inversión financieramente inteligénte, pero más aún, una señal de respeto y consideración a la salud mental y satisfacción laboral de nuestros colegas.

En fin, este es un listado de acciones de relativamente sencilla implementación, que sin duda colaborarán a crear un ambiente donde el resultado de nuestro trabajo no sea una permanente fuente de frustraciones, sino que, al menos a ratos, nos haga sentir orgullosos.

Top comments (0)