The latest articles on DEV Community by Gabriel Manzur (@gmanzur). https://dev.to/gmanzur https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1125878%2F0011b4d0-cef4-498e-a78f-362d56ea8600.jpeg https://dev.to/gmanzur en Gabriel Manzur Sun, 07 Jan 2024 22:32:26 +0000 https://dev.to/javascriptchile/prevencion-de-la-deuda-tecnica-1h02 https://dev.to/javascriptchile/prevencion-de-la-deuda-tecnica-1h02 <p>El <strong>origen de la deuda técnica</strong> es una mezcla de distintos fenómenos en variadas proporciones:</p> <ol> <li>Herramientas obsoletas o en proceso de quedar obsoletas (entiéndase que ya no reciben nuevas actualizaciones).</li> <li>Bajos estándares de desarrollo.</li> <li>Problemas de liderazgo.</li> <li>Diseño deficiente.</li> <li>Tiempos de entrega mal calculados.</li> <li>Estrés.</li> <li>Poca experiencia del desarrollador.</li> <li>El simple paso del tiempo.</li> <li>Rotación en el equipo.</li> <li>Mezcla de tecnologías.</li> </ol> <p>Y seguramente podríamos pensar en muchas más...</p> <p>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. </p> <p>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. </p> <p>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:</p> <p><strong>Desarrolladores Trainee/Junior:</strong></p> <ul> <li>Antes de comenzar a programar una tarea buscar entender el problema. Si la solución no es <strong>obvia</strong> entonces buscar de forma temprana la opinión <strong>general</strong> 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.</li> <li>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. </li> <li>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.</li> <li>Nunca agregar nuevas librerías/herramientas sin antes consultar a alguien más senior.</li> <li>Usar bien el tiempo y comenzar tempranamente a desarrollar la feature: El apuro produce malos resultados.</li> </ul> <p><strong>Desarrolladores Semi-senior/Senior</strong></p> <ul> <li>Siempre dejar el código en mejor estado de cómo lo encontraste</li> <li>Evitar abstracciones y soluciones complejas cuando sea posible.</li> <li>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. </li> <li>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. </li> </ul> <p><strong>Líderes técnicos y similares</strong></p> <ul> <li>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.</li> <li>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.</li> <li>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. </li> <li>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.</li> </ul> <p>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. </p>