RSS El Diario ¿Qué Demonios? Nota

RSS El Diario ¿Qué Demonios?

El Daily WTF es un blog de humor orientado a la programación creado por Alex Papadimoulis basado en historias sobre el desarrollo de software y el mundo de la tecnología. Se centra principalmente en anécdotas basadas en problemas de proyectos, ejemplos de código y historias divertidas relacionadas con la TI. El sitio cuenta con una gran colección de estas experiencias del mundo real de muchos desarrolladores que comparten sus extrañas y divertidas aventuras en el trabajo, técnicas o personales, pero siempre conectadas a la tecnología.

Hilo de notas

John recordó una historia de su experiencia pasada trabajando en un banco donde desarrollaron una aplicación del lado del cliente para ayudar a los agentes de ventas a calcular pagos de hipotecas y mostrar gráficos a los clientes. La aplicación fue exitosa, pero más adelante, los agentes solicitaron una versión web móvil que pudieran utilizar en sus teléfonos. La idea inicial fue conectarla al backend principal, pero debido a la falta de desarrolladores de mainframe, decidieron envolver los objetos de cálculo de hipotecas en un servicio web en su lugar. El servicio web se probó y funcionó bien, pero a veces produjo resultados absurdos, que eran difíciles de reproducir y diagnosticar. El problema finalmente se encontró que fue causado por un objeto singleton que no estaba limitado a una sola solicitud, lo que permitía que las solicitudes simultáneas se interfirieran entre sí. El objeto singleton era un resto de la aplicación cliente original, donde no era necesario hacer cumplir la unicidad. El calculador mantenía estado y probablemente no debería haber sido un singleton desde un principio. La solución fue simple, que fue dejar de utilizar el patrón singleton y asegurarse de que cada solicitud obtuviera su propia instancia del calculador. Esta experiencia sirve como ejemplo de la mala aplicación de patrones, destacando la importancia de una consideración cuidadosa al aplicar patrones de diseño al desarrollo de software. La historia demuestra cómo un problema aparentemente simple puede tener una causa compleja, y cómo una revisión cuidadosa del código y el diseño puede llevar a una solución sencilla.