Producir, producir y producir!!!!

Actualmente, estoy trabajando desplazado en un cliente ayudándoles (o al menos intentándolo) al sacar adelante su aplicación interna de gestión, el trabajo es duro y el tiempo es corto… vamos que estamos en la mejor de las situaciones que imagino que muchos de vosotros, por desgracia, conoceréis.

 

De ahí, el tema del “post”, en una situación como la actual lo que se pide a los desarrolladores es que produzcan, produzcan y que produzcan… y que además lo produzcan bien (bueno esto último es un decir). Para ello nos dan una herramienta maravillosa que se llama Microsoft Visual Studio 2008 y una “bonita” solución de… 200 proyectos (y sí, habéis leído bien 200 proyectos!!!).

 

Nosotros le hemos cogido cariño a la solución y es nuestra “bicha”, y la susodicha tarda aproximadamente 20 minutos en compilar… ¿Os podéis imaginar el tiempo que se pierde para corregir una incidencia?……… MUCHO, de hecho muchísimo… además pierdes la concentración y al final pierdes las ganas de arreglar las incidencias.

 

¿Cómo se ha llegado a esto?

La verdad, no tengo ni idea, yo solo pasaba por allí. Pero hay una mezcolanza de arquitecturas y de formas de dividir una solución que al final hay muchísimos proyectos, todos relacionados entre sí y hasta alguna referencia circular… (sí, ya se que Visual Studio no te deja… pero es que también usamos reflection a cascoporro… así que “si quieres, puedes”).

Yo aquí sólo diría que una vez que nos ponemos a intentar organizar una solución y todos sus proyectos, podemos hacer divisiones de ensamblados funcionalmente, o técnicamente… que podemos dividirlos por “LogicaNegocio”, “CapaDatos”, “Modelo”,…. o por “Compras”, “Proveedores”, “Clientes”… pero por favor no los mezcléis porque si no… terminaréis con una “bicha” y os aseguro que no es para nada bueno…

 

¿Por qué tarda tanto en compilar?

La respuesta es sencilla y tiene dos o tres puntos:

1. Son muchos proyectos

2. Los proyectos tienen muchas referencias del tipo “Proyecto” a los distintos proyectos (redundante ¿eh? :-))

3. Existe algún proyecto excesivamente grande o con un número demasiado grande de referencias

Seguro que existen muchas más razones pero estas son las que se me ocurren a mí…

 

¿Se podría reducir el tiempo de compilación?

Sí, y la primera respuesta que se me viene a la cabeza es… “REUNIFICANDO PROYECTOS”, aunque también se podrían poner las referencias a ensamblados previamente compilados y no tardaría mucho, o intentar redefinir los proyectos con un elevado número de referencias.

 

¿Tiene algún tipo de fundamento reorganizar el código en menos proyectos?

Una vez visto el problema que tenemos en la parte de desarrollo y no olvidando nunca que nuestra función fundamente es producir, producir y producir un poquito más, estuve buceando un poco por Internet y preguntando a algún que otro crá de esto de la informática y al final creo que el sentido común es lo que triunfa.

Así que es mejor tener un proyecto un poco más grande que tener cinco proyectos pequeñitos, y cuándo este número crece mucho, se hace bastante importante, porque:

1. Se reduce el número de proyectos (esto es obvio)

2. Se reduce el número de referencias

3. Se puede evitar el efecto “rebase” (esto no es muy importante cuando se tienen pocos proyectos pero bueno… algo es algo)

4. El JITTER utiliza menos tiempo

5 …

 

Esto viene todo de un bonito sitio que se llama “Microsoft Pattern & Practices” y bueno parece que estos chicos saben un poquillo de esto, os dejo los links que son bastante aclaradores.

http://msdn.microsoft.com/en-us/library/ms998547.aspx#scalenetchapt05_topic33

http://msdn.microsoft.com/en-us/library/ms979052.aspx

 

¿Conclusión?

Bueno la conclusión es sencilla… da igual de qué forma se optimice el tiempo de compilación pero es un tiempo que debería ser nulo o muy pequeño si no queremos que el ritmo de producción se vea alterado por otras causas ajenas a nuestras meteduras de pata. Yo en este cliente en particular intento reducir el número de proyectos.

 

Perdonad por el rollazo, este es mi primer post de lo que espero sea una larga lista de ellos, y no tengo intención de que sean de este tipo si no algo más orientado a ayudas con el código para hacer ciertas cosas, pero es que este tema me tiene comidita la moral y creo que es muy importante que nosotros los desarrolladores no nos muramos cada vez que intentemos compilar una solución.

5 comentarios sobre “Producir, producir y producir!!!!”

  1. Mario, sin conocer a fondo la aplicación es muy difícil ayudarte, a mi juicio 200 proyectos me parecen excesivos, creo que aproximadamente 50-60 sería un buen límite para una gran aplicación, contando con los proyectos de testing que podrían estar incluso en una solución aparte, podrías también dividir el proyecto en varias soluciones, esto os puede dar mayor versatilidad, además podéis utilizar las librerías de los demás proyectos sin necesidad de recompilarlas cada vez.

    El rendimiento de visual Studio sobre todo al compilar es desastroso, pero podéis minimizarlo, seguro que hay proyectos que no sufren muchos cambios, podéis hacer que la aplicación no compile estos por defecto, también podrías utilizar discos SSD y equipos modernos, con esto los tiempos podrían reducirse en más de 30 o 40 %, por los proyectos que me hablas, deberíais utilizar capas basadas en generics para reducir vuestro código, utilizar interfaces y aprovechar las ventajas de la herencia, tanto de formularios, controles y clases, me imagino que esto ya lo estéis haciendo, espero haberte ayudado, yo tengo muchos problemas de rendimiento y mi solución no sobrepasa los 40 proyectos, pero hemos logrado reducir con mucho esfuerzo los tiempos de compilación.

    En cualquier caso la reunificación de proyectos os puede aportar un poco mas de velocidad, pero no creas que va a ser la solución a tus problemas.

    Espero haberte ayudado, saludos.

  2. Por curiosidad ¿habéis probado a pasarle el NDepend? Puede ser útil, aunque no sé cómo se comportará con 200 proyectos a la vez. Si no lo conoces te sirve por ejemplo para ver referencias circulares, dependencias entre proyectos y tambien para hacer todo tipo de métricas.

    Espero que te sirva de algo.

  3. 200 proyectazos!!! me parece una barbaridad!!!
    Estoy de acuerdo con Juan Irigoyen, creo que se puede optimizar mucho el tiempo de compilación. Además de todo eso pienso que deberíais desacoplar proyectos en módulos mas pequeños (si es posible) y delegar las compilaciones completas a un servidor de integración continua.
    En cualquier caso, bienvenido!! y espero que encuentres la manera de optimizar la producción… por aquí se mueve gente que sabe mucho y seguro que te echan una mano 😉

  4. Porque he leido que eres de Murcia, sino pensaría que estabas en un proyecto que conozco de oidos aquí en Madrid. Creo que lo 1ro es «filtrar» aquellos proyectos que realmente son necesarios, no me creo que los 200 sean necesarios, refactorizar un poco y comenzar a tirar compilaciones contra ensamblados en lugar de contra proyectos.

    Otra cosilla es revisar este gran post http://www.xoreax.com/webhelp/pages/advanced_improv_vc.htm, donde se comentan algunos trucos de bajo nivel para incrementar los tiempos de compilacion. Ojo que algunos son un poco peligrosos, pero si lo que quieres es ser más productivos y bajar esos 20 minutos (monstruosos) de compilación, seguro que algo te sirve.

    Asi que ya nos contarás que tal y suerte !!!

  5. Bruno… soy de Murcia, aunque afincado en Madrid… pero sí… trabajo en Avanade y trabajo en ese proyecto… :)… en fins… cosillas del direto

    Las ideas que tenemos para realizar es, lo primero refactorizar y minimizar el número de proyectos y seguidamente reducir el número de referencias.

    Por cierto los proyectos de Test están ya fuera… es que si no eran 234 proyectazos….

    Os comento que estamos trabajando en ello y de momento hemos bajado a 175 proyectos… pero como bien decís… la ideas es bajarlos a 60 o 70… aunque vistas las cosas con 100 proyectos me daría cómo satisfecho…

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *