\u00bfQu\u00e9 es la deuda t\u00e9cnica?<\/h2>\n
Hay varias interpretaciones de deuda t\u00e9cnica, pero la definici\u00f3n m\u00e1s com\u00fanmente aceptada es cualquier decisi\u00f3n tomada con el prop\u00f3sito de lograr ganancias r\u00e1pidas a pesar de saberlo implica refactorizar o revisar en una etapa posterior<\/strong>. En nuestro caso, esto podr\u00eda ser, por ejemplo, implementar un c\u00f3digo que funcione perfectamente y que no est\u00e9 alineado con la estrategia a largo plazo del producto, o casos extremos que se dejen de lado voluntariamente en ausencia de requisitos funcionales que los necesiten en ese momento.<\/p>\n Como la gran mayor\u00eda de las soluciones de software empresarial, la plataforma Moneythor se basa en una buena cantidad de bibliotecas de c\u00f3digo abierto. Hist\u00f3ricamente, el software de c\u00f3digo abierto ha sido desarrollado por individuos o financiado por l\u00edderes de la industria. Hoy en d\u00eda, las grandes organizaciones contribuyen cada vez m\u00e1s al desarrollo de muchos proyectos de software de c\u00f3digo abierto para ayudar a satisfacer sus propias necesidades. Piensa en lo ahora inevitable Apache Kafka<\/a> (de LinkedIn), Kubernetes<\/a> (de Google), Reaccionar<\/a> (de Facebook\/Meta); la lista crece cada d\u00eda.<\/p>\n Dada la complejidad de la soluci\u00f3n Moneythor, ser\u00eda inimaginable, extremadamente lento y costoso construir nosotros mismos todos los aspectos de la soluci\u00f3n, sin mencionar el riesgo de reinventar la rueda sin alcanzar nunca el mismo nivel de calidad de estos proyectos patrocinados por terceros. por organizaciones reconocidas y probado intensivamente en m\u00faltiples entornos de producci\u00f3n.<\/p>\n Dicho esto, la seguridad es una gran preocupaci\u00f3n. A nadie le gusta escuchar c\u00f3mo un servicio ha sufrido una violaci\u00f3n de datos, pero es casi imposible evitar vulnerabilidades como las que se informan peri\u00f3dicamente. Vulnerabilidades y exposiciones comunes<\/a> y a menudo requieren una acci\u00f3n inmediata para remediarlos.<\/p>\n Como tal, probamos y seleccionamos cuidadosamente todas las bibliotecas de terceros, considerando siempre las alternativas y lo dif\u00edcil que ser\u00eda comprender su c\u00f3digo fuente y solucionar nosotros mismos cualquier problema de seguridad. Una vez hecho esto, lo integramos en nuestra soluci\u00f3n con las capas necesarias para garantizar que pueda actualizarse o incluso reemplazarse f\u00e1cilmente.<\/p>\n Reescribir el c\u00f3digo fuente o cambiar de una tecnolog\u00eda a otra a menudo implica un alto costo y es dif\u00edcil de justificar ante las partes interesadas. Por ese motivo, tomamos en cuenta la deuda t\u00e9cnica desde el principio. La forma en que dise\u00f1amos nuestra soluci\u00f3n juega un papel importante aqu\u00ed y, a veces, no dudamos en realizar un esfuerzo adicional inicial para preparar la soluci\u00f3n para una pieza adicional de funcionalidad no confirmada.<\/p>\n Esta tambi\u00e9n es una oportunidad para que registremos desde el principio lo que se considerar\u00e1n implementaciones finales de nuevas funciones y elementos en los que tuvimos que tomar algunos atajos para producir una soluci\u00f3n funcional a tiempo, sabiendo a\u00fan que algunas partes podr\u00edan revisarse m\u00e1s adelante.<\/p>\n Vale la pena se\u00f1alar que los requisitos funcionales evolucionan y tenemos que revisar el c\u00f3digo existente. En ese caso, no estamos abordando una partida de deuda t\u00e9cnica. Es simplemente el ciclo de vida natural de una soluci\u00f3n mejorada constantemente.<\/p>\n Dicho esto, es imposible adivinar el futuro y arriesgado apostar por una pr\u00f3xima soluci\u00f3n o palabra de moda. Por ejemplo, la soluci\u00f3n Moneythor aprovecha las bases del conjunto de aplicaciones Java Enterprise, una plataforma muy madura y respetable que ha respaldado el desarrollo de millones de proyectos de software empresarial probados en las \u00faltimas d\u00e9cadas. Una de las caracter\u00edsticas de la plataforma Java es la venerable API Servlet de bloqueo, un modelo probado diferente del enfoque de procesamiento de flujo as\u00edncrono sin bloqueo promovido por la nueva iniciativa de programaci\u00f3n reactiva.<\/p>\n Si este \u00faltimo se convierte en el enfoque predeterminado en el futuro una vez que la comunidad y muchas dependencias adopten este nuevo paradigma de programaci\u00f3n, podr\u00eda crear una deuda t\u00e9cnica en la que ser\u00eda necesario invertir tiempo para llevar una soluci\u00f3n a un nuevo est\u00e1ndar con el mismo nivel de funcionalidad como antes.<\/p>\n En este caso, el papel del equipo de ingenier\u00eda es nuevamente dise\u00f1ar la soluci\u00f3n de tal manera que podamos minimizar el esfuerzo de reescribir y adaptar las caracter\u00edsticas existentes sin tener que dedicar tiempo a adaptar la l\u00f3gica de negocios existente.<\/p>\n Como es bien sabido, el mundo produce y consume cada a\u00f1o m\u00e1s datos a un ritmo exponencial. Procesar y analizar una gran cantidad de datos siempre ha sido un desaf\u00edo importante para las organizaciones de todos los sectores, incluida la industria de servicios financieros. No sorprende que la industria del software trabaje y cree constantemente nuevas herramientas con el objetivo de resolver estos desaf\u00edos de datos en constante evoluci\u00f3n.<\/p>\n Si bien las bases de datos relacionales eran las predeterminadas en el pasado y sus versiones administradas en la nube son muy escalables, ahora existen enfoques completamente diferentes sobre c\u00f3mo persistir y consultar datos. Cambiar de una base de datos relacional tradicional a algo as\u00ed como un almac\u00e9n de documentos no es tan sencillo como cambiar entre dos proveedores de bases de datos relacionales diferentes. En muchos casos, la soluci\u00f3n existente se basa en principios y contratos que ya no existen en el nuevo almac\u00e9n de datos.<\/p>\n Nuestra experiencia en esta industria durante las \u00faltimas d\u00e9cadas y m\u00faltiples proyectos heterog\u00e9neos muestran que existe un umbral por encima del cual la deuda t\u00e9cnica se convierte en un agujero negro y este umbral disminuye cada vez m\u00e1s con el tiempo, especialmente cuando no se toman medidas.<\/p>\n Lo que significa es esto: cuando se alcanza el l\u00edmite, puede ser imposible ponerse al d\u00eda con su deuda t\u00e9cnica y, en \u00faltima instancia, costar\u00e1 menos reescribir todo desde cero, lo que puede ser un esfuerzo significativo y desmoralizador. Cuando eso sucede, toda la experiencia y el conocimiento que se adquiere con una tecnolog\u00eda deben reconstruirse.<\/p>\n Por ejemplo, cambiar de la popular base de datos relacional PostgreSQL al tambi\u00e9n popular almac\u00e9n de documentos Mongo DB no se trata s\u00f3lo de hacer que su software sea compatible con las dos capas persistentes. Tambi\u00e9n se trata de comprender las implicaciones que tiene en el flujo de datos, el proceso transaccional, los pros y los contras de ambas soluciones, lo que se obtiene y lo que se pierde. Esto puede pasarse por alto f\u00e1cilmente y provocar retrasos y costes adicionales, e incluso fallos en algunos casos.<\/p>\n Como se mencion\u00f3 anteriormente, ser\u00eda imposible predecir los acontecimientos, ni podemos implementar todo de una vez de manera razonable. Lo que podemos hacer es intentar protegernos contra obst\u00e1culos innecesarios. Existen patrones de dise\u00f1o y arquitectura bien conocidos y probados para este prop\u00f3sito exacto.<\/p>\n En primer lugar, la soluci\u00f3n se construye sobre la Marco de primavera<\/a>. El punto m\u00e1s importante a tener en cuenta aqu\u00ed es que elegimos Spring no solo porque es extremadamente popular, est\u00e1 bien mantenido y proporciona un rico conjunto de subproyectos para ayudar a abordar muchos aspectos de las soluciones de software de nivel empresarial, sino porque, en esencia, Es un marco de inyecci\u00f3n de dependencia que nos permite desacoplar nuestro c\u00f3digo y facilita enormemente la implementaci\u00f3n del separaci\u00f3n de intereses<\/a> principio.<\/p>\n En la medida de lo posible, desacoplamos todo, desde bibliotecas de terceros, a nuestro propio c\u00f3digo para que la implementaci\u00f3n sea f\u00e1cilmente reemplazable. A continuaci\u00f3n, una vez que decidimos implementar una nueva caracter\u00edstica, comenzamos por desacoplar la implementaci\u00f3n concreta de la l\u00f3gica empresarial con el marco. Tambi\u00e9n nos tomamos m\u00e1s tiempo para dise\u00f1ar una capa intermediaria gen\u00e9rica que se ubica entre el marco t\u00e9cnico impulsado por Spring o bibliotecas de terceros y la implementaci\u00f3n de los requisitos comerciales. El prop\u00f3sito de esta capa intermedia es proporcionar una abstracci\u00f3n de de qu\u00e9 se trata la caracter\u00edstica para que luego podamos personalizarla f\u00e1cilmente y protegerla del impacto de actualizar o reemplazar componentes t\u00e9cnicos subyacentes.<\/p>\n El resultado es que la soluci\u00f3n Moneythor se convierte en s\u00ed misma en un marco con una implementaci\u00f3n concreta de la l\u00f3gica funcional, y no solo esa implementaci\u00f3n. Esto nos proporciona un gran nivel de flexibilidad, lo cual es extremadamente valioso en nuestro caso. Tambi\u00e9n nos da la capacidad de mantener el mismo producto para todos los clientes. Por supuesto, adaptamos nuestra soluci\u00f3n a diferentes regiones, entornos de destino y caracter\u00edsticas espec\u00edficas del cliente, pero esto se logra gracias a una sola versi\u00f3n del c\u00f3digo fuente sin bifurcaci\u00f3n.<\/p>\n Hoy podemos medir los beneficios de este enfoque. Comenzamos a desarrollar este conjunto de aplicaciones hace casi 10 a\u00f1os y, a\u00fan as\u00ed, no mantenemos ninguna biblioteca vulnerable. En su lugar, utilizamos la \u00faltima versi\u00f3n de Spring y otros componentes de terceros, lo que nos permite agregar soporte para nuevas tecnolog\u00edas dentro del presupuesto y sin la necesidad de refactorizar gran parte del software. Por \u00faltimo, pero no menos importante, esto mantiene motivado a nuestro equipo de desarrollo para trabajar en una arquitectura moderna con tecnolog\u00edas y herramientas recientes.<\/p>\n B\u00e1sicamente, se trata de encontrar el equilibrio adecuado entre dise\u00f1o e ingenier\u00eda complejos y un costo aceptable de retrabajo, y con la soluci\u00f3n Moneythor hemos podido lograr ese equilibrio y continuaremos haci\u00e9ndolo.<\/p>\n \u00a0<\/p>\n\t\u00bfPor qu\u00e9 es esto importante para nosotros?<\/h2>\n
Sea consciente de su deuda t\u00e9cnica<\/h3>\n
Mantenga la deuda t\u00e9cnica bajo control<\/h3>\n
Los sistemas de almacenamiento de datos crean f\u00e1cilmente deuda t\u00e9cnica<\/h3>\n
La deuda t\u00e9cnica tiene consecuencias<\/h3>\n
Nuestro enfoque para gestionar la deuda t\u00e9cnica<\/h2>\n
![\"Suscr\u00edbete](\"https:\/\/www.moneythor.com\/wp-content\/uploads\/2024\/02\/Article-CTA-NEW-BRANDING.png\")
\t\t\t\t\t\t\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/a>\t\t\n