Crónica de una muerte anunciada, por estrangulamiento – Parte II

En la introducción ya mencione los móviles y las justificaciones por la cuales creo que lo correcto es renovar casi desde cero un sistema. Ahora en este post nos toca describir al sistema a renovar, junto con las herramientas y una idea del nuevo sistema, comencemos.

La Victima

El sistema a remplazar técnicamente no es un sistema en si, en este momento son un conjunto de herramientas separadas pero que son usadas en conjunto para ayudar a los desarrolladores de la empresa donde estoy trabajando a que puedan completar las tareas de puesta a punto de sus entornos, actualización de código y debugging.

Se preguntaran cuan grande es el sistema que manejan acá para necesitar herramientas extras, a parte del IDE y el repositorio de código con su respectivo cliente, y bueno, solo les puedo decir que es enorme y se necesitan mas de 100 desarrolladores trabajando en paralelo para poderlo mantener.

Para simplificarlo, dividiremos nuestro requerimiento en tres secciones:

  • Entorno de Desarrollo
  • Debugging
  • Testing

Todas estas herramientas están construidas para ser ejecutadas sobre el escritorio de Windows y en su mayoría están escritas con C# y Windows Phone. Muchas de las aplicaciones tienen toda la lógica en sus code-behindes y en un solo archivo, generando una baja reutilización de código.

Con esta división por secciones, se nos simplificara la tarea de buscar denominadores comunes e identificar las funcionalidades repetidas o las funcionalidades que existen únicamente para la comunicación entre las aplicaciones isla, además de que podremos identificar el flujo de trabajo de los usuarios y así intentar simplificarlo.+

Características del nuevo sistema  y las herramientas

El nuevo sistema que vayamos a crear debería de cumplir un conjunto de características para que sea lo mas exitoso posible en su ciclo de vida, y de tal manera de que sea fácil de mantener y que cuando cumpla su ciclo de vida sea fácil de estrangular, esta parte es muy importante, ya que si nuestro sistema nace con la concepción de que en algún momento a mediano plazo debe morir (con mediano plazo, me refiero a un tiempo no muy lejano, donde gran parte de los desarrolladores que lo hicieron aun estarán trabajando en el proyecto al momento de estrangularlo y casi de seguro ellos mismos harán esa tarea), deberemos pensar que lo mas conveniente será que podamos reutilizar sin demasiado cambio un gran numero de secciones del sistema, para facilitar la migración. En analogía con el tema de loa autos, podríamos decir que lo mas conveniente es reutilizar sin mucho cambio la tecnología que creamos para las ruedas o para los seguros de las puertas o para la llave de encendido.

Ya definidas las características, pasemos a las herramientas que nos ayudaran a crear nuestro sistema:

  • Windows Presentation Foundation
  • PRISM
  • MEF
  • Microsoft Enterprise Library
  • xUnit
  • CruiseControl .NET
  • MSBuild
  • Unity

El sistema debería de trabajar de la siguiente forma:
mock
Donde tendremos una barra de accesos directos a los módulos, cada modulo es independiente y gracias PRISM es cargado en tiempo de ejecución como un Plug-in de tal forma que fácilmente cada modulo puede ser mantenido independientemente.

En la siguiente entrega hablaremos en profundidad de algunas herramientas y la puesta a punto del proyecto básico.

Crónica de una muerte anunciada, por estrangulamiento -Introducción

“Crónica de una muerte anunciada” es una novela publicada en 1951 del autor Gabriel García Márquez que ciertamente no es muy de mi agrado, pero que posee el titulo perfecto para la serie de post que planeo publicar a lo largo de estos meses venideros.

Para los que no hayan leído la novela, acá un pequeño resumen extraído de Wikipedia:

En un pequeño y aislado pueblo en la costa del Caribe, se casan Bayardo San Román, un hombre rico y recién llegado, y Ángela Vicario. Al celebrar su boda, los recién casados se van a su nueva casa, y allí Bayardo descubre que su esposa no es virgen. Cuando lo descubre, devuelve a Ángela Vicario a la casa de sus padres, donde su madre la muele a golpes. Ángela culpa a Santiago Nasar, un vecino del pueblo.

Los hermanos Vicario –Pedro y Pablo-, obligados por la defensa del honor familiar, anuncian a la mayoría del pueblo que matarían a Santiago Nasar. Nasar no se entera, sino minutos antes de morir. Los hermanos matan a Santiago, después de pensarlo en varias ocasiones, en la puerta de su casa, a la vista de la gente que no hizo o no pudo hacer nada para evitarlo. A los 27 años, el mejor amigo de Santiago (el narrador) reconstruye los hechos de los que él fue testigo.”

La pregunta es, cuál es la motivación para que haya elegido el presente título, tan poco común para un blog técnico y además de la curiosidad, de ¿qué es lo que vamos a matar y de paso porque por estrangulamiento? Y principalmente, ¿porque vamos a tomar esa difícil decisión de eliminar algo?

Pues digamos que en este universo, no hay nada eterno, todo tiene un ciclo de vida, desde su concepción hasta su muerte, y esto ciertamente también se aplica al software.

¿Entonces hablamos de eliminar un sistema de software?, pues ciertamente si y no estamos hablando de cualquier sistema, hablamos de un tipo en particular, los sistemas empresariales.

Este tipo de sistema, tiene dos características importantes a mi parecer, la primera es que posee mucha lógica de negocios acumulada a lo largo de los años de vida y lo segundo que sus usuarios son muy renuentes a cualquier tipo de cambio.

Todo aquel que en algún momento haya trabajado en alguna aplicación empresarial sabe que tratar de remplazar una aplicación empresarial, con otra escrita desde “cero” es una locura, ya que ocasionaría un costo en tiempo y en dinero excesivo que no justificaría tomar el riesgo, sin embargo estos temores no son ciertos al cien por ciento. Hay veces en los que el mantener un sistema legado es por demás costoso, al punto que justifica embarcarse en esta riesgosa empresa de rehacer el sistema.

Por lo general un software empresarial después de haber sido puesto en producción entra en la fase explotación, donde se van arreglando bugs o agregando algunas funcionalidades no contempladas en la fase de desarrollo, esta fase muchas de las veces se extiende por años, sin embargo con el pasar del tiempo, el código del sistema se va ensuciando por varios factores, como por ejemplo funcionalidades nuevas que el cliente desea pero que requieren tocar partes estructurales del sistema para ser implementadas o por el crecimiento del equipo de desarrollo o el cambio de algunos miembros, que provocan que se asiente esta capa de suciedad sobre el código. Además no hay que olvidar también que algunas veces se construye software empresarial con ingenieros de software no muy experimentados que están encargados de la arquitectura del sistema y esa falta de experiencia hace que se agregue por lo general una capa extra de complejidad al sistema por un desarrollo no muy bien estructurado.

Este proceso común genera que este software, después de un periodo de unos 5 a 6 años, sea tan costoso, estresante y difícil de mantener que entra a una etapa que me gustaría denominarla etapa de “agonía”. Y cuando uno tiene un software en esta etapa, tenemos dos caminos, siendo el primero realizar un proceso de refactorización o el segundo camino que es construir uno nuevo.

Por lo general la idea de la refactorización es la más aceptada, tanto por los usuarios como por los dueños del software, ya que ofrece una menor cantidad de riesgos a simple vista, como costos bajos a corto plazo, tanto en tiempo como en dinero. Sin embargo muchas de las veces tomar este camino, no es el más adecuado y como una analogía para aclarar el punto, usemos autos.

Supongamos que nuestra aplicación en etapa de agonía, es un Volkswagen Golf 1990 como el de la primera fotografía y después de refactorizar obtendremos el auto de la segunda fotografía:

before

after

Ciertamente, después del proceso de refactorización, el producto se ve mucho mejor, sin embargo como podemos verlo gráficamente en la fotos y como sucedería con una aplicación, a pesar de que se hicieron cambios, aun se ve y se siente como un auto de 1990 ya que hicimos mejoras sobre la carrocería y el chasis de un auto de 1990 con materiales que datan de 1990, lo cual nos limita para que podamos obtener un producto mucho mejor y más acorde a la fecha.

Ahora supongamos que decidimos tomar el camino de rehacer la aplicación, el resultado que obtendríamos sería algo así:

Golf-GTI-2014-nunca-igualado

Ciertamente será más costoso a corto plazo en dinero como en tiempo, pero nos entregara un resultado más satisfactorio, porque no tendremos las limitantes que conlleva usar un chasis y una carrocería de más de 10 años de antigüedad, de igual modo con nuestro proyecto de software hecho desde “cero”, no tendremos la limitantes de un diseño de hace muchos años. Además de que nos proveerá algunas de las siguientes ventajas:

  • Uso de tecnología moderna, hace 10 años, no existía por ejemplo ASP.NET MVC o WPF
  • Mejor adaptación a los requerimientos actuales, 10 años antes, solo usábamos PDAs para leer emails y un poco más, al día de hoy usamos Tablets, Smartphones y PC con pantallas táctiles en conjunto para realizar muchas tareas empresariales.
  • Crear una aplicación desde “cero”, apasiona a los desarrolladores.
  • Uso de nuevas técnicas de prevención de errores, como las pruebas unitarias.
  • Menor costo de mantenimiento de tecnologías legacy, usar componentes y Frameworks de última generación, en aplicaciones con un diseño estructural de hace 10 años, requiere más esfuerzo para que se adapte a estructura antigua.

Por último, mencionar un punto importante y por el cual muchos de los riesgos que a simple vista parecen muchos, no lo son tantos y es que cuando la primera versión de la aplicación empresarial fue desarrollada, los requerimientos no eran para nada claros lo cual hizo que en muchas de las ocasiones el cliente no obtuviera lo que deseaba o lo obtuviera con mucho retraso o por partes, sin embargo si rehacemos la aplicación por segunda vez, ciertamente no estaremos empezando desde cero, ya que sabremos realmente que quiere el usuario y como lo quiere. Volviendo a la analogía de los autos, cuando desarrollamos la primera versión, solos sabíamos que el usuario quería un automóvil, no sabíamos si quería 3 o 5 puertas o si quería un motor con turbo o si prefería gasolina en vez de diésel, sin embargo para cuando lo rehacemos, sabemos que el usuario quiere un auto de tres puertas con un motor a gasolina de 3.2 litros, con un sistema biturbo y con un sistema de cambios de velocidad manual de 5 velocidades. Ciertamente errar en la segunda vez es mucho más difícil sabiendo lo que se desea obtener, además de que tendremos la aplicación legacy para comparar, este es el motivo por el cual uso el “cero” en muchos de los párrafos anteriores.

¿Qué enfrento y como la mato? – Van Helsing

Ya habiendo sentado las bases de porque es mejor tomar la opción de rehacer el sistema, solo queda ponerse las manos a la obra y como diría Van Helsing, solo es necesaria una pregunta doble: ¿Qué enfrento y como la mato? La respuesta a la primera parte de la pregunta varía de sistema a sistema y cada uno sabe a qué clase de sistema legacy se enfrenta, ahora la segunda parte es un poco más clara, y diremos que una de las mejores maneras de eliminar a ese sistema legacy es a través de la estrangulación.

Se preguntaran porque la estrangulación, y la respuesta es para la reducción de riesgos, como indica muy bien Matin Fowler:

“The most important reason to consider a strangler application over a cut-over rewrite is reduced risk. A strangler can give value steadily and the frequent releases allow you to monitor its progress more carefully. Many people still don’t consider a strangler since they think it will cost more – I’m not convinced about that. Since you can use shorter release cycles with a strangler you can avoid a lot of the unnecessary features that cut over rewrites often generate.” — Martin Fowler, Chief Scientist, ThoughtWorks, on The Strangler Pattern

La analogía que plantea Martin en su blog, es genial, pero me gustaría cambiarla por la de una Boa Constrictora, ya que la Boa es mucho más rápida y esto tiene que ver desde el punto de que si nuestro nuevo sistema tarda mucho tiempo en ser lanzado, podría ser considerado un fracaso, además de que tiene que ser letal contra el sistema legado, propiciando que el usuario final quiera saltar al nuevo sistema ni bien tenga la oportunidad por los beneficios que le ofrece, ya que casi de seguro, durante un tiempo tendremos los 2 sistemas funcionando en paralelo.

Estrangulación en Directo

Al principio de esta entrada mencione, que esto es el primer post de una serie de posts y esto es porque tengo la intención de estrangular un sistema e ir describiendo el proceso para que sea como una guía ejemplificada de como se lo debe hacer, además de que el describir el proceso me ayudara a supervisar el proceso.

En mi próxima entrada describiré el sistema a estrangular y que características debería tener el nuevo sistema, aunque advierto que no hare mucho énfasis en los detalles del sistema ya que es un sistema interno de la empresa en la que trabajo por lo que no puedo dar detalles, así que procurare que sea lo más general posible.