Mes: febrero 2008

Esta semana he tenido el placer de participar en el evento de  lanzamiento de los nuevos productos de Microsoft: Visual Stuido 2008, Windows 2008 y Sql Server 2008.

Compartí dos ponencias con Bruno y Luis, y la verdad fue un placer. Además sobre todo por que entre ambos, magos del Power Point, se han encargado de hacer las ppts del evento (parte que odio jejejeje…) Gracias titanes!!! No se me ocurre mejor equipo para hablar sobre la versión Team de Visual Studio.

Entre los tres presentamos dos ponencias: una sobre las novedades de Team System en su versión 2008 y otra sobre colaboración con Team System. Da gusto trabajar en equipo, con gente de otras empresas, que incluso son competencia con el único afán de ayudar a la comunidad.

Luego, ya solito y sin el amparo de estos dos cracks, presente una ponencia titulada Scrum y Team System en el mundo real. Traté de contar mis experencias con Scrum como metodología y Team System como herramienta. El exito de público fue notable, con la sala a rebosar, e incluso la duración se alargó más allá del tiempo previsto (ventajas de se el último del día) y no se movio ni un alma (alguna ventaja tiene que tener medir casi dos metros y pesar ciento diez kilos jejejej…). Como al resto de ponentes la sesión se me quedo corta. Os dejo, por cierto, como adjunto, la ppt que usé, por si alguien está interesado.

Otra cosa notable del evento fue ver a todos los habituales de la comunidad y poder charlar de tecnología con un motón de gente apasionada por la tecnología y el desarrollo de software. No cito a nadie en concreto para no olvidarme de nadie. Una pena que no me pude quedar a la fiestuqui y tener aun más rato para charlar con el motón de geeks que andaban por allí.

En el blog de Luis Fraile, se ha planteado una interesante reflexión a raíz de unas palabra mías en el TTT. Vaya por delante el decir que creo no fueron del todo correctas desde un punto de vista purista. Yo afirmé algo como «en TDD da igual escribir las pruebas antes que después», cuando lo que debería haber dicho es: «En mi opinión, lo importante es escribir pruebas, da igual antes que después». Cuando una sala esta llena de gente de gran nivel, cualquier error es sacado rápidamente a la luz, algo que siempre ayuda: «Cuanto antes se descubre un error menos cuesta», dice una máxima de calidad del software. La corrección está hecha (no lo he visto pero seguro que Luis ya lo ha cambiado). En la ppt ahora hablará genéricamente de pruebas unitarias en lugar de TDD.

En TDD, sin duda, las pruebas se deben escribir antes. No es opcional si queremos decir que realmente seguimos las reglas de TDD. No hay discusión en esto si nos ponemos estrictos. Y los defensores a ultranza de está técnica esgrimen una serie de ventajas, que sin duda son ciertas, pero que en gran medida se obtienen también escribiendo las pruebas a posteriori.

En cualquier caso, desde mi experiencia, escribir las pruebas antes o después es un matiz que yo creo que se debe dejar en manos de cada desarrollador. Cada uno que haga lo que mejor le parezca y más cómodo le resulte. Quiero que los desarrolladores se sientan cómodos a la hora de escribir pruebas ante todo.

Yo, personalmente, uso un enfoque más bien mixto, eso sí cada vez más sesgado hacia escribir antes las pruebas. Hay veces que veo claro que test debo escribir y me lanzo ha escribirlos antes que la clase, hay veces que escribo primero la clase. Casi siempre que escribo los test antes, luego suelo tener que escribir alguna prueba más después para alcanzar cobertura suficiente. Tal y como yo lo veo, creo que escribir las pruebas antes, tiene una curva de aprendizaje mayor que escribirlas depués.

De todos modos, si yo escribo pruebas después del escribir el código (para cada porción pequeña de código, nunca cuando tengo cientos de líneas acumuladas que ya es tarde), las ejecuto con frecuencia y siempre antes de integrar código en el gestor de fuentes, integro las pruebas en la build, me preocupo por que sean rápidas y sobre todo tienen covertura suficiente, etc, etc… ¿No estoy haciendo TDD? En sentido estricto no, pero desde un punto de vista de la filosofía y ventajas que hacer pruebas unitarias aporta, si. Puedo asegurar que, aun escribiendo los test después, estos guían mi desarrollo de manera determinante. Y en un sentido amplio TDD = Desarrollo guiado por pruebas.

Interesantísimo el link que nos ha dejado El Bruno en los comentarios del post de Luis: TDD Proven Effective! Or is it? que viene a dar la misma conclusión que yo trato aquí: no hay grandes diferencias entre escribir pruebas antes o después, pero lo que nadie discute es que hay que escribir pruebas. Se le pedia a Luis responsabilidad y demás, pero la verdadera responsabilidad que tenemos es que todo el mundo sepa de las ventajas de las pruebas unitarias.

Resumiendo escribe pruebas unitarias, eso no es opcional, y luego si quieres llámalas Trinidad…

Todos sabemos que los adminsitradores de red son gente dura de roer. No conozco muchos que estén contentos dandonos acceso por SMTP a ‘su’ servidor de correo (cosa que me parece muy razonable dicho sea de paso). Pero es cierto que cada vez más y más aplicaciones necesitan por un motivo u otro enviar correos electrónicos.

Antes lo que los desarrolladores haciamos era simplement instalarnos un servidor SMTP en nuestra máquina (si las políticas de nuestro administrador nos los permitian), pero esta opción ha perdido validez con la llegada de Windows Vista que no incluye servidor SMTP en ninguna de sus versiones.

Una características que he descubierto por pura necesidad a la hora de escribir el testeo unitario de una aplicación es la posibilidad de configurar las clases de mensajeria del framework de .Net para que en lugar de enviar el mensaje por SMTP simplemente lo dejen un directorio.

Para ello es suficiente añadir las siguentes líneas a nuestro archivo de configuración:

De esta manera, la clase SmtpClient generará un mensaje de correo y lo pondra en el directorio especificado (c:TestMessages en el ejemplo) en formato .eml.

Ayer celebramos otro evento de Artalde: Ven a llorar con nosotros sobre metodologías, tal y como hace algún tiempo anunció mi amigo Ibón Landa. Ibón y yo tratamos de dinamizar el evento y de responder a algunas de las interesantes cuestiones que los presentes plantearon.

Hicímos una brevísima introducción a las metodologías más usadas comparandolas entre ellas someramente.

Se hablo mucho de metodologías ágiles y se plantearon las cuestiones habituales que siempre surgen cuando se habla de metodologías: la dificultad de llevarlas a cabo, las importancia de las personas, la dificultadad de encontrar sponsors, cómo dar el peso adecuado a la documentación y como mantenerla actualizada, la importancia del testeo unitario para reducir el impacto de los cambios, la dificultad de la relación con el cliente, se cuestiona la validez de las metodologías ágiles para proyectos cerrados (espero haber convencido a la gente de que también sirven para este tipo de proyectos)…

En general un evento muy divertido, en el que mucha gente participo dando su paracer y contando sus experiencias, precisamente lo que buscamos en este tipo de eventos…

Dejo como complemento al post la presentación que Ibón preparó, por si alguien la quiere usar en algún evento similar, aunque la verdad es que no pasamos de la cuarta diapositiva.

¡Gracias a todos los asístentes!

Ya he hablado en este blog varias veces sobre revisiones de código, métricas y calidad del código, hoy llega el momento de unir ambos aspectos del desarrollo de software en una divertida viñeta que además está llena de verdad: Las veces que dices ‘pero que coño es esto’ cuando revisas código es inversamente proporcional a su calidad.

 

Un poco de humor cargado de verdad.

Artículo originalmente publicado en dotNetMania.

La documentación siempre es un aspecto que exige nuestra atención en los proyectos de software. A menudo tendemos a pensar que la mejor manera de lograr que nuestros proyettos avancen y poder mostrar ese avance es realizando la documentación adecuada, buscando el ciclo adecuado para esa documentación y estableciendo una serie de documentos como estándares. Incluso hay metodologías bastante populares que se centran en definir qué documentos se deben generar, quién es el responsable de cada documento y por qué manos debe pasar cada uno de ellos. ¿Nos olvidamos de que los documentos no se pueden ejecutar? ¿Nos olvidamos de que el propósito final de todo proceso de desarrollo es conseguir software que funciona?

A menudo,de la documentación que mantenemos durante el desarrollo solo un pequeño porcentaje tiene valor para el cliente. Es cierto que habitualmente hemos de entregar cierta documentación, manuales de operación, de administración o de usuario; esta documentación tiene un claro valor. Este tipo de documentación se debe tratar como cualquier otro entregable. En el fondo, ésta es la única documentación que es realmente imprescindible, la que el destinatario del software necesita, aquella por la que, hipotéticamente, estaría dispuesto a pagar. Minimizar la documentación que no aporta nada a nuestros clientes, que solo sirve para soportar nuestro proceso de desarrollo, y sobre todo el coste de mantenerla, debe ser uno de nuestros objetivos.

El avance de los proyectos de software es algo que siempre ha preocupado a todos los implicados en los mismos. Es algo sobre los que nuestros clientes centran su interés y algo que, como gestores de proyectos, necesitamos comunicar. Tradicionalmente hemos abordado esta necesidad de mostrar el progreso mediante el uso de diferentes documentos o artefactos. Todos los que hemos tenido que mantener actualizado “el project” del proyecto sabemos lo difícil que esto es. Es tan difícil, que rara vez se hace con la disciplina que requiere, de tal modo que habitualmente este tipo de aproximación no proporciona los resultados esperados.

El enfoque tradicional de mostrar el avance de los proyectos mediante documentos es algo que no funciona bien. Nuestros clientes han descubierto que los documentos rara vez nos muestran el avance real de un proyecto. Es muy posible haber trabajado mucho y tener una gran cantidad de documentación sobre un proyecto y estar a años luz de que quien financia el proyecto pueda obtener valor. ¿Quién no conoce algún proyecto en el que tras muchos meses de desarrollo lo único que había es un montón de documentos? Los documentos por sí mismos no aportan ningún retorno de la inversión. No se puede hacer nada para obtener valor para tu negocio solamente con la documentación relacionada con un proyecto de software. Solo el software que pueden ejecutar y utilizar es susceptible de crear valor para nuestros clientes. Solo el software que funciona debe ser la medida del progreso de los proyectos de desarrollo. Asumir esto nos obliga a asumir que tendremos que entregar software con frecuencia a nuestros clientes, que tendremos que reaccionar de manera ágil al feedback que nos proporcionen y que a cambio ellos obtendrán de manera temprana un retorno para su inversión.

Debemos ser muy tacaños con el esfuerzo que ponemos en nuestra documentación; si no, corremos el riesgo de ver que todos aquellos requisitos, por poner un ejemplo, que tan detalladamente documentamos sobre el sistema de gestión que nuestro cliente quiere, son papel mojado porque han comprado una nueva unidad de negocios. Y nosotros ya hemos hecho un gasto del que difícilmente obtendremos algún retorno. La documentación en los proyectos de software pierde su relevancia y se queda obsoleta muy rápidamente, haciendo que mantenerla actualizada sea muy costoso. A menudo cometemos el error de tratar de sustituir la comunicación fluida por documentación, y cuando hacemos esto, estamos introduciendo costes e inflexibilidades en nuestro proceso de desarrollo.

Otro aspecto del desarrollo de software que nos lleva a generar documentación es la necesidad de mantener los sistemas que desarrollamos. Se suele pensar que la documentación detallada del sistema nos va a evitar un montón de quebraderos de cabeza. Pero esto solo es cierto si esa documentación cumple la premisa de estar actualizada. Cuando un desarrollador encuentra una línea en la documentación que no es correcta o no está actualizada rápidamente pierde la confianza y vuelve su vista a la única fuente de verdad absoluta: el código fuente. Esto nos lleva a la situación de que solo la documentación que se genera directamente desde el código fuente de manera automatizada tiene verdadero valor.

El código es la única fuente de verdad absoluta sobre un proyecto de software a nivel de detalle, y el nivel de detalle es el único útil para modificar, extender o mantener un sistema en producción. La documentación directamente asociada al código fuente o embebida en él (comentarios que permitan generar documentación, por ejemplo, con NDoc, JDoc o similares) o aquella que se genera de manera automática desde el mismo (por ejemplo, diagramas de clases que solo son otra vista del código) es la que más valor tiene, pues evoluciona y se mantiene en paralelo al código fuente y siempre está actualizada.

Otra documentación que no está directamente relacionada con el código fuente y que es de gran utilidad, si no imprescindible, es la relativa a arquitectura. Es necesario que un nuevo desarrollador o aquel que resucita el proyecto tras un tiempo puedan comprender qué decisiones de alto nivel guiaron el desarrollo. Esta documentación sirve para comprender por qué se tomaron determinadas decisiones que no se cambian con facilidad a lo largo del proyecto y proporciona una primera aproximación de alto nivel. La arquitectura de una aplicación no suele cambiar a menudo; lo que cambia más frecuentemente es la implementación, el código. Esta documentación es simple de mantener, porque es mucho más estática que la de diseño detallado.

A menudo nos centramos en documentar olvidando que la principal fuente de información sobre qué hace una pieza de software está el nombre de los componentes, de las clases y de las funciones. La principal documentación con la que contamos es el estilo de nomenclatura, la coherencia a la hora de nombrar cosas y una arquitectura general coherente. Establecer un lenguaje común, la nomenclatura y el estilo que va a guiar del desarrollo es más valioso que cualquier documentación. Mucha documentación puede emanar de una serie de patrones que se repiten a lo largo del proyecto, tanto a nivel arquitectónico como de diseño, y estos patrones donde viven es en el código.

Buscando valor para el cliente, cada vez más proyectos deciden mantener una base de conocimiento sobre nuestro proyecto, basada en artículos cortos y con ejemplos, tipo knowledge base, sobre los que se pueda realizar búsquedas fácilmente. Por eso se están popularizando tanto como repositorios de información sobre proyectos los wikis: no imponen una estructura, son ágiles de mantener, fácilmente actualizables, fácilmente buscables y soportan muchos tipos diferentes de contenido.

También se tiende cada vez más a sustituir la documentación por la refactorización: si una pieza de software es compleja, tenemos dos posibles estrategias a la hora de hacerla entendible. La primera es documentarla; la segunda es, a base de refactorización y de mejorar el diseño, simplificarla para hacerla más clara. Se puede ganar mucho en la legibilidad de nuestro software simplemente eligiendo buenos nombres, evitando las funciones enormes, limpiando las variables no utilizadas… La ventaja de este enfoque es que mejora objetivamente el software, haciéndolo más mantenible y más claro, sin necesidad de un artefacto externo que puede fácilmente quedar desactualizado.

Antes de escribir cualquier documentación debemos preguntarnos varias cosas: ¿Es realmente imprescindible? ¿Será fácil de mantener? ¿Aporta algún valor claro para nuestro cliente?

El manifiesto ágil resume lo aquí expuesto de la siguiente manera: “El software que funciona es más importante que la documentación exhaustiva”. El desarrollo de software va sobre código fuente y ejecutables, no sobre documentos.

 

Hoy ha nacido Comando Tomate, un nuevo sitio para la comunidad promovido por la gente de DPE España. Ha sido presentado en una rueda de prensa multitudinaria.

Comando Tomate posibilita que los entusiastas del desarollo del software y de las tecnologías en general cuenten al mundo, mediante videos que pueden enviar al sitio, todo aquello que consideren relevante.

De momento se pueden encontrar entrevistas a Iñaki Ayucar, creador de Simax, un simulador de conducción para el sector de la formación y de la seguridad vial, todo un crack al que conocí el Tech Ed, a Ismael El-Qudsi que trabaja en MSN como responsable de Live.com y a Oscar del Moral, responsable de la plataforma Xbox en España, de sus juegos y del servicio de juego online Xbox Live. Seguro que en breve habrá mucho más contenido.

Comentar que desde Plain Concepts hemos trabajado con Microsoft en este proyecto para adaptar Community Server a las necesidades particulares de esta comunidad. El resultado, a la vista salta, es un Comunity Server al que no reconocería a primera vista ni su padre :). La flexibilidad (y todo hay que decirlo, la complejidad de Community Server) a la hora de construir comunidades online salta a la vista.

Quizás me anime y haga un video del estilo «Así se hizo Comando Tomate»…

Espero que esta nueva comunidad que hoy nace tenga todo el exito del mundo.