En los últimos años estamos asistiendo a un cambio radical en la forma de gestionar los proyectos de desarrollo de software. Empieza a resultar extraño encontrar ofertas de trabajo en las que no se mencione scrum, o proyectos que empiecen en los que no se haya planteado el uso de metodologías ágiles. Pero de nada nos sirve una metodología, por muy buena que pueda ser, si perdemos más tiempo gestionando el proceso que programando. Por lo que nos vemos casi obligados a empezar a usar herramientas que nos ayuden con esta tarea. A lo largo de este artículo trataremos una de esas herramientas, que consideramos más potentes: TFS.
En todos los asuntos de opinión, nuestros adversarios están locos (Oscar Wilde). Por suerte los locos con los que puedes compartir opiniones en la lista de correo de la fundación [T]echdencias, son magníficos profesionales como @Marc_Rubino o @mserrate. Hace unos días tuvimos la oportunidad de discutir sobre el patrón “Repository”.
Hace unos meses, me encontraba en un cliente hablando de la posibilidad de sustituir su conjunto de aplicativos para ALM (Application Lifecycle Management o gestión del ciclo de vida de las aplicaciones) por el potente TFS de Microsoft. Se mostró fascinado por la herramienta: estuvimos navegando por el portal, mostrándole las gráficas y lo fácil que era gestionar todo el trabajo. No obstante, el líder tecnológico era escéptico y no confiaba en las capacidades del entorno que estábamos proponiendo.
En el mundo de la programación orientada a objetos una de las máximas que debemos cumplir, si queremos desarrollar un código de calidad, es que debemos buscar una elevada cohesión con bajo acoplamiento. Y con el fin de ayudarnos en esta ardua tarea, aparece el patrón Mediator.
La mayor parte de los problemas que nos podemos encontrar al usar patrones de diseño vienen de no ser capaces de reconocer en qué contextos hay que aplicarlos.