Acabo de heredar 200,000 líneas de código espaghetti. ¿Y ahora qué?

Acabo de heredar 200,000 líneas de código espaghetti. ¿Y ahora qué?

Esta es la interesante pregunta que ha planteado Kevin Mote en stackexchange.com ,  Acabo de heredar 200,000 líneas de código espagueti. ¿Y ahora qué? Algo que seguramente nos habrá sucedido a todos, algunos con mayor o menor medida dentro de la implicación en el nivel de toma de deciciones, pero que afecta por completo nuestro equipo.

Kevin acaba de conseguir un nuevo trabajo en una pequeña empresa como un ingeniero de software y acaba de heredar una base de código que ha sido desarrollada durante dos décadas por un conjunto de personas con bastante conocimiento sobre el dominio de aplicación, pero con pocos conocimientos sobre ingeniería de software. Como es de esperar dados esos antecedentes, desde un punto de vista de arquitectura y mantenebilidad el código es un desastre

Decir que “las demas personas tienen poco conocimiento sobre ingeniería de software” es como mínimo arriesgado, ya que en este mundo la tecnologia avanza muy rápido.  Nos quedamos  con que  “ha sido desarrollada durante dos décadas” . 20 años es mucho tiempo para un software, y ademas tienen bastante conocimiento sobre el modelo de negocio.

Kevin Mote recibió muchas y valiosas respuestas. Detallaré algunas, pero sin duda en los comentarios de la comunidad esta el verdadero valor de esta charla.


  • Definir una estructura rígida de proyecto con plantillas de proyecto, convenios de código, sistemas de build y guías de uso para toda la infraestructura y las herramientas.

  • Instalar un sistema de control de versiones y enseñar a todo el mundo a usarlo. Parece algo de lo mas básico pero  se ve de todos en los reinos del señor. SVN es casi el estandar para el control de versiones de proyecto, pero , ¿ Has probado usar Git o Mercurial? ¿Conoces las ventajas de estos sobre svn o cvs?

  • Emplear sistemas de chequeo de calidad de código y sistemas que generen métricas sobre el código automáticos. Algo que muchos catalogan como “coloritos para frikis” puede ser de mucha ayuda para detectar donde se esta acumulando los errores en tu código y con un simple vistazo.   Sonar cumple con creces.

  • Emplear sistemas de integración continua CI.  Algo que yo considero impresindible dentro de los Pincipios de Desarrollo de Software Moderno

  • Elegir un buen entorno de desarrollo y enseñar a todo el mundo a usarlo.  IDEs + Task List + Task Focus

  • Aislar y blindar el código legacy, para minizar los puntos de contacto, controlarlos, y facilitar el refactoring. Si algofunciona, no lo cambies reza el proverbio popular así que antes de comenzar a hacer refactoring y disparar balas desde el cinturon cual vaquero del antiguo oeste aisla tu código antiguo.

  • Identificar los puntos más desastrosos de la base de código y comenzar a refactorizar por ahí.

  • Crear pruebas funcionales para testear el buen funcionamiento de la aplicación. Hay quien recomienda crear pruebas unitarias pero….. ¿Sirven de algo las pruebas unitarias para un codigo legacy y que no fue pensado para crear pruebas unitarias? Ademas del acoplamiento que debe tener ese código.


Ahora comentare algunas cosas que NO DEBRIAS HACER

  • Reescribir el codigo desde cero. ¿Alguien se acuerda de Netscape ? Desde el varapalo que se dió Nestcape al reescribir todo su código viendo como IExplorer lo desbancaba como numero 1, parece mentira que las personas tropiecen con la misma piedra pero es que subvaloramos el conocimiento del negocio de X años de otras personas y confiamos en nuestras habilidades como arquitectos/programadores etc. Si no te convences mira lo que dice Joel Spolsky


Aqui hay solo algunos puntos, puedes profundizar en  los comentarios.

via | JavaHispano

artículo original | Programmers Stackexchange