¿Los nuevos patrones ayudan a la mantenibilidad de aplicaciones?

Si tuviera que decir que funcionalidad del Visual Studio (y de VB6 ya puestos) he estado usando mas ultimante, la respuesta seria «Go to Definition» (seguida de «Find All References»).

La razón de esto es debido a que ahora me corresponde estar en mantenimiento de aplicaciones, lo cual implica que cuando hay un error tratar de encontrar que metodo o clase fallo y ver que hacer para solucionar el error, y en otras ocasiones añadirle una funcionalidad a cualquiera de las aplicaciones ya existentes (en cuya creación yo no intervine).

Como ya explique anteriormente esta es una situación en la que no se empieza de cero, y se requiere tratar de entender de manera rápida el como esta montado todo a fin de encontrar la raiz del problema, por lo cual usualmente tengo dos caminos:

– Ubicar la aplicación e ir haciendo una «depuración sin ejecutar» mediante el «Go to definition» tratando de ubicar los puntos de paso críticos que hay durante la cascada de llamadas de los sucesivos métodos involucrados en la funcionalidad.
– Buscar el texto con el mensaje de error reportado, y de esa manera mediante el «Find all references» identificar de abajo hacia arriba la posible pila de llamadas y en el camino encontrar lo que ocasiono el problema.

Pero llegados a este punto vemos que se ha incrementado la demanda por desacoplamiento y pruebas unitariasdentro de nuestros codigos, todo como parte de los patrones SOLID:

* SRP: The Single Responsibility Principle (Principio de Responsabilidad Única)
* OCP: The Open/Closed Principle (Principio Abierto / Cerrado)
* LSP: The Liskov Substitution Principle (Principio de Sustitución de Liskov)
* ISP: Interface Segregation Principle (Principio de Segregación de Interfaces)
* DIP: The Dependency Inversion Principle (Principio de Inversión de Dependencias)

Principios muy interesantes, que valen la pena revisar, pero que introducen tendencias como la Inyección de Dependencias y la Inversión de Control, para lo cual recomiendo este muy bien explicado articulo de Gisela Torres de donde extraigo esta explicacion;

Generalmente, cuando tenemos una clase que depende de otras para ciertas acciones, necesitamos inicializar instancias de las mismas para poder utilizarlas posteriormente. En ocasiones, una de las alternativas puede ser crear un objeto de dichas clases de forma privada e inicializarlas, utilizando el constructor de la clase principal.

Si vemos estas acciones desde el punto de vista de la Inyección de Dependencias y la Inversión de Control, no sería la forma más óptima debido a que la clase que sufre estas dependencias no debería ser la responsable de la creación de las mismas.

¿QUÉ CONSEGUIMOS?

  • Desacoplamiento.
  • Mejora la posibilidad de testeo de la aplicación.
  • Mejor mantenimiento a la hora de realizar cambios de los componentes, gracias a la modularidad.
  • […]

Ambos conceptos están tan ligados que, en ocasiones, no se hace distinción. Se utiliza el concepto Inversión de Control para delegar en otro componente, un framework por ejemplo, la responsabilidad de crear las instancias necesarias en lugar de crearlas nosotros mismos. Por otro lado, la Inyección de Dependencias es el término utilizado cuando una clase depende de otra y, a través del constructor generalmente acepta un parámetro del tipo del cual depende. 

Siguiendo el ejemplo, podemos ver que en lugar de el tradicional mecanismo de instanciación de la clase que necesitamos, por detras existe un interesante mecanismo de Configuración y Factoria de Objetos que nos permiten que en lugar de:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;
public HomeController()
{
_twitterService = new TwitterService();
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Tengamos:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;

public HomeController(ITwitterService twitterService)
{
_twitterService = twitterService;
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Nada mal según parece, usamos interfaces, y se logra una mayor facilidad para pruebas unitarias, lo cual es uno de los objetivos a lograr, pero oh sorpresa… si ahora le hacemos «Go To Definition» al FetchTweets notaremos que ya no vamos a la implementación del método en cuestión (definido en la clase TwitterService), sino al cuerpo de la Interfaz ITwitterService, lo cual detendría nuestra búsqueda en cascada, al no tener mucha idea de cual es la implementación real que se esta invocando, por lo cual nos quedan dos potenciales soluciones:

– Correr la aplicación y en tiempo de ejecución ver la implementación real para así tomar las medidas de análisis necesarias a fin de resolver el problema.
– Tratar de entender la configuración de las dependencias y así inferir cual es la clase que se esperaba instanciar.

Como se comprenderá esta circunstancia puede hacer complicado una tarea de mantenimiento, y la idea de que esas tendencias pueden significar un problema, no en el tiempo de desarrollo, sino en posteriores mantenimientos me han dado vueltas en la cabeza durante un buen tiempo, hasta que encontré este interesante articulo, del cual cito y traduzco:

Yo lo he experimentado de primera mano, en muchos diferentes proyectos donde he tenido que hacerme cargo de codigo despues de que un desarrollador dejo la compañia, y puede ser una experiencia exasperante. Una mejora es solicitada, o un bug es reportado, digamos que se trata de un bug. Se me puede haber dado una excepcion en la pila, y eso al menos me lleva al codigo fuente en donde empezar. Lo que usualmente encuentro es un bonito set de pruebas unitarias que puedo correr y comprobar que todas se ejecutan correctamente, lo cual no es una gran sorpresa; pero, todos los tests usan «mocks» por lo que no puedo reproducir inmediatamente el bug como no sea escribiendo un lindo mock test para simular como el código debería responder ante un particular error de entrada, puesto que yo puedo «mockear» facilmente el error. Eso esta bien, pero no es util si mi objetivo principal es evitar que el error ocurra.

¿Que clase en concreto es la responsable del bug? Aqui es donde se pone complicado, en la mayoria de los casos, la pila no te da ninguna pista. Leer el codigo y examinar la configuración puede ser una enorme perdida de tiempo y termina siendo una tediosa búsqueda en amplitud.

Como el autor apunta «la capacidad para obtener información rápidamente y entender un programa al leer el código es degradada por IoC debido al desacoplamiento», y así.. esa seria la alerta con la que nos deberíamos quedar, ver cual es el lugar de estos patrones, y si la búsqueda de objetivos en este momento como el desacoplamiento y las pruebas unitarias, no vendrían a significar un lastre en el largo plazo, cuando la aplicación tenga que ser mantenida por un equipo diferente.

El paso por mantenimiento de aplicaciones te hace tener en cuenta estas otras consideraciones.

Otro articulo interesante:
Dependency Injection makes code unintelligible

No siempre empezaras desde cero

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.