Aquí hay consejos sobre cómo manejarlo cuando su empresa le hace utilizar un entorno de programación obsoleto. Consejo: Todavía puede aplicar métodos modernos a los lenguajes de programación antiguos.

    Erik Dietrich, consultor de TI en Michigan, tiene una historia sobre una agencia del gobierno estatal que reemplazó su sistema de pantalla verde por Windows y formularios en línea, lo que resultó en un sistema más lento, más clandestino y más odiado que los terminales obsoletos y que estaba prácticamente obsoleto para el momento en que se lanzó.

    Lo que está de moda en ConsejoTecnologico.com

    Hay lecciones que aprender, anotó Dietrich, para cuando su empleador lo haga usar herramientas de desarrollo de software obsoletas. Los llama lenguajes y herramientas «zombies», como explicó en su blog de febrero de 2019 sobre Microsoft Visual BASIC, escrito para su cliente SubMain Software, que realiza análisis de código y productos de revisión. Con ejemplos como el perpetuamente no-muerto-yet COBOL, «Por suerte, los lenguajes de programación pueden disfrutar de largas, satisfactorias y saludables muertes como zombis», escribió.

    Dietrich, al preguntarle sobre el alcance del problema esta semana, comenzó su respuesta con un audible jadeo de exasperación.«Oh, Dios mío, yo diría que es bastante generalizado… lo que hace que toda la prensa de la industria sea la más reciente, pero imagino que hay una gran mayoría silenciosa de desarrolladores que trabajan en tecnología obsoleta», dijo.

    VER: Kit de contratación: Desarrollador JavaScript (Tech Pro Research)

    El informe de la semana pasada de la Cloud Foundry Foundation iluminó aún más el uso continuo de entornos no de moda como el C e incluso el lenguaje ensamblador. Dietrich ofreció sus consejos a los desarrolladores que probablemente no han tocado estos paquetes desde la universidad.

    «Lo primero sería, ¿está esto en tu timonera o no? Si se trata de desempolvar algo con lo que estás familiarizado -como para mí, solía hacer VB6 en mis tiempos- lo primero que probablemente haría es volver a ver: ¿Tengo algo en este idioma pasado que pueda desenterrar y trabajar, o puedo desenterrar cualquiera de los recursos del pasado que solía tener?».

    «Iba y asaltaba lugares como librerías a mitad de precio y librerías para buscar versiones antiguas de libros de programación. Eso probablemente me ayudaría a prepararme para el trabajo».

    «Desde una perspectiva táctica, lo que creo que hay que hacer es tratar de mojarse los pies eligiendo características relativamente simples que sólo requieren cambiar unas pocas líneas de código. Se puede entrar en el código base de forma mínimamente invasiva y conocerlo», continuó. Tomar un código conocido, cambiar cosas y ver el efecto que tuvo es la forma en que practiqué Applesoft BASIC en la década de 1980.

    O, en lugar de empezar con nuevas características para una antigua base de código hecha con viejas herramientas, «A ver si puedes detectar algunos errores de la pila de trabajo atrasado», observó Dietrich.

    «Francamente, si una organización está tomando a un desarrollador y le dice: `Ve a buscar un lenguaje de hace 15 años que no entiendes e implementa una característica importante’, hay algo malo con esa organización'».

    VER: La verdad sobre MooCs y bootcamps: Su mayor beneficio no es crear más codificadores (PDF de portada) (ConsejoTecnologico.com)

    ¿Qué pasa con la integración de programas antiguos con otros sistemas? «Por lo general, lo que yo sugeriría a un desarrollador individual o de grupo es que diseñe los otros sistemas de tal manera que estén un poco a la defensiva contra esa aplicación obsoleta, o que sean robustos, podría ser una mejor manera de decirlo: desea aislarse lo más que pueda de ella», explicó. «Si puede, divida las funciones del sistema antiguo en grupos para que pueda empezar a reemplazarlas de a una por una. Así que en el transcurso de un par de años, pieza por pieza lo reemplazas todo».

    Las pruebas automatizadas de unidades pueden ser un salvavidas si hereda código de otro programador que hace mucho tiempo dejó el edificio. Es el concepto de probar pequeñas secciones de código individualmente, en lugar de probar toda la aplicación a la vez, dijo Dietrich. Eso no era posible en los días de las pantallas verdes, pero hoy en día ayuda a prevenir los juegos de whack-a-mole con sus bichos. Sorprendentemente, «he leído sobre personas que buscan formas de hacerlo en COBOL o incluso en aplicaciones de Microsoft Access», dijo. «Puedes ser creativo con formas de modernizar tu enfoque aunque no puedas modernizar la pila.»

    Noticias técnicas que puede utilizar en el boletín informativo

    Entregamos las mejores noticias de tecnología empresarial sobre las empresas, las personas y los productos que revolucionan el planeta. Entregado diariamente

    mismo