Si te dedicas al desarrollo de software, tendrás que lidiar con una deuda técnica en algún momento. Respondiendo a la pregunta del título… no, no se puede evitar. Sin embargo, hay pasos que puede seguir para minimizar sus efectos y asegurarse de que no se salga de control. Al menos demasiado.
¿Qué es la deuda técnica?
La deuda tecnológica, como a veces se le llama, es esencialmente un costo en el que incurres con el tiempo debido a un código imperfecto. Los cambios en el código fuente y las actualizaciones tienen un precio, 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 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 se haya parcheado una solución menos que perfecta en el código fuente para completarla a tiempo. Tal vez esté agregando un componente de código abierto que no comprende completamente para admitir la función en lugar de codificarlo usted mismo. También puede cambiar bibliotecas entre versiones (por ejemplo, de Backbone a React), pero aún necesita admitir a las personas que usan la base de código heredada para sus proyectos.
Absolutamente ninguna de estas cosas son malo. No por mi cuenta. Tal vez no en absoluto. Pero cuando se suman, su deuda técnica tendrá que ser pagada en algún momento en el futuro.
En algún momento, es posible que sea necesario reemplazar (o bifurcar) este componente de código abierto. Le costará tiempo y dinero. En un futuro lejano, tendrá que eliminar todo el código de Backbone de su proyecto y dejar de admitir a los usuarios más antiguos. Tiempo y dinero otra vez. ¿Ese parche que hiciste para cumplir con la fecha límite? Bueno, eventualmente retrocederá y necesitará una solución más permanente. Tiempo y dinero. Tendrá nuevos miembros en su equipo que cambiarán al código anterior para hacer todo esto y deberán comprender el código y la lógica de los desarrolladores anteriores. Tiempo. Dinero.
Entender.
Si bien la deuda técnica es un concepto abstracto y, a menudo, metafórico, el costo de la deuda tecnológica es muy real. La devolución tiene un valor monetario y puedes llevar un control de los intereses que pagas en horario comercial y recibos de sueldo. Puede verlo en la última línea de todo el desarrollo de software.
¿Es posible evitar la deuda tecnológica?
Como dije antes… no realmente, no. Si alguna vez vuelve al código después de su lanzamiento, acumula deuda técnica en cada proyecto que escribe. Sin embargo, si desglosas los tipos de deuda técnica, puedes minimizarlos e incluso incluirlos en tus proyectos. Si considera su deuda de antemano, no es diferente a sacar un préstamo de automóvil o una hipoteca. Usted mira el costo, el interés y los beneficios y luego decide si puede/quiere pagarlos.
Echemos un vistazo a algunos de los ejemplos que discutimos anteriormente y veamos si hay una manera de evitar, minimizar o absorber costos.
Considerando la deuda técnica intencional
Cuando hablamos de deuda técnica intencional, nos referimos a que tu equipo ha tomado decisiones que sabes que no están dentro de las llamadas mejores prácticas en cuanto al lenguaje o tipo de proyecto en el que estás trabajando. Mencionamos anteriormente que es posible que tenga una fecha límite que cumplir. O tal vez este plazo es difícil y rápido. Tal vez haya un 0% de probabilidad de un cambio o un cambio.
Aquí es cuando debe considerar obtener un préstamo e incurrir en una deuda técnica.
Realmente tienes tres opciones aquí:
- Publique software inacabado y con errores, pero no comprometa la claridad y la lógica del código.
- Obtenga características que no puede perfeccionar, pero libere lo que tiene que esté lo mejor escrito posible
- Tome decisiones de programación que liberen un código «suficientemente bueno» para que las cosas funcionen, pero probablemente tendrán que resolverse más adelante.
La tercera opción a menudo es elegida por personas. Esto entra en deuda técnica. Y no hay nada malo en ello. Porque has tomado la decisión de hacerlo..
Reembolso de un préstamo de deuda específico
Asegúrese de documentar en su código las decisiones detrás de elegir esta ruta. Tome notas sobre lo que hizo y cuál sería la solución ideal. Y asegúrese de incluir al menos algún comentario en el código fuente para indicar dónde se implementó esta solución de manejo de deuda (y si sabe qué sistemas cubrieron otras áreas del proyecto). Si no realiza este paso, agregar a su proyecto (incluso en correcciones de errores y parches, sin mencionar nuevas características o una base de código extendida) puede retrasarse terriblemente al encontrar una solución de parches cuando espera que esté completa.
Nuevamente, esta solución de retazos podría estar perfectamente bien y nunca causarle ningún problema real. Pero la deuda técnica aún existe y debe ser contabilizada.
Considerando la deuda técnica del Legacy Code
Otro tipo común de deuda técnica es la que WordPress está acumulando mucho en estos días. WordPress puede ejecutarse en PHP 5.x. Sin embargo, la última actualización 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 núcleo.
Sin mencionar el nuevo editor de bloques. Está escrito en JavaScript. Reaccionar específicamente. Está cerca de PHP. De hecho, gran parte del núcleo de WordPress se está reescribiendo gradualmente a JavaScript. Pero todo este JS también necesita ser complementado y hecho para llevarse bien con PHP. La adopción de nueva tecnología es excelente y debe adoptar nuevos requisitos de versión. Pero al hacer esto usted paga intereses sobre inevitable la deuda técnica en la que incurre debido a este software que ha existido por un tiempo.
Pagar la deuda bajo el código anterior
Este es bastante difícil ya que no hay una gran manera de hacerlo. Puede tomar la opción nuclear y reescribir completamente desde cero en el nuevo idioma/marco/versión (mire lo que hicimos entre Divi 2 y Divi 3.0 pasando de Backbone.js a React). Sin embargo, eso todavía no resuelve completamente el problema de la deuda, ya que todavía hay personas que usan su antigua biblioteca. En algún momento, tendrá que cancelar la compatibilidad con la base de código heredada. Es un poco como pagar un 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 confiar en las características específicas del idioma o 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) pueden no adoptarlas nunca. Puede preparar sus proyectos para el futuro al apegarse a los conceptos básicos, lo que a su vez reducirá la cantidad de cambios que se deben considerar al actualizar o refactorizar que de otra manera.
Teniendo en cuenta muchos desarrolladores a lo largo del tiempo.
Este es el tipo de deuda tecnológica que los equipos grandes construyen peor con el tiempo que los equipos de desarrollo pequeños. Sin embargo, incluso los más pequeños deben preocuparse por eso. Verá, cada ingeniero de software escribe el código de manera diferente. Muy rara vez tendrá dos programadores resolviendo 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 (como puede ver quién escribió las publicaciones aquí, por ejemplo, Jason, Nathan, Donjetë y yo tenemos diferentes estilos). El código no es diferente.
Con esto en mente, la lógica a veces puede tener diferentes voces. Lo que piensa un programador está perfectamente claro, otro programador echará un vistazo y no tendrá idea de por qué el código hace lo que hace. Este tema se vuelve realmente problemático cuando el autor original ya no está disponible para su consulta. La deuda técnica acumulada puede ser catastrófica. Pero hay maneras de lidiar con eso.
Amortización de la deuda técnica de los antiguos promotores
Es más fácil contratar a los mejores desarrolladores y nunca dejar que abandonen su negocio. Cuando sea.
Dado que esto no sucederá el 100% del tiempo, este pago de la deuda es algo más fácil de aliviar de lo que piensa. En primer lugar, asegúrese de capacitar a su equipo de desarrollo para que comente su código. Y es bueno comentarlo. Cada vez que tomen una decisión que alguien más pueda considerar ambigua, pídales que anoten por qué lo hicieron y cómo funciona la característica.
Además, asegúrese de que todos los desarrolladores de su equipo se adhieran a una guía de estilo o un conjunto de estándares. WordPress Core tiene un conjunto de estándares de codificación que mantendrán los complementos, temas y contribuciones de Core para que cualquiera que venga más tarde no tenga problemas. Airbnb tiene una guía de estilo para React, que ha sido adoptado como el estándar no oficial de toda la industria. Incluso las guías de estilo y los estándares internos evitan que los desarrolladores vayan demasiado lejos por su cuenta, ya que este tipo de cambios no se fusionarán a menos que se estén preparando para el rapé.
Envase
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 incurre en una deuda tecnológica y cómo pagarla, su crecimiento puede ser más rápido y fluido de lo que sería de otro modo. Esperamos que en estos tiempos en los que asumir esta carga es inevitable, esperamos haberle brindado algunas ideas de estrategias que puede implementar para que sea menos efectivo de lo que podría ser de otra manera.
¿Cómo lidias con la deuda técnica en tus proyectos y equipos de desarrollo?
El artículo presentaba una imagen de Andrey Suslov / shutterstock.com
