En la inicialización de esa pantalla se crea un objeto “ListaDatos” y se guarda en sesión. Como era de esperar, tiene un método “Agregar” y la implementación de una interfaz que permite pasárselo a una grilla a modo de fuente de datos.
Me alegro mucho cuando veo un código claro y bien estructurado. Que puede debe tener errores -por supuesto-, pero consideremos que no sé cómo es que la pantalla logra meter los datos ahí y tampoco sé cómo es que esos datos terminan en la base cuando le doy “Aceptar”…
…pero no me interesa. Sólo sé que se guardan en ese objeto, que yo agrego uno y termino viendo dos. Tiene un y sólo un método para agregarlos así que necesariamente pasa por allí. Y tiene una interfaz para mostrar los datos, así que sale por allí… el error está necesariamente ahí, en el medio de esos dos.
Y todo lo anterior es obvio, y se deduce de ver solamente el código de inicialización de la pantalla que tiene unas escasas 10 líneas y ningún comentario… porque no le hace falta. 10 líneas de puro código bien escrito bastan para indicar cómo está estructurada toda la funcionalidad. Me alegro más cuando no es mío. Me siento en paz con el mundo que me rodea.
Así que a ver la implementación. La lista de registros se mantiene internamente con un objeto de nuestro framework. Una clase que nos había dado muchos dolores de cabeza con registros duplicados en el pasado por su capacidad de mantener versiones actuales, originales y eliminadas de los registros que la componen.
“No… no otra vez con esto… justo ahora que parecía que andaba bien…”
Casi una hora después seguíamos buceando en las profundidades no ya del sistema en cuestión sino de nuestro framework -que soporta varios sistemas, algunos en producción-, allí donde se manejan todas esas cuestiones desagradables de las que nos habíamos olvidado.
Y un par de minutos después, seguros de que entraba uno y salían dos (la versión original y una marcada como “modificada”) apareció la famosa frase…
“Es un error del Framework”. Ahora con mayúscula, ya que se refería no al nuestro si no al .Net, de Microsoft.
No sé ustedes, pero yo la escuché 10.000 veces… ¿Y saben con cuántos errores del .Net me topé en mi vida profesional? Con ninguno. Es por eso que esta frase tiene la curiosa propiedad de devolverme a la realidad.
La explicación más simple es la más probable.
¿Hay un error en el .Net (en una de las funciones más comunes, en su versión 2.0, con casi 7 años de vida oficial desde la 1.0 –13 de febrero de 2002-, usado en miles de sistemas en todo el mundo) o nos estamos equivocando nosotros? Hay un error en el .Net, por supuesto.
¿Hay un error en nuestro framework (aparecido por arte de magia en la funcionalidad más utilizada de todas -por lejos- en varios de nuestros sistemas y luego de meses de no modificarla) o nos estamos equivocando ahora? En el framework, claro.
- ¿Te fijaste bien en dónde se llama al método “Agregar”? A ver… busquemos las referencias otra vez?
- Pero ya me fijé.
- Dale otra vez, que yo no lo ví.
Y listo. ¿Por qué se ven dos registros? Porque se están agregando dos. Por un pequeño error (una distracción al borrar código sobrante durante alguna edición, probablemente) se estaba llamando dos veces al método “Agregar”, pasándole los datos al objeto en sesión dos veces por cada una que los ingresaba el usuario.
En los días siguientes -con esta anécdota dando vueltas- empezamos a darnos cuenta de cuántas veces repetíamos (todos, me incluyo) más o menos la misma frase: “El error está en… [cualquier otro lado]”.
Y tiene mucho que ver con el conocido antipatrón de diseño:
Absolvedor (Absolver): Código mayormente desarrollado por ex-empleados, al que acuden los programadores actuales para lavar su culpas ante cualquier problema reportado. También es conocido como "no está en mi código".
Sólo que en vez de “ex-empleados” es “cualquiera menos nosotros”. Y en vez de “no está en mi código” es “no está donde estoy mirando (y no puedo encontrarlo, habría que agregar)”.
Viene también a cuento la frase de Larry Wald:
La mayoría de ustedes están familiarizados con las virtudes del programador. Son tres, por supuesto: pereza, impaciencia y orgullo desmedido.
Pereza: es más cómodo decir “está en otro lado” que buscar ese “otro lado”.
Impaciencia: si no lo encuentro en 10 segundos es que no está.
Orgullo desmedido: este código está bien, ya lo revisé (10 segundos). Sigamos revisando todo menos esto.
Resumen:
-
En el 99.99% de los casos el problema -no importa cual sea- es tuyo. Tu código, tu revisión, tu interpretación, lo que tu estás mirando, lo que sea.
“-Profesor, ¿dónde, dónde está el problema? -En tu cabeza.”
“El problema está siempre de este lado de la pantalla.”
-
Así que no vale decir “el problema está en otro lado” por descarte.
O lo que es lo mismo, eres culpable hasta que demuestres lo contrario.
Por otro lado, “otro lado” no es un lugar sino un no-lugar. Si no sabes exactamente dónde está el problema éste sigue siendo tuyo, porque si no sabes dónde está no puede haber otro responsable.
-
Si crees que el problema está en un componente de base ampliamente utilizado (el framework, el motor de base de datos o lo que sea) búscalo en Google. Si no está no existe.
Otra vez: si no está no existe.
De nuevo: no eres el primero en encontrarlo.
No importa cuántas veces lo digas: no eres el primero en encontrarlo.
Si crees ser el primero ahora tienes dos problemas: el primero es que estás buscando mal lo que de todas maneras muy probablemente no exista. El segundo es el problema que estás buscando.
No hay comentarios.:
Publicar un comentario