¿Qué es la deuda técnica y se puede evitar?


Si está en el desarrollo de software, tendrá que lidiar con la deuda técnica en algún momento. Entonces, para responder a la pregunta del título … no, no puedes evitarlo. Sin embargo, hay pasos que puede seguir para minimizar sus efectos y asegurarse de que no se salga de control. Al menos demasiado mal.

¿Qué es la deuda técnica?

La deuda tecnológica, como a veces se la llama, es esencialmente el costo en el que incurres a lo largo del tiempo por tener un código imperfecto. Los cambios y actualizaciones en el código fuente tienen un costo, al igual que agregar un nuevo miembro al equipo de desarrollo, agregar una nueva función o corregir errores y parchear exploits.

A medida que su proyecto se hace más grande, la base de código se expande y más personas trabajan en ese código, sus voces y estilos chocarán aquí y allá. Tal vez tenga una fecha límite y una solución menos que ideal esté parcheada en el código fuente para terminar a tiempo. Quizás agregue un componente de código abierto que no comprende completamente para manejar una función en lugar de codificarla usted mismo. O puede cambiar las bibliotecas entre versiones (de Backbone a React, por ejemplo), pero aún necesita apoyar a las personas que usan la base de código heredada para sus proyectos.

Absolutamente ninguna de estas cosas es malo. No por su cuenta. Quizás no en absoluto. Pero cuando se suman, la deuda técnica en la que incurren tendrá que pagarse en algún momento en el futuro.

En algún momento, ese componente de código abierto puede necesitar ser reemplazado (o bifurcado). Eso costará tiempo y dinero. En un futuro lejano, deberá eliminar todo el código Backbone de su proyecto y dejar de admitir usuarios heredados. De nuevo, tiempo y dinero. ¿Ese parche que hiciste para cumplir con una fecha límite? Bueno, eventualmente se deshará y necesitará una solución más permanente. Tiempo y dinero. Y tendrás nuevos miembros de tu equipo que revisan el código antiguo para hacer todo esto, necesitando entender el código y la lógica de los desarrolladores anteriores. Hora. Dinero.

Usted lo consigue.

Si bien la deuda técnica es un término abstracto, a menudo metafórico, el costo de la deuda tecnológica es muy real. Devolverlo tiene un valor monetario y puede realizar un seguimiento de los intereses que paga en horas de trabajo y recibos de pago. Puede verlo en la línea inferior de todo el desarrollo de software.

¿Puede evitar la deuda tecnológica?

Como dije antes… no realmente, no. Va a acumular deuda técnica en cada proyecto que escriba si alguna vez vuelve al código después de su lanzamiento. Sin embargo, si desglosa los tipos de deuda técnica, puede minimizarla e incluso contabilizarla en sus proyectos. Si considera la deuda de antemano, no es diferente a solicitar un préstamo para el automóvil o una hipoteca. Observa el costo, los intereses y los beneficios, y luego decide si puede / quiere pagarlo.

Echemos un vistazo a algunos de los ejemplos que analizamos anteriormente y veamos si hay una manera de evitar, minimizar o absorber el costo.

Consideración de la deuda técnica intencionada

Cuando decimos deuda técnica intencionada, lo que queremos decir es que su equipo ha tomado decisiones que sabe que no están dentro de las llamadas mejores prácticas para el idioma o el tipo de proyecto en el que está trabajando. Mencionamos anteriormente que es posible que tenga una fecha límite que cumplir. Y tal vez esa fecha límite sea dura y rápida. Tal vez haya un 0% de posibilidades de que se cambie o se cambie.

Aquí es cuando debe considerar la posibilidad de solicitar un préstamo y contraer una deuda técnica.

Realmente tienes tres opciones aquí:

  • Ponga software que no esté terminado y tenga errores, pero no haga concesiones en cuanto a la claridad y la lógica del código
  • Extraiga las funciones que no puede perfeccionar, pero libere las que tenga que estén lo mejor escritas posible
  • Tomar decisiones de desarrollo que publiquen código "lo suficientemente bueno" para que todo funcione, pero que probablemente deban abordarse nuevamente más adelante.

La tercera opción aquí suele ser la que la gente elige. Eso se convierte en deuda técnica. Y no hay nada de malo en esto. Porque tomaste la decisión de hacerlo.

Pagar el préstamo de la deuda con propósito

Asegúrese de documentar las decisiones detrás de la elección de seguir esta ruta en su código. Tome nota de lo que hizo frente a cuál sería la solución ideal. Y asegúrese de incluir al menos algún tipo de comentario en el código fuente para indicar dónde se implementó esta solución de toma de deuda (y si sabe, los sistemas afectados en otras áreas del proyecto). Si no da este paso, agregar al proyecto (incluso en correcciones de errores y parches, sin mencionar nuevas funciones o una base de código expandida) puede retrasarse terriblemente al encontrar una solución de mosaico cuando espera una completa.

Una vez más, esa solución de mosaico podría estar perfectamente bien y nunca causarle ningún problema real. Pero la deuda técnica sigue ahí y debe tenerse en cuenta.

Considerando la deuda técnica del código heredado

Otro tipo común de deuda técnica es la que WordPress está acumulando mucho en este momento. WordPress puede ejecutarse en PHP 5.x. Sin embargo, la actualización más reciente les dirá a los usuarios que debe ser al menos PHP 5.6. Para fines de 2019, WP Core requerirá PHP 7.x. Sin embargo, al aumentar los requisitos, es necesario actualizar una gran cantidad de código antiguo. Porque todavía hay código PHP 5.x en complementos, temas y el propio Core.

Sin mencionar el nuevo Editor de bloques. Está escrito en JavaScript. Reaccionar, específicamente. Eso no es nada parecido a PHP. De hecho, gran parte del núcleo de WordPress se está reescribiendo en JavaScript, poco a poco. Pero todo eso JS también tiene que complementar y llevarse bien con PHP. Adoptar nueva tecnología es genial y es necesario adoptar nuevos requisitos de control de versiones. Pero al hacerlo, está pagando intereses sobre el inevitable deuda técnica en la que incurra debido a que ese software existe desde hace un tiempo.

Pagar la deuda del código heredado

Este es un poco difícil porque no hay una buena manera de hacerlo. Puede tomar la opción nuclear y hacer una reescritura completa desde cero en el nuevo lenguaje / marco / versión (mire lo que hicimos entre Divi 2 y Divi 3.0, pasando de Backbone.js a React). Sin embargo, esto aún no soluciona por completo el problema de la deuda, ya que todavía hay personas que usan la biblioteca anterior. En algún momento, tendrá que dejar de admitir el código base heredado. Lo que es como devolver el préstamo. Hasta que tengas que sacar el siguiente.

Si esa no es una opción (o la mejor idea para usted), puede asegurarse de no depender de funciones específicas del idioma o de la versión. Los desarrolladores de aplicaciones para el usuario tienen que lidiar con esto todo el tiempo, ya que algunos navegadores admiten funciones completamente nuevas rápidamente, mientras que otros (Microsoft Edge / IE, tos para tos) puede que nunca lo adopten. Puede preparar sus proyectos para el futuro si se apega a lo básico, lo que, a su vez, hará que la cantidad de cambios que deben abordarse al actualizar o refactorizar sea menor de lo que sería de otra manera.

Consideración de varios desarrolladores a lo largo del tiempo

Este es un tipo de deuda tecnológica que los equipos grandes tienden a acumular con el tiempo, peor que los equipos de desarrollo pequeños. Aunque incluso los más pequeños también deben preocuparse por eso. Verá, cada ingeniero de software escribe código de manera diferente. Muy raramente tendrá dos desarrolladores que resuelvan el mismo problema con exactamente el mismo código. Pueden realizar la misma función y el resultado final puede ser el mismo, pero el código se escribirá con la voz del autor (al igual que puede saber quién escribió publicaciones aquí, por ejemplo, como Jason, Nathan, Donjetë y Todos tengo estilos distintos). El código no es diferente.

Teniendo esto en cuenta, la lógica a veces también puede tener diferentes voces. Lo que un desarrollador piensa que está perfectamente claro, otro desarrollador lo verá y no tendrá idea de por qué el código hace lo que hace. Este problema se vuelve realmente problemático cuando el autor original ya no está disponible para consultar. La deuda técnica acumulada por esto puede ser catastrófica. Pero hay formas de manejarlo.

Pagar la deuda técnica de los antiguos desarrolladores

La forma más fácil es contratar a los mejores desarrolladores posibles y nunca dejar que abandonen su empresa. Nunca.

Dado que eso no sucederá alrededor del 100% de las veces, el pago de esta deuda se puede mitigar un poco más fácil de lo que cree. En primer lugar, asegúrese de capacitar a su equipo de desarrollo para comentar su código. Y comentarlo bien. Siempre que tomen una decisión que pueda ser considerada remotamente ambigua por otra persona, pídales que anoten por qué lo hicieron y cómo funciona la función.

Además, asegúrese de que todos los desarrolladores de su equipo se apeguen a una guía de estilo o un conjunto de estándares. los WordPress Core tiene un conjunto de estándares de codificación que mantendrá los complementos, los temas y las contribuciones principales en línea para que cualquier otra persona que venga más tarde no tenga problemas con él. Airbnb tiene una guía de estilo para React que se ha adoptado como un estándar no oficial en toda la industria. Incluso las guías de estilo y los estándares internos evitan que los desarrolladores vayan demasiado lejos por sí mismos porque ese tipo de confirmaciones no se fusionarán a menos que estén a la altura.

Terminando

La deuda técnica es un problema muy real. También es un recurso muy real si sabe cómo administrarlo. Al poder decidir cuándo asume una deuda tecnológica y cómo la paga, su desarrollo puede ser más rápido y fluido de lo que sería posible de otra manera. Y en esos momentos en los que asumir esa carga es inevitable, esperamos haberle dado algunas ideas de estrategias que puede implementar para que tenga menos impacto de lo que podría ser de otra manera.

¿Cómo maneja la deuda técnica dentro de sus proyectos y equipos de desarrollo?

Imagen destacada del artículo de Andrey Suslov / shutterstock.com