El progreso impulsa la tecnolog\u00eda hacia adelante. Pero el progreso tambi\u00e9n tiene un costo: al agregar nuevas capacidades y caracter\u00edsticas, la comunidad de desarrolladores ajusta constantemente los componentes b\u00e1sicos. Eso incluye los lenguajes fundamentales utilizados para codificar soluciones tecnol\u00f3gicas.<\/p>\n
Cuando los componentes b\u00e1sicos cambian, el c\u00f3digo detr\u00e1s de la soluci\u00f3n tecnol\u00f3gica tambi\u00e9n debe cambiar. Es un ejercicio desafiante y lento que agota los recursos. Pero, \u00bfy si hay una alternativa?<\/p>\n
El problema: leer el c\u00f3digo que escribi\u00f3 otra persona<\/h2>\n
Demos un paso atr\u00e1s y echemos un vistazo a uno de los desaf\u00edos fundamentales en el desarrollo: editar el c\u00f3digo de otra persona. Est\u00e1 bien editar el c\u00f3digo que acaba de escribir o que escribi\u00f3 hace un par de semanas. Pero editar su propio c\u00f3digo escrito hace a\u00f1os, no importa el c\u00f3digo de otra persona, esa es una historia diferente.<\/p>\n
Las reglas de estilo de c\u00f3digo internas pueden ayudar, pero siempre hay convenciones de nomenclatura extra\u00f1as para variables y funciones, o elecciones inusuales para algoritmos. Podr\u00eda decirse que la capacidad de un programador para leer c\u00f3digo es una habilidad clave, pero es dif\u00edcil para todos.<\/p>\n
Los desarrolladores llaman al proceso de edici\u00f3n de c\u00f3digo antiguo “refactorizaci\u00f3n” y es un proceso que com\u00fanmente introduce nuevos errores o problemas de rendimiento. Por eso, retroceder y editar el c\u00f3digo antiguo, bueno, eso es lo \u00faltimo que la mayor\u00eda de los equipos de desarrollo quieren hacer, especialmente cuando el c\u00f3digo base existente se ejecuta de manera estable y est\u00e1 haciendo su trabajo.<\/p>\n
Es un verdadero dolor de cabeza, pero a veces no hay alternativa<\/h2>\n
La refactorizaci\u00f3n es algo que todo desarrollador quiere evitar durante el mayor tiempo posible porque puede parecer una p\u00e9rdida de tiempo. No obstante, los desarrolladores deben refactorizar de vez en cuando por una variedad de razones, y una de las razones m\u00e1s comunes se debe a los cambios en los componentes b\u00e1sicos del desarrollador.<\/p>\n
Eso incluye cambios en los lenguajes de programaci\u00f3n utilizados para crear software, que inevitablemente evolucionan con el tiempo. Las nuevas versiones de un idioma a menudo dejar\u00e1n de lado las viejas formas de hacer las cosas e introducir\u00e1n nuevas funciones. Si los desarrolladores no adoptan la nueva versi\u00f3n de idioma, quedan excluidos del nuevo conjunto de caracter\u00edsticas. <\/p>\n
Sin embargo, el c\u00f3digo existente generalmente necesita un ajuste para ejecutarse en la nueva versi\u00f3n del lenguaje, y eso implica un proceso de refactorizaci\u00f3n. Y ese es el enigma: para adoptar la versi\u00f3n nueva y m\u00e1s avanzada de un lenguaje, los desarrolladores deben refactorizar, y en el camino gastar\u00e1n una gran cantidad de esfuerzo y romper\u00e1n todo tipo de cosas inesperadas, introduciendo nuevos errores en una aplicaci\u00f3n que estaba funcionando bien.<\/p>\n
Peor a\u00fan, la refactorizaci\u00f3n por s\u00ed sola no le brinda las ventajas de la nueva versi\u00f3n del idioma, sino que necesita volver a desarrollar su base de c\u00f3digo para aprovechar las mejoras. De lo contrario, a pesar de ajustar el c\u00f3digo para que se ajuste a la nueva versi\u00f3n del idioma, estar\u00e1 donde sol\u00eda estar: una base de c\u00f3digo que se ejecuta en una nueva versi\u00f3n del idioma, pero sin caracter\u00edsticas nuevas. <\/p>\n
Los proveedores suelen dejar que los usuarios finales se encarguen de ello.<\/h2>\n
Puede parecer un ejercicio sin sentido pero, con la marcha constante del cambio tecnol\u00f3gico, a menudo hay pocas opciones al respecto: sus socios tecnol\u00f3gicos eligen por usted.<\/p>\n
Digamos que acabamos de pasar de Python 2.7 a Python 3.0. Si est\u00e1 desarrollando sus aplicaciones internamente, tiene el control total y puede hacer el cambio o no hacerlo. Los desarrolladores, por otro lado, bien pueden decidir dejar las cosas como est\u00e1n. Si una aplicaci\u00f3n se desarrolla y se ejecuta en Python 2.7, el desarrollador simplemente lo dejar\u00e1 as\u00ed y les dir\u00e1 a los usuarios que se desarroll\u00f3 una aplicaci\u00f3n para Python 2.7, sin soporte para otras versiones.<\/p>\n
Puede dejar a los usuarios en una situaci\u00f3n dif\u00edcil: permanecer en la versi\u00f3n anterior de Python 2.7 para acomodar la aplicaci\u00f3n, dejando atr\u00e1s el progreso, o cambiar a Python 3.0 y correr el riesgo de una serie de incompatibilidades con las aplicaciones.<\/p>\n
El resultado neto: un gran riesgo de seguridad<\/h2>\n
Los lenguajes de programaci\u00f3n (y sus variadas bibliotecas) no son inmunes a las vulnerabilidades de seguridad. Cuando surgen estas vulnerabilidades, los desarrolladores pueden imponerle una actualizaci\u00f3n de la versi\u00f3n de idioma. <\/p>\n
Pero estas actualizaciones no se limitar\u00e1n a correcciones de errores simples: provocar\u00e1n la desaprobaci\u00f3n de las construcciones del lenguaje con nuevas construcciones incorporadas, y eso obligar\u00e1 a los desarrolladores a realizar los movimientos de hacer cambios en el c\u00f3digo existente, nuevamente con todos los problemas potenciales que trae.<\/p>\n
La situaci\u00f3n empeora a\u00fan m\u00e1s cuando piensa en el efecto compuesto de las bibliotecas incluidas. Despu\u00e9s de los cambios de idioma, estas bibliotecas tambi\u00e9n deben actualizarse, pero si los autores no actualizan una de las bibliotecas en uso, el desarrollador no podr\u00e1 usarla despu\u00e9s de actualizar el resto del c\u00f3digo a una versi\u00f3n m\u00e1s reciente, lo que nuevamente lleva a m\u00e1s escritura de c\u00f3digo. <\/p>\n
Es f\u00e1cil ver a d\u00f3nde lleva todo esto: m\u00e1s esfuerzo, riesgos adicionales de introducir errores… y una reticencia a seguir refactorizando para acomodar las actualizaciones. \u00bfPr\u00f3ximo? Las actualizaciones simplemente no se realizan, lo que significa que las cargas de trabajo dependen de componentes b\u00e1sicos inseguros y obsoletos.<\/p>\n
La historia es similar a lo que vemos en todo el mundo de la tecnolog\u00eda, ya que los componentes b\u00e1sicos antiguos y vulnerables dejan la puerta abierta a los ataques cibern\u00e9ticos. Sin embargo, est\u00e1n surgiendo algunas buenas noticias. <\/p>\n
\u00bfHay una soluci\u00f3n mejor?<\/h2>\n
Tome los sistemas operativos no compatibles, por ejemplo. En el pasado, cuando un sistema operativo lleg\u00f3 al final de su vida \u00fatil<\/a>, la \u00fanica opci\u00f3n era actualizar a un sistema operativo m\u00e1s nuevo: una inversi\u00f3n importante y llena de riesgos. El resultado neto es que muchas organizaciones conf\u00edan en sistemas operativos sin parches ni soporte, incluso para cargas de trabajo cr\u00edticas. Si no tiene aplicaciones actualizadas, debido a que los desarrolladores no refactorizar\u00e1n las bases de c\u00f3digo antiguas, no puede mover sus aplicaciones a sistemas operativos m\u00e1s nuevos que no son compatibles con las versiones anteriores del lenguaje y, por lo tanto, romper la aplicaci\u00f3n.<\/p>\n