Hace poco me comentaba un proveedor que los resultados obtenidos con Sonar tras realizar el análisis estático del código de las aplicaciones que desarrollaban en su empresa estaban muy condicionados al framework de desarrollo y a las soluciones de generación de código que se utilizaban.
Yo le comenté que no dudaba un ápice, al contrario, del framework de desarrollo utilizado, ya que no solo respetaba las reglas de diseño y codifición establecidas en nuestro libro blanco, sino que además, facilitaba el desacoplamiento de la aplicación a nivel vertical por la existencia de diferentes capas con responsabilidades concretas y además permitía disminuir tiempos de desarrollo. Como todo en la vida es mejorable, pero el nivel que tenía era bastante alto.
Tampoco dudaba lo más mínimo de las soluciones de generación de código, es más me parece muy apropiado que se utilicen este tipo de estrategias ya que además de dar uniformidad a los desarrollos (cogidos de la mano del framework) permiten ahorrar costes de desarrollo.
Calidad y reducción de costes de desarrollo, van unidos de la mano de los frameworks y de los generadores de código. Evidentemente no aseguran nada, ni calidad ni reducción de costes, pero son la base para sustentar desarrollos de calidad a menor coste.
Lo que venía a decirle al proveedor que independientemente de que el framework y la generación de código condicionen una determinada solución, siempre existe el factor humano, ya que hay clases que se tendrán que codificar a mano (incluso subsistemas de negocio completos) y por supuesto la posibilidad de refactorizar determinadas clases determinadas por el framework, sobre todo cuando tengan un alto nivel de acoplamiento.
Es decir siempre es posible mejorar la calidad del código para mejorar la mantenibilidad del sistema. ¿Qué supone un esfuerzo? Por supuesto que sí, pero la clave, como he comentado en tantas ocasiones no consiste en intentar llegar a la perfección, ya que además de no conseguirse, aproximarse a la idea que tengamos de perfección requerirá un esfuerzo (y unos costes) que no merecen, en absoluto, la pena. En estos casos, hay que centrarse en quick wins, centrarse en clases en las que se puede mejorar la codificación y/o bien es necesario realizar una refactorización y en donde estas modificaciones permitan mejorar la calidad global de la aplicación desde el punto del vista del mantenimiento.
Sonar es una herramienta muy útil para detectar este tipo de clases, aunque también sería posible detectar clases candidatas a un alto acoplamiento, antes de desarrollar, mediante la realización de diagramas de clases en los que se refleje las dependencias entre las mismas. Cada una de esas alternativas tiene sus ventajas e inconvenientes. La gran ventaja de Sonar es que te permite medir la calidad desde múltiples puntos de vista e indicarte de manera sencilla qué clases fallan en según qué métricas, su inconveniente es que ya has codificado y todos sabemos que cuánto más tarde se detecten los problemas en la construcción, más costoso resulta corregirlos.
Jummp 