¿Qué es la Deuda Técnica y se Puede Evitar?

¿Qué es la Deuda Técnica?

La deuda tecnológica, como a veces se le llama, es esencialmente el costo en el que incurre con el tiempo por tener un código imperfecto. Los cambios y las actualizaciones del 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 crece, 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. Tal vez agrega un componente de código abierto que no comprende completamente para manejar una característica en lugar de codificarlo usted mismo. O podría cambiar las bibliotecas entre versiones (de Backbone a React, por ejemplo), pero aún necesita admitir a las personas que usan la base de código heredada para sus proyectos.

Absolutamente ninguna de estas cosas es  mala . No por su cuenta. Tal vez no en absoluto. Pero cuando se suman, la deuda técnica en la que incurren tendrá que ser pagada en algún momento en el futuro.

En algún momento, es posible que sea necesario reemplazar (o bifurcar) ese componente de código abierto. Eso costará tiempo y dinero. En un futuro lejano, deberá eliminar todo el código de 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á nuevos miembros de su equipo que revisarán el código anterior para hacer todo esto, y necesitarán comprender el código y la lógica de los desarrolladores anteriores. Tiempo. 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. Pagarlo tiene un valor monetario, y puede rastrear el interés que paga en horas de trabajo y talones de pago. Puede verlo en la línea inferior de todo el desarrollo de software.

¿Se puede evitar la deuda tecnológica?

Como dije antes… no realmente, no. Vas a acumular deuda técnica en cada proyecto que escribas si alguna vez vuelves al código después de su lanzamiento. Sin embargo, si desglosas los tipos de deuda técnica, puedes minimizarla e incluso contabilizarla en tus proyectos. Si considera la deuda de antemano, no es diferente a sacar un préstamo de automóvil o una hipoteca. Miras el costo, el interés y los beneficios, y luego decides si puedes/quieres pagarlo.

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

Teniendo en cuenta la deuda técnica con propósito

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 es dura y rápida. Tal vez haya un 0% de posibilidades de que se cambie o cambie.

Aquí es cuando debe considerar obtener un préstamo y contraer una deuda técnica.

Realmente tienes tres opciones aquí:

• Saca software que está inacabado y con errores, pero no haces concesiones en cuanto a la claridad y la lógica del código.
• Obtenga funciones que no puede lograr perfeccionar, pero libere lo que tiene que esté lo mejor escrito posible
• Tome decisiones de desarrollo que generen un código «suficientemente bueno» para que todo funcione, pero es probable que deban abordarse nuevamente más adelante

La tercera opción aquí es a menudo la que la gente elige. Eso es entrar 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 notas sobre 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, la adición al proyecto (incluso en correcciones de errores y parches, sin mencionar las nuevas funciones o una base de código ampliada) puede retrasarse terriblemente al encontrar una solución de parches cuando espera una completa.

Nuevamente, esa solución de retazos podría estar perfectamente bien y nunca causarle ningún problema real. Pero la deuda técnica sigue ahí y debe ser contabilizada.

Teniendo en cuenta la deuda técnica del código heredado

Otro tipo común de deuda técnica es una que WordPress está acumulando mucho en este momento. WordPress puede ejecutarse en PHP 5.x. La actualización más reciente, sin embargo, les dirá a los usuarios que al menos debe ser PHP 5.6 . Para fines de 2019, WP Core requerirá PHP 7.x. Sin embargo, al aumentar los requisitos, se debe 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 cerca de PHP. De hecho, gran parte del núcleo de WordPress se está reescribiendo en JavaScript, poco a poco. Pero todo eso JS tiene que complementar y llevarse bien con PHP también. Adoptar nuevas tecnologías es excelente y es necesario adoptar nuevos requisitos de versiones. Pero al hacerlo, está pagando intereses sobre la  deuda técnica inevitable en la que incurre debido a que ese software existe desde hace un tiempo.

Pago de la deuda del código heredado

Este es un poco difícil porque no hay una gran manera de hacerlo. Podrías elegir la opción nuclear y hacer una reescritura completa desde cero en el nuevo idioma/marco/versión (mira lo que hicimos entre Divi 2 y Divi 3.0, pasando de Backbone.js a React). Sin embargo, esto todavía no soluciona completamente el problema de la deuda, ya que todavía hay personas que usan la biblioteca antigua. En algún momento, tendrá que dejar de admitir el código base heredado. 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 front-end 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 tos) puede que nunca las 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.

Teniendo en cuenta múltiples 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 el código de manera diferente. Muy rara vez 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ó las publicaciones aquí, por ejemplo, como Jason, Nathan, Donjetë y Todos tengo estilos distintos). El código no es diferente.

Teniendo eso en cuenta, la lógica a veces también puede tener diferentes voces. Lo que piensa un desarrollador está perfectamente claro, otro desarrollador lo mirará y no tendrá idea de por qué el código hace lo que hace. Este tema se vuelve verdaderamente 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 maneras de manejarlo.

Pago de la deuda técnica de los desarrolladores antiguos

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

Dado que eso no sucederá alrededor del 100 % de las veces, el pago de esta deuda se puede mitigar un poco más fácilmente de lo que piensa. En primer lugar, asegúrese de capacitar a su equipo de desarrollo para comentar su código. Y comentarlo bien . Cada vez que tomen una decisión que otra persona pueda considerar remotamente ambigua, 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 sigan una guía de estilo o un conjunto de estándares. El núcleo de WordPress tiene un conjunto de estándares de codificación que mantendrán los complementos, los temas y las contribuciones del núcleo 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 sus desarrolladores vayan demasiado lejos 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 sabes 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 otro modo. Y en esos momentos en los que asumir esa carga es inevitable, esperamos haberle dado algunas ideas de estrategias que puede implementar para que sea menos impactante 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 por Andrey Suslov/ shutterstock.com