Como desarrolladores generalmente esperamos estar desde el arranque de un proyecto, con la idea de que asi “esta vez hacer las cosas bien” usando una buena arquitectura y claro, con lo ultimo de la tecnología, al final terminamos llegando al estado de “parecia una buena idea en su momento” y que hay que terminar el proyecto “como sea”, bueno… exagero un poco, pero debe quedar claro que estar en el proyecto desde un inicio no es una garantia para que todo vaya como una seda todo el tiempo.

Pero para bien o para mal, si uno es un desarrollador “desde las trincheras” y no un “guru”, no sera rara la situación en que nos veamos en la necesidad de dar mantenimiento a un programa que alguien mas haya hecho o empezado (en cualquier grado de avance), y ahí es donde empieza nuestra historia…..

Antes de proseguir, debo decir que cuando he estado una buena temporada en un proyecto, trato de pensar (sobre todo en las ultimas etapas) en “como hacerle mas simple la vida al pobre tipo que se hara cargo de esto” para lo cual opto por un enfoque realista, dejar comentarios en las secciones de código que se que pueden ser mas crípticas, y de ser el caso dejar documentación útil, ¿y cuando una documentación es útil? ¿no se supone que lo útil es documentar todo lo posible? ¡Error! una documentación es util cuando uno honestamente sabe que leyéndola proveerá una idea para entender la lógica detras de la implementación de un código.

Entonces como decia, nos encontramos en la situación de que hay una aplicación existente, en cuya creación no hemos intervenido, y se nos pide ver porque ha dejado de funcionar o que le agreguemos una nueva funcionalidad, la documentación es escasa y con suerte tenemos las referencias de los servidores involucrados.

Asi que con esta premisa vamos tras el codigo fuente a ver que podemos sacar en claro (*), con lo que nuestra rutina es mas o menos como sigue:
– Ubicar el punto de entrada de la aplicacion, o sino, los controles y sus eventos respectivos que desencadenan la accion a investigar.
– Ubicado el punto de entrada o el evento deseado (capa de Interfaz de Usuario), ir viendo como se van creando las sucesivas instancias de las capas de Negocio, Fachada, Datos y los métodos involucrados.
– De ser necesario ir depurando para evaluar los valores que van tomando las variables criticas…

En fin, este es el mundo real y creo que alguna vez todos habremos pasado por este lió, siendo nuestros dilemas el saber a que clase/metodo se esta invocando desde un punto del código, así que me he sentido afortunado cuando he podido hacerme una idea del código usando las herramientas para encontrar la “Definicion” de un método invocado.

Es que así es el código típico:

– Método f1 de la clase A necesita llamar al método f2b de la Clase D.
– Método f1 instancia un objeto “miD” de la Clase D.
– Método f1 ejecuta el método miD.f2b.
– Método f2b de la clase D necesita……

Si el código esta mas o menos estructurado (y no es un spagetti por supuesto), esa es la lógica que uno busca, con las debidas excepciones de cuando se tienen que ejecutar instancias remotas y/o usando Interfaces en vez de clases directas.

Una de las cosas que tienen de bueno los entornos RAD como Delphi y .NET (WebForms y Winforms) es que brindan un mecanismo comprensible para empezar a depurar, sabes el control y quieres ver que hace, pues entonces… a ver los eventos vinculados y de ahi para adelante, de capa en capa. Quienes hemos trabajado con ASP Clasico recordamos la pesadilla que eran los puntos de entrada de las paginas, revisando todas las posibles combinaciones de parametros que venia en el Request razon por la que la introducción de WebForms fue la respuesta a nuestros problemas, y para mi lo sigue siendo.

Pero la evolución del desarrollo de software es imparable, y asi hemos visto como han surgido tendencias que han procurado añadir valor a nuestros ciclos de desarrollo como: WebServices, Refactorizacion, SOA y varios intentos de mecanismos para construir una arquitectura distribuida: DCOM, COM+, .Net Remoting, WCF….

Pero al margen de como vayan evolucionando las tendencias, una cosa que siempre procuro en mis desarrollos, es dejar el camino mas o menos despejado para que el que venga luego pueda entender el código que esta leyendo, procurando tener las inevitables sofisticaciones bajo control. Teniendo esto en cuenta… cabe preguntarse si tendencias como el “desacoplamiento” y la necesidad de “pruebas unitarias” facilitan o no la vida del que luego tiene que enfrentarse a mantener tu código, pero ese análisis lo dejo para un posterior post.

De momento quiero dejar la reflexión de que a veces estamos tentados a emplear unos patrones novedosos, potentes, pero… también debemos pensar que no todos los desarrolladores siempre desarrollan desde cero, que se llega a proyectos ya empezados, a código terminado en producción que hay que mantener, y que no hay que complicarle la vida en aras de lucirte con lo mas novedoso en metodologias y arquitecturas si es que no es de veras necesario, ya que estas no solo deben prometerte mas facilidades para ti, si no para el que luego tendra que mantener tu codigo.

(*)Aunque alguna vez no contamos ni siquiera con el código fuente, como me paso en un cliente hace 3 años, por lo que toca ver si podemos desensamblar el código, pero eso ya es otra historia y mas bien un extremo de irresponsabilidad por parte del cliente.