Cómo evaluar, administrar y evitar deudas técnicas
Publicado: 2020-05-26Si la deuda técnica suena como sacada de un manual de finanzas es porque el término está relacionado con las finanzas. Sin embargo, en el sentido real de la misma, la deuda técnica está relacionada con la programación. Es la idea de que durante el desarrollo de un proyecto de software, se omiten ciertos pasos necesarios, o simplemente se descartan por completo en un intento por cumplir con un plazo.
En un intento por desarrollar la aplicación o el software perfecto, los desarrolladores a menudo tienen poco tiempo, al igual que cualquier persona al azar que realiza cualquier tarea arbitraria de todos modos. Por lo tanto, por lo general tiene sentido tener algún tipo de compromiso entre entregar un producto perfecto con código perfecto y maximizar el tiempo.
La pregunta entonces es: ¿hay un límite para estas compensaciones? ¿Hay daños inherentes que podrían resultar de esta compensación? Finalmente, ¿el desarrollador está realmente mejor a largo plazo? En este artículo sobre deudas técnicas, intentaré responder a todas estas preguntas.
¿Qué es la deuda técnica?
Al definir la deuda técnica, tendremos que referirnos al hombre al que se atribuye haber generado el término en primer lugar: Ward Cunningham. Según Cunningham, la deuda técnica se refiere al trabajo de desarrollo adicional que se debe realizar para programar un código para compensar el déficit que surge de programarlo en un período corto.
Para hacerlo más gráfico, imagina que tienes la tarea de limpiar una habitación desordenada y llegas tarde a una clase. En un intento por asegurarse de llevar a cabo las instrucciones y llegar a tiempo a su clase, hace una limpieza rápida y barre la mayor parte de los escombros debajo del sofá. La consecuencia de esto es que eventualmente tendrá que tomarse el tiempo para ordenar el desorden. Para el desarrollo de software, cuando se salta los pasos necesarios y sigue una ruta más fácil, con códigos 'no tan limpios', será más difícil limpiar el código más adelante en el futuro. Hay múltiples fases encontradas en el dominó del proyecto de software, y cuanto más tiempo ignore un problema existente, más tiempo llevará resolverlo.
Tipos de Deudas Técnicas
Las deudas técnicas son de diferentes tipos, entre ellas:
Deudas Técnicas Previstas
Esto ocurre en situaciones en las que las organizaciones deciden deliberadamente contraer deudas técnicas. Esto, como se discutió anteriormente, generalmente es para superar los plazos establecidos y llegar a una meta específica. Al comprometerse con deudas técnicas planificadas, la organización debe tener claro a qué está dispuesta a ceder y a qué no. Debe mantener registros precisos, teniendo en cuenta que eventualmente tendrá que regresar y corregir los errores que saltó al principio.
Deudas técnicas no intencionales
Este tipo de deuda técnica es directamente opuesta a la primera. Surge cuando una organización no prevé ni planifica la deuda técnica. La razón de esto suele ser una falla en la comunicación entre las distintas unidades de la organización, o malas prácticas de trabajo entre las unidades.
Deudas Técnicas Ineludibles
Este es el tipo de deuda técnica que ninguna acción por parte de la organización podría haber evitado. Por ejemplo, con los rápidos cambios experimentados en la tecnología, tiene sentido que algunos códigos escritos en el pasado no alcancen los estándares actuales proyectados.
Además, este tipo de deuda técnica puede surgir cuando se solicitan cambios cuando el código ya se está escribiendo. Si a mitad de camino en el diseño del software, se introducen ciertos cambios, podría estropear la dinámica, haciendo que el código antiguo se vuelva obsoleto o innecesario.
Causas de la Deuda Técnica
Algunas de las razones de la deuda técnica se han discutido anteriormente, pero las seleccionaré una tras otra para aclararlas.
Prisa
La causa más frecuente de la deuda técnica es la prisa. Los desarrolladores a menudo tienen plazos estrictos, algunos de los cuales incluyen plazos para lanzar cierto software. A menudo es comprensible (y esperado) en este tipo de situaciones que el desarrollador pueda incurrir en deudas técnicas en el camino. Este tipo de deuda técnica a menudo es intencional y puede dar lugar a problemas que pueden ir desde errores en el código o la aparición de códigos spaghetti.
Descuido/Error
A veces, los programadores simplemente escriben códigos incorrectos, lo que eventualmente genera deudas técnicas. Independientemente de si el código incorrecto existe como resultado del error del codificador o no, el hecho es que los errores generan deudas técnicas y, debido a que no son escalables, eventualmente tendrán que corregirse.
Falta de conocimiento de los efectos
A veces, las deudas técnicas surgen porque el codificador no se da cuenta o no reconoce cuán dañinas son las deudas técnicas a largo plazo. Esto podría provenir de una ignorancia legítima de los efectos dañinos de tomar atajos durante la programación, o podría ser una indiferencia deliberada de las consecuencias.
Intención
Las deudas técnicas pueden surgir intencionalmente por las acciones deliberadas del codificador o la organización.
Falta de modularidad
Esto surge principalmente porque un código puede servir para diferentes lógicas comerciales al mismo tiempo. Este tipo de situación hace que el manejo del software sea mucho más difícil. Con cada código que escribe un desarrollador, hay más posibilidades de que experimenten desafíos con la modularidad.
Evaluación de Deuda Técnica
Las deudas técnicas nunca deben calcularse manualmente porque sería bastante arduo. Supondría tener que introducir manualmente el código para determinar los problemas actuales y los posibles futuros. Aparte de la pérdida de tiempo que supone el proceso manual, existe la posibilidad de que los códigos hayan cambiado de forma al final del proceso manual.
Una forma de llevar a cabo la evaluación es mediante la realización de un análisis estático utilizando algunas herramientas que lo soporten. Algunas de las herramientas que se pueden usar incluyen Coverity, SonarQube, Check Style y Closure Compiler.
Generalmente, existen dos formas de calcular las deudas técnicas. En el primer enfoque, podría obtenerse calculando el índice de deuda técnica según el índice de código. En este caso, la estimación inicial o el tiempo total necesario para desarrollar la aplicación se utilizaría para determinar el tiempo necesario para solucionar la deuda técnica.
En el segundo enfoque, podría utilizar directamente las estimaciones proporcionadas por las diversas herramientas, como SonarQube. Esto se combinará con las listas de las deudas técnicas, así como sus códigos de referencia. A partir de las herramientas, puede obtener una estimación precisa del tiempo necesario para solucionarlo.
La evaluación de la deuda técnica le dará una idea de cuántos días llevará arreglar la deuda técnica. Cuantas más deudas haya, más tiempo te llevará arreglarla.
Resolución de deudas técnicas
¿Qué sucede si se han producido deudas técnicas y no sabe qué hacer? Hay ciertos pasos que puede seguir para administrar las deudas técnicas.
En primer lugar, debe reconocer que las deudas técnicas existen y comunicarlas a su equipo. Al comunicarse, debe tener claro lo que ha sucedido y lo que debe hacerse para corregirlo. Debe asegurarse de comunicar claramente la necesidad de hacerse cargo de la deuda técnica lo antes posible.
Después de informar a su equipo de las deudas técnicas, hay tres enfoques que podría tomar. En el primer enfoque, podría decidir continuar con el sistema tal como está. En este escenario, la aplicación se utilizará tal cual.
Alternativamente, podría decidir refactorizar la aplicación. La refactorización se realiza con el objetivo de reducir la complejidad de la aplicación y limpiar la estructura de la aplicación. Con la refactorización, el comportamiento del software no cambiará; la única parte afectada será la estructura interna.
Finalmente, si las dos opciones discutidas anteriormente no funcionan, deberá reemplazar el código por completo. Un problema con esto es que podría conducir a nuevas deudas técnicas, pero eso podría ser una mejor compensación a largo plazo.
Evitar deudas técnicas en el futuro
Por supuesto, es una obviedad que evitar las deudas técnicas es definitivamente más inteligente que tratar de arreglarlas cuando surgen. Aparte del hecho de que le ahorra tiempo y estrés, también se asegura de que las consecuencias residuales que se derivan de tener deudas técnicas desde el principio estén ausentes.
Se podría argumentar que las deudas técnicas, en sí mismas, no son malas. Generalmente son problemáticos porque son deudas que hay que pagar, y los humanos no son la especie más responsable de la tierra. Elegir constantemente una opción más débil generalmente debilitará la fortaleza de su software y hará que sea más difícil mejorar las funcionalidades más adelante. En definitiva, evitar las deudas técnicas es la mejor apuesta para cualquiera.
Entonces, ¿cómo evitar que surjan deudas técnicas?
La idea aquí es mantener a todos al tanto del proceso y ponerlos al día con los requisitos para cualquier tarea que se lleve a cabo. La creación de un backlog permite que todos vean las tareas que quedaron sin hacer y los caminos a seguir para lograrlas.
Si usted mismo es un programador, debe aprender a priorizar la realización de un trabajo de calidad sobre mucho trabajo. Asegúrese de que sus códigos estén limpios y que sus aplicaciones u otro software estén desarrollados a la perfección. Comprenda que la tentación de tomar atajos no valdrá la pena porque eventualmente, aún tendrá que llevar a cabo las tareas que descartó.
Si dirige un equipo, debe comunicar estos mismos valores a los miembros del equipo. Se debe enseñar a los miembros a crear soluciones orientadas a los resultados y evitar los atajos.
Generalmente, un conocimiento profundo de qué es la deuda técnica y cómo evitarla puede ser útil para evitar que surjan en primer lugar. Cuando proporcione a sus desarrolladores los conocimientos necesarios, será mejor que eviten las trampas que plantean las deudas técnicas.
Algunas prácticas de codificación hacen que sea más probable que caiga en una deuda técnica. Por lo tanto, sería genial evitar el acoplamiento estrecho, emplear la abstracción y la refactorización.
Las actualizaciones periódicas de la tecnología pueden ser un medio excelente para anticiparse a las deudas técnicas. Al actualizar, debe asegurarse de que lo que se está utilizando es el marco, las bases de datos y el software de aplicación más recientes.
Conclusión
Las deudas técnicas, en la gran mayoría de los casos, son inevitables mientras continúes desarrollando programas y escribiendo códigos. Sin embargo, las posibilidades de que ocurran pueden reducirse considerablemente si se siguen los pasos enumerados anteriormente. Además, ante la eventualidad de deudas técnicas, no se pierde toda esperanza. Mantén la calma, ten confianza, actúa en consecuencia.