Contexto
Recientemente me encontré con una aplicación frontend de tamaño mediano escrita en Angular 6 (sí, cuyo EOL fue en 2019).
La tarea era actualizar el proyecto a una versión LTS (Long Term Support) de Angular. Opté, como primer movimiento, por actualizar a la primera versión LTS disponible, la versión 16.2.X. Sin embargo, no soy especialista en frontend ni en el stack de Node.js, y necesitaría bastante tiempo o el apoyo de otro desarrollador con más conocimiento del framework.
El proyecto tenía 40 módulos y 175 componentes, distribuidos según la siguiente tabla:
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
CSS 6 334 271 20 43
HTML 180 11903 10206 693 1004
JavaScript 4 78 49 19 10
JSON 2 22 22 0 0
Sass 247 12575 9431 1284 1860
SVG 2 4 4 0 0
TypeScript 370 36123 27318 2904 5901
===============================================================================
Total 811 61039 47301 4920 8818
===============================================================================La opción de contar con el apoyo de otro desarrollador no era viable, y tampoco podía dedicar semanas al proyecto de migración. Entonces decidí adoptar un enfoque que vi recientemente en canales de YouTube: experimentar con el uso de AI Code Assist en el IDE para que me ayudara. Aunque soy usuario de JetBrains IDEA y de GitHub Copilot para proyectos de backend, en este caso quería probar algo nuevo y más enfocado en mi objetivo: apoyarme en mi conocimiento elemental de frontend y del framework Angular, y trabajar en un estilo de pair programming tipo Driver and Navigator [1], alternando entre momentos en los que la IA generaba el código y yo lo revisaba, y viceversa.
Herramientas
Para esta tarea, opté por probar el editor de código Cursor [2], que cuenta con integración nativa de IA y promete un aumento de productividad con una serie de funcionalidades. A continuación, destaco las que usé, aunque existen otras más avanzadas descritas en la documentación [3].
Tab: para sugerir o editar código a partir de un fragmento existente o una descripción;Cursor Prediction: después de una edición realizada conTab, Cursor predice fragmentos adicionales que pueden corregirse de la misma forma y salta automáticamente al siguiente fragmento con un nuevotab ⇥;
Chat: para interactuar con la IA y entender un fragmento de código o pedir una sugerencia de implementación;AI Fix in Chat: donde se resalta un error detectado por ellinter, y la IA abre un popup sugiriendo una solución;Apply: para aplicar las sugerencias de la IA directamente en el editor;
Para usar Cursor no es necesario tener una suscripción premium, aunque el uso es limitado [4]. En mi caso, opté por la suscripción Pro para garantizar el uso ilimitado de las funciones
completionseinstant apply.
Con Cursor, node en la versión 20.11 y el Angular CLI en la versión deseada instalados, comencé a trabajar.
Interactuando con la IA de Cursor
Lo primero que hice fue generar un nuevo proyecto con la versión 16 del Angular CLI y comparar las diferencias entre el proyecto antiguo y el nuevo. Noté que algunos archivos ya no eran necesarios, como angular-cli.json, mientras que otros necesitaban crearse o ajustarse, como angular.json, tsconfig.json, tslint.json y tsconfig.app.json. Le delegué a la IA la tarea de corregir esos archivos mediante interacciones con el siguiente formato:
Actualiza el archivo angular-cli.json (en el contexto) a la versión 16 de Angular.
Con el siguiente resultado:
Y el resultado de los cambios sugeridos por la IA se aplicaba directamente en el archivo deseado:
Una vez actualizados los archivos base del proyecto, pasé a las dependencias. Obviamente, muchas ya no existían, o habían cambiado de nombre. Por lo tanto, tuve que corregir manualmente algunas dependencias a partir de búsquedas en npm.js, como por ejemplo angular-http, que fue incorporado a angular-common, o angular2-fontawesome, que fue descontinuado y reemplazado por @fortawesome/angular-fontawesome.
Una vez actualizadas las dependencias, y después de muchos npm install, llegó la hora de intentar ejecutar ng build y empezar a encontrarme con los primeros errores.
Fase de build del backend
Los proyectos Angular se dividen en dos grandes partes: el backend, con componentes, módulos y servicios; y el frontend, compuesto por templates, directivas, pipes y módulos de interfaz de usuario.
En cinco años cambian muchas cosas, y en el caso de los proyectos frontend, los cambios fueron aún mayores.
Mi enfoque fue ejecutar primero ng build para compilar el backend, y, como era de esperar, ocurrieron muchos errores de build, especialmente por la configuración strict de tsconfig.json, que ahora exigía que todas las variables estuvieran tipadas. Aunque podría haber desactivado esa configuración, preferí, con la ayuda de la IA, corregir los errores de tipado en cada archivo, usando las funcionalidades mencionadas al inicio del artículo. Además, muchas dependencias cambiaron de namespace, siendo uno de los principales ejemplos la separación de los componentes de Angular Material, que antes estaban bajo el namespace @angular/material.
Cientos de Tabs después, ng build finalmente compiló sin errores, y pude pasar a la fase de build del frontend.
Fase de build del frontend
Ahora ng serve necesitaba compilar el frontend. Obviamente, muchas directivas habían cambiado, como el binding de propiedades y eventos, que tuvieron que corregirse.
La explicación que dio la IA de Cursor para un error durante la migración del binding de evento fue la siguiente:
El cambio que mencionaste en la directiva de Angular de maxlength='100' a [maxLength]='100' refleja una actualización en la forma en que se vinculan las propiedades en Angular, especialmente en relación con el uso del property binding.
Explicación del Cambio:
- Property Binding:
- Antes (Angular 6): La directiva usaba la sintaxis de atributo HTML estándar, donde maxlength se definía como un atributo HTML con un valor literal. Esto significa que el valor se trataba como una cadena de texto.
- Ahora (Angular 16): La nueva sintaxis [maxLength]='100' utiliza el property binding de Angular. Esto permite que el valor se trate como una expresión de Angular, lo que significa que puedes pasar variables, expresiones o valores dinámicos.
La ventaja de contar con la IA proporcionando tanto la corrección como la explicación del cambio fue que pude usar la función de Search All and Replace para corregir de una sola vez todos los fragmentos similares que necesitaban modificarse.
Otro error frecuente era la falta de manejo de valores null al acceder a propiedades de objetos, algo que TypeScript no aceptaba y debía corregirse. Este es un problema recurrente en proyectos legados, y la IA fue capaz de corregirlo a partir de sugerencias de Tab.
Después de un tiempo, ng serve finalmente compiló sin errores, y pude acceder a la aplicación en el navegador.
Publicando la aplicación y creando el Pull Request
Con la aplicación funcionando, solo restaba actualizar el archivo de pipeline para usar una versión más reciente de Node.js y crear el Pull Request en el repositorio.
Este fue el resultado final de la rama enhancement/bump-up-angular-16:
397 files changed, 20290 insertions(+), 19788 deletions(-)Conclusión
El término "Programación Asistida/Guiada por IA", y otros similares, estarán cada vez más presentes en el día a día de los equipos de ingeniería de software. Estudios de Gartner prevén que, para 2028, el 75% de los desarrolladores usarán herramientas de IA para escribir código [5]. Este movimiento ya es perceptible en la industria del software; Mercado Libre, por ejemplo, ya utiliza herramientas de IA para apoyar a sus más de 9.000 desarrolladores [6].
En este breve relato, pude observar que, aunque no era un profundo conocedor de un stack específico, la productividad en la ejecución de la tarea aumentó significativamente. Un esfuerzo que antes habría requerido semanas se redujo a pocos días. Sin embargo, el conocimiento y la experiencia del desarrollador son indispensables, ya que, como demostré, muchas veces es el propio desarrollador quien debe decidir cuál es el enfoque más adecuado para resolver el problema. Así, el criterio, la sensibilidad y la experiencia del desarrollador fueron esenciales y no fueron sustituidos.