Tengo la suerte de poder compartir conocimientos con una gran diversidad de profesionales y entre ellos con un nutrido grupo de desarrolladores. En este sentido a menudo soy espectador de cómo somos víctimas de nuestra propia sinergia y obviamente a menudo nos vemos sorprendidos por utilizar o adoptar técnicas incorrectas simplemente porque así lo hicimos o mal entendimos desde el principio. Me encanta compartir esto con vosotros, pues son historias que algunas veces ponen al descubierto las mas retorcidas formas de interpretar la tecnología en nuestro “aburrido” día a día… para los que no quieren convertirlo en “divertido”.

Intentare abreviar e ir al grano pero creo que será difícil, os explicare que se trata de la forma en que gestionamos nuestros proyectos, si bien en equipos organizados el propio control de código nos ofrece herramientas suficientemente sofisticadas para evitar las malas prácticas, conduciéndonos y aplicándonos metodologías sobradamente contrastadas; existe aún un gran grueso de pequeños equipos de desarrolladores que “a su bola” realizan su trabajo en un frenético pulso por sacarse las tareas de encima sin reparar en las graves consecuencias a nivel de costes horarios cuando dejan de ocupar su puesto de trabajo.

Dicho esto, la semana pasada recibí una llamada de un buen colega, pidiéndome soporte para averiguar si podíamos entender unos inexplicables problemas con alguno de los proyectos que un antiguo empleado había liderado y al parecer era un problema de gran magnitud.. Por supuesto mi interés en entender tal misterio fue tan poderoso que no tarde ni una hora en acudir.

Recordad: Los grandes problemas se resuelven con pequeñas soluciones 🙂

Se trataba de un equipo de tres desarrolladores, creando sus proyectos en un recurso compartido “mal hecho!”, cada uno gestionando su parcela “el colmo!” y para rematarlo algunas librerías y proyectos eran base para compartir “peor imposible!” , puede parecer irreal pero os aseguro que es real y esta situación se produce en mas ocasiones de las que podemos imaginarnos.

El problema radicaba en que ciertos proyectos parecían no compilarse adecuadamente o que las referencias a ciertas partes en común no terminaban de contener la totalidad de las funciones diseñadas. Ummm… ciertamente extraño.

Al dar un vistazo por alguno de los proyectos base, pude observar que se compilaban como parte de la solución, sin embargo en otros proyectos más simples en vez de crear una solución conteniendo los distintos proyectos, se hacía referencia a clases que estaban ubicadas en “ese recurso compartido”, cuál fue mi sorpresa al observar que el antiguo empleado, cuando necesitaba alguna clase base para su proyecto… simplemente la añadía al proyecto! Sin atinar que cuando simplemente utilizas la opción de “Agregar Elemento Existente” en el explorador de Visual Studio lo que estás haciendo es una copia del “archivo en cuestión” a la ubicación de tu proyecto, por lo tanto cuantas modificaciones sobre el mismo serán para ese proyecto y no del origen del mismo.

Después de investigar algunos de los proyectos en los que “el antiguo empleado” había trabajado, nos quedo un rastro de algunas decenas de clases con el mismo nombre en diferentes proyectos y por supuesto diferentes contenidos, supongo que dicha persona nunca llego a entender lo que realmente estaba haciendo, pues en otro caso debo pensar que fue negligencia total.

Salvando las distancias quiero pensar, que en algún punto del camino cuando este profesional aprendía como utilizar las herramientas, no presto suficiente atención para entender que existen dos formas distintas para añadir un “elemento Existente”… está claro que el escenario de una clase compartida en un recurso compartido la opción correcta no es “Agregar”, si no “Agregar como Vinculo” solo debería haber prestado un poquito de atención en el combo que ofrece las opciones de agregar, supongo que ello hubiera ahorrado un montón de angustias.

Finalmente y a titulo de reflexión, tal y como empecé diciendo me gustaría pensar que somos víctimas de nuestras propias sinergias y desgraciadamente no atinamos en ellas hasta que alguien atina a explicarlas. Bien para que no quede en entredicho, si por alguna de aquellas casualidades alguien más desconoce este matiz, estar encantando de haber sido útil.

Recordad: Los detalles más insignificantes son los que causan los problemas más graves! 🙂

IMPORTANTE: La version “Basic” de Team Fundation es gratis!… que excusa tienes ahora?

Saludos,
PepLluis,