Hola equipo, el reto consiste en presentar una propuesta para reemplazar mi labor como desarrollador de software. Por lo tanto, decidí abordar esta idea a través de tres sistemas independientes que podrían no sólo reemplazar mi labor (sistema 1 y 3), sino también mejorar la eficiencia de los procesos de desarrollo de software (sistema 2).
Diseñé diagramas de flujo guiados para cada uno de los sistemas, además de ejemplos de situaciones en las que podrían ser útiles.
El proceso para crear los siguientes conceptos fue resultado de introspección en mi trabajo como desarrollador de software, así como de la lectura de los últimos avances en el campo del aprendizaje automático. Espero con esto demostrar mi enfoque para la resolución de problemas y así poder ser parte del equipo de SmartUp 😊.
🔧 Sistema automático para reparar errores
Usualmente, los errores en un sistema se reportan por parte de un cliente mediante un correo electrónico, un sistema de tickets o un formulario. La información de este error es enviada a un equipo de desarrollo y, posteriormente, asignada a un desarrollador. El desarrollador debe investigar la causa error y proponer una solución. Una vez creada y probada la solución, el desarrollador debe integrarla y desplegarla en el sistema.
Ahora bien, ¿qué tal si, una vez reportado el error, el sistema automático pudiera estudiarlo con la información proporcionada? Analizar no solamente la información provista por el usuario, sino también material multimedia como imágenes, videos, etc., para generar un conjunto de hipótesis sobre la causa del error. La hipótesis generada iría acompañada de pruebas automáticas para asegurar que el error se solucionó.
En este punto, se categoriza el error para mejorar la búsqueda de soluciones y evitar modificar el código fuente (como se verá más adelante) de manera incorrecta.
Las categorías podrían ser:
- Interfaz de usuario: El error ocurre en la interfaz de usuario. Por ejemplo, un botón no funciona.
- Lógica de negocio: El error ocurre en la lógica de negocio. Por ejemplo, un usuario no puede pagar un producto.
También se pueden establecer categorías por áreas:
- Pasarela de pagos: El error ocurre en la pasarela de pagos.
- Registro de usuarios: El error ocurre en el registro de usuarios.
Una vez generada las hipótesis, el sistema automático podría proponer varias soluciones para cada hipótesis. Esta solución tendría una estructura que incluye una explicación y código fuente. El sistema podría integrar las soluciones propuestas en un entorno específico para esa solución y probarlas a través de las pruebas automáticas escritas en el paso anterior.
Desde este punto, se obtienen los resultados de las pruebas automáticas; las soluciones que pasaron las pruebas pueden ser integradas y desplegadas automáticamente en el sistema principal.
Como desarrollador de software, muchos de los problemas descritos brevemente tienen un módulo o una función relacionada. Es decir, si existe un problema en el registro de usuarios, es probable que la solución se aplique en el módulo que procesa dicho registro y no en el módulo que procesa el pago de productos.
Por lo tanto, si en el siguiente paso no se encuentra una solución, el sistema podría buscar en el código fuente de otros módulos relacionados con el módulo que procesa el registro de usuarios, como, por ejemplo, el módulo que procesa el pago de productos.
Es decir, primero realiza varias hipótesis sobre el módulo de software más relacionado con el error y, si no encuentra una solución, realiza las hipótesis sobre los módulos de software en conjunto.
El error se documenta en una base de datos para que el sistema pueda aprender de los errores que ocurrieron en el pasado. En este punto creo que sí es inevitable que un humano intervenga para revisar los errores, mejorarlos y corregirlos si es necesario.
🔍 Sistema automático para encontrar errores
En la propuesta anterior, mencioné que un usuario puede reportar un error. Pero, ¿qué tal si desarrollamos un sistema automático pudiera encontrar errores de forma proactiva en lugar de reactiva? Sería mucho más eficiente y efectivo.
Como desarrollador de software, he pasado por muchas situaciones donde tras el despliegue de una nueva versión de una aplicación web o móvil, los usuarios reportan errores que no fueron detectados en las pruebas. ¿Cómo podemos adelantarnos a estos errores?
Quiero destacar dos clases de errores que podrían ser encontrados por el sistema potenciando su capacidad de análisis:
- Errores de seguridad: El sistema podría analizar minuciosamente el código fuente de los módulos de software y detectar errores de seguridad de manera efectiva. Dependabot (de GitHub) es un ejemplo similar, dado que alerta a los desarrolladores de posibles vulnerabilidades, aunque se basa en actualizaciones de seguridad obtenidas de una base de datos revisada por humanos.
- Errores en el uso del sistema: El sistema podría emular las acciones que un usuario podría realizar en el sistema, pero introduciendo aleatoriedad y perturbaciones para simular el comportamiento de un usuario real, explorando así posibles escenarios problemáticos. Por ejemplo, un usuario podría hacer clic en un botón, pero el sistema podría hacer clic en el botón 3 veces. Y así descrubrir que un proceso detrás de escena se puede triplicar. O un usuario podría escribir un texto en un campo de texto con un límite de 100 caracteres, pero el sistema podría escribir 200 caracteres en el campo de texto (modificando el código de cliente) y descubrir que el sistema no valida el límite de caracteres.
Si se detecta algún inconveniente o comportamiento sospechoso, el sistema podría reportar el error al sistema automático de arreglo de errores (que describí en la propuesta anterior).
De no encontrarse ningún inconveniente, el sistema automático puede proceder con la siguiente acción.
Este es un proceso que contemplo ejecutar de forma periódica. El lapso de tiempo entre cada ejecución dependerá de la complejidad del sistema y de la cantidad de módulos de software que lo componen. Por ejemplo, si el sistema es complejo y tiene muchos módulos de software, el sistema podría ejecutar el proceso de forma periódica cada 6 horas. Si el sistema es simple y tiene pocos módulos de software, el sistema podría ejecutar el proceso de forma periódica cada 48 horas.
Si el sistema depende a un alto grado del tiempo, el sistema automático podría ejecutar el proceso con mayor frecuencia.
📄 Sistema automático de documentación
La documentación de un sistema de software es una parte esencial del desarrollo de software. En mis anteriores posiciones como Desarrollador de Software, he tenido que escribir documentación de código fuente, documentación de APIs, e incluso documentación de procesos, entre otros aspectos relevantes para mantener una base de conocimiento que permita a otros desarrolladores entender el sistema, y validar que el sistema cumple con los requisitos funcionales y no funcionales.
Tengo experiencia documentando código utilizando GPT-3 (2021). Creé un script que analiza el código fuente de un proyecto y genera documentación de código fuente mediante few-shot learning. Ahora, con la evolución del último modelo GPT-4, la precisión de la documentación de código fuente mejorará significativamente.
Propongo aquí un sistema automático de documentación que aproveche la potente capacidad de GPT-4 para generar documentación de código fuente de forma automática y precisa. La documentación del código fuente puede almacenarse en un repositorio con su propio sistema de control de versiones, garantizando su integridad en el tiempo.
Esta documentación inicial se deriva del código fuente existente. Luego, el sistema se integra de manera eficiente al flujo de control de versiones del código fuente, asegurando que cada vez que se realice un cambio en el código fuente, el sistema de generación de documentación revise el código fuente modificado junto con la documentación existente, y de ser necesario, actualice la documentación de acuerdo con el cambio realizado en el código fuente.
Este sistema puede ser integrado al proceso de integración continua (CI) del sistema de software, de manera que cada vez que se realice un cambio en el software, todo el flujo de trabajo se ejecute.