Como desarrollador de software ¿cuál es la situación más difícil que has enfrentado hasta el momento y cómo saliste de ella?

Uno de los retos más locos que he enfrentado no está relacionado exactamente con el desarrollo de software habitual, 

(ARP).
En el año (2018), fui ascendido a un nuevo puesto cuando mi nuevo gerente me dijo: “Necesito un reemplazo de la herramienta X ya que esto es una … Y estamos perdiendo N cantidad de dinero mensualmente”.
Desafortunadamente, no podía deshacerme de la herramienta incluso si hubiera querido ya que ya había un contrato de por medio … Y el proyecto no había funcionado correctamente por aproximadamente 3 años … Había demasiada intervención humana en un robot “desatendido”.
Imagínese estar entre la espada y la pared, ya sea que su promoción se iba o debía arreglar un proyecto completo que no había funcionado correctamente durante tanto tiempo donde muchas personas lo habían intentado y fallado, porque la gente prefería renunciar a repararlo. No es el lugar donde quisieras estar … Dado que en la mayoría de los casos de “desarrollo de software común” tienes foros que pueden guiarte más o menos, pero en el caso de los ARPs, siéntete afortunado si alguien alguna vez ha compartido alguna experiencia en Stack o en otro lugar más …
¿Qué no estaba funcionando? Bueno, no fue fácil de identificar para ser honesto, necesitaba comenzar a analizar todo el robot, que ejecutaba más de 20 macros, N cantidad de tareas internas, procedimientos SQL, servicios e integración con N sitios web (entre IE y Chrome ), llamando a otros robots y soluciones de punto único.
Sin embargo, el principal dolor de cabeza no era uno, fueron tres situaciones específicas que no eran exactamente el robot, sino diseños arquitectónicos “incorrectos” (no estaban planificados para ser automatizados) que pasé 3 meses para encontrar los problemas específicos y fueron por materia de azar (mientras escribía aplicaciones paralelas para manejar mini-servicios) y mi falta de hiper-especialización en cualquier tecnología, para ser honesto, prefiero ser un generalista que sea lo suficientemente bueno en múltiples tecnologías que un súper genio en C# o JS que “lo sabe todo”.
Los problemas fueron los siguientes:
Controles dinámicos.
Este fue una locura, teníamos algunos sitios web que creaban muchísimos controles que se veían iguales y estaban en “la misma posición”, pero eran increíblemente aleatorios porque podías abrir el mismo sitio 2 veces y él ID era totalmente diferente.
Si no tuviera ninguna experiencia con el desarrollo web, no podría imaginar cómo descubrir la razón detrás del comportamiento anormal y por qué la herramienta no se ha automatizado correctamente.
El nombre de los controles era el mismo, pero las ID, en una ejecución eran btn12, la siguiente btn73 y muchas veces incluso intercambiaban los ID ya que había más de un texto de entrada y los botones cambiaban de cierta forma …
Desde la perspectiva humana, todo estaba funcionando bien, ya que solo identificaba el control y listo, pero para el robot, era una pesadilla ya que fallaba horriblemente cuando uno de los controles no tenía una identificación previamente reconocida … Y necesitábamos agregar múltiples excepciones para adivinar todas las situaciones alternativas. La solución anterior no funcionó correctamente durante más de un par de semanas. ¿Qué opciones nos quedaba?
Escribir e inyectar un script JS para reasignar todos los controles (ID) HTML después de cargar.
Falta de propiedades de automatización en WPF.
Este también era descabellado, ya que en una de nuestras herramientas estaban desarrolladas en WPF, muchos controles no eran reconocibles bajo ninguna circunstancia … Imagínate tratando de encontrar un control que es visible, pero no puedes hacer clic en él y solo puede adivinarlo por sus coordenadas X y Y …
No suena como la solución más eficiente que haya existido y no lo era, por eso no funcionó durante años. Había miles de errores adicionales porque si había un cambio menor en cualquier pantalla, todo desapareció y se bloqueaba nuevamente.
Después de meses de pruebas y por casualidad, encontré esta propiedad:
AutomationProperties.AutomationId=”Grid1″ 
Y cuando lo encontré, créanme, me ahorró días de estrés ya que toda la aplicación pudo automatizarse.
Enlaces de descarga falsos.
En este proyecto, enfrenté un desafío final, cuando una situación específica era “imposible” de automatizar porque bajo ninguna circunstancia ciertos “enlaces” de archivos se podían descargar automáticamente. La mayoría de los enlaces eran normales:
<a href=”http://location/file/file.xlsx”>Link</a> 
Daba clic y se descargaba el archivo. Pero los otros enlaces, durante muchos años nadie tuvo idea de cómo descargarlos (era una sección “prohibida”, ¡todo el mundo odiaba cuando un usuario subía el archivo allí, el robot fallaba!). ¿Por qué te estarías preguntando? La razón no era tan clara, ya que parecían un enlace común, actuaban como un enlace, pero no tenían ninguna propiedad href o algo relacionado, cuando obtenías la información del control; de hecho, no eran enlaces “reales”, eran “enlaces con JS” como este:
<a onclick=’getFile(xxxIdxxx)’>Link</a> 
Nadie entendía y hasta que yo de casualidad vi el código fuente y aquí estaba la clave porque el archivo no era algo directo … Y esto era porque nadie tenía alguna, ya que para poder resolverlo, se necesitaba saber sobre desarrollo web y JS para pensar en algo tan lógico como “Clic derecho, inspeccionar elemento “. Si eras hiper-especializado en Java, C#, AA, etc. No tendrías tanta suerte para resolverlo.

¿Cuál fue la solución? Necesitábamos usar
Diré que la clave de mi éxito fue la falta de hiper-especialización en una sola tecnología porque, si lo fuera, probablemente no te podría contar esta historia. Dado que el robot ha estado funcionando correctamente por más 1 año y medio después de todos estos cambios locos sin mayores problemas.

Deja un comentario