TDD y Unit Tests

Benefícios de Test-Driven Development

• El conjunto de test unitarios proporciona contante retroalimentación de que cada uno de los componentes sigue funcionando.
• Los test unitarios actuan como documentación que no se queda obsolet, al contrarío que otros tipos de documentación.
• Cuando el test pasa y el código de producción es refactorizado para eliminar duplicidades, es claro que el código está terminado, y el desarrollador se puede mover a la siguiente tarea.
• TDD fuerza un análisis y diseño crito porque el desarrollador no puede crear código de producción sin entender realmente cuales deberían ser los resultado deseados y como probarlos.
• El software tiende a estar mejor diseñado, esto es, menos acoplado y más facilmente mantenible, porque el desarrollador es libre de hacer decisiones de diseño y refactorizar en cualquier momento con la confianza de que el software todavia funciona.
• El conjunto de tests actua como una red de seguridad contra regresiones en los bugs: Si se encuentra un bug, el desarrollador debe crear un test que ponga de manifiesto el bug y despues modificar el código de producción para eliminar el bug. En sucesivas ejecuciones de los test, todas las correcciones de bugs son verificadas.
• El tiempo de depuración se reduce.

Características de un buen unit test

• Se ejecuta rápido, se ejecuta rápido, se ejecuta rápido. Si los test son lentos, no se ejecutaran a menudo.
• Separa o simula dependencias ambientales como bases de datos, sistemas de archivos, redes, colas y demás. Los test que ejercitan estos no serán rápidos y los fallos no dan información significativa sobre cual es el problema realmente.
• Es muy limitado en su alcance. Si el test falla, es obvio donde bucar el problema. Realiza pocas llamadas a la clase Assert de manera que el código que falla sea obvio. Es importante probar una única cosa en cada test.
• Se ejecuta y pasa de manera independiente. Si los tests requieren establecer entorno especial o fallan inexperadamente, no son buenos tests unitarios. Cambialos por simplicidad y fiabilidad. Los teste deben ejecutarse y pasarse en cualquier máquina. La excusa "funciona en mi máquina" no sirve.
• Usa a menudo stubs y mock objects. Si el código que está siendo probado llama a un base de datos o al sistema de archivos, estas dependencias deben ser simuladas. Esta dependencias habitualmente serán abstraidas usando interfaces.
• Revela claramente su intención. Otro desarrollador puede ver el test y comprender que se espera que haga el código de producción.

Arquitectura SOA: Los Servicios. Introducción

Definición

En una arquitectura SOA la funcionalidad de la aplicación está expuesta a través de una colección de servicios. Estos servicios son independientes y encapsulan tanto la lógica de negocio como los datos asociados.

Desde una perspectiva empresarial, los servicios son activos independientes que se corresponden con actividades comerciales reconocibles o funciones comerciales del mundo real y que son accesibles de acuerdo con las políticas que se hayan establecido para los mismo.

Desde un punto de vista técnico podemos decir que se trata de componentes autónomos de grano grueso, con interfaces bien definidas (contratos de servicio) y con una clara separación entre su interface pública y su implementación privada interna.

Los servicios interactúan entre sí a través de mensajes, con un esquema que define su formato, un contrato para definir sus intercambios y la definición de una política de cómo deben ser intercambiados.

Aplicaciones como conjunto de Servicios.

El primer paso en cualquier proyecto de SOA es identificar claramente los problemas críticos para el negocio o desafíos.

Los servicios incluirán los procesos de negocio y serán publicados para su consumo por parte de usuarios, sistemas u otros servicios.

Los servicios pueden utilizar otros servicios para cumplir sus funciones, serán en este caso servicios compuestos de otros servicios.

La creación de grandes aplicaciones será un proceso iterativo de incluir nuevos servicios y publicarlos.

En la terminología SOA componer nuevos servicios basándonos en los ya existente se llama Orquestación (Orchestration) al igual que en una orquesta iremos combinando instrumentos para realizar tareas más complejas.

La importancia del contrato

Las aplicaciones SOA publican sus servicios y no saben quien los va a usar ni donde, estando

fuera del control de la aplicación. Publican un contrato (interface) que se mantendrá constante a lo largo del ciclo de vida del servicio. El ciclo de vida de un servicio diferencia entre los servicios en producción y en desarrollo, para los servicios en producción nunca se modificará su interface sino que en su lugar el servicio se marcará como en desuso y se notificará a sus consumidores que hay una nueva versión del servicio disponible que deberán usar.

Es fundamental la separación entre la interface y la implementación. El usuario de un servicio sólo necesita (y debe) conocer la interface. La implementación puede cambiar a lo largo del tiempo sin que para ello deba afectar a sus consumidores .

Servicios Web

Como comentamos antes, un error muy común es confundir servicios, componentes que forman una arquitectura SOA, con servicios web. Los servicios web son una forma de implementar estos servicios, pero no es obligatorio que los servicios estén implementados como servicios web aunque sí es lo más común.

En nuestro próximo artículo vamos a profundizar en los servicios web como forma más habitual de implementar los servicios de una arquitectura SOA, haciendo referencia a las dos formas más habituales de servicios web (SOAP y RESTFUL) y las principales diferencias entre ellas.

Breve Introducción a SOA

Si tu conocimiento sobre SOA se limita a la realización de algunos Web Services, pero te apetece conocer un poco más en profundidad la Arquitectura Orientada a Servicios.

En éste primero voy a enumerar 5 ideas fundamentales que debes conocer sobre SOA.

1. SOA no son webservices. Los servicios web son una forma de implementar los servicios de SOA, la más conocida e implantada, pero incluso sin webservices podríamos tener SOA siempre que tengamos una forma estándar de comunicar los servicios entre sí. Digamos que los servicios web son los árboles y SOA va sobre el bosque entero.
2. Los servicios en SOA representan procesos de negocio. Hay una relación directa entre los procesos de negocio de una empresa y los servicios que se van a implementar en SOA, de tal manera que un proceso de negocio estará formado por la llamada a varios servicios.
3. SOA no tiene porque ser válido para todas las organizaciones, donde realmente tiene sentido es en grandes sistemas distribuidos y heterogéneos donde el bajo acoplamiento entre los distintos componentes es el factor más importante. Si nuestra empresa no tiene componentes distribuidos y además todo está bajo la misma plataforma probablemente SOA no nos aporte nada.
4. Implantar SOA no significa cambiar todos nuestros sistemas por un nuevo (y carísimo) software basado en SOA, uno de los principios de SOA es aprovechar los sistemas heredados, realizando servicios que se encargarán de actuar como fachada entre estos sistemas y el resto de servicios.
5. El Gobierno SOA es un factor fundamental en una arquitectura SOA y es el encargado de velar porque se cumplan los principios de la arquitectura.

Por último algunas siglas que deberías conocer:

• ESB: Enterprise Service Bus o bus de servicio empresarial, es el encargado de facilitar la comunicación entre los servicios y puede ofrecer muchas funcionalidades de valor añadido como alta disponibilidad, enrutamiento inteligente, orquestación de procesos, monitorización, etc.
• BPM: Business Process Management o gestión de procesos de negocio, es complementario a SOA, como los servicios representan procesos de negocio es factible que se puedan crear nuevos procesos de negocio en base a la combinación de los servicios ya existentes, con lo que dando de alta nuestros servicios en una herramienta BPM los podemos combinar incluyendo condiciones y utilizando para ello un lenguaje específico como BPEL (Business Process Execution Language)

Fuente

No escribo pruebas unitarias porque... (manual de excusas)

Siendo alguien que vive los beneficios de hacer TDD, creo profundamente en el desarrollo guiado por pruebas. Esta práctica agrega un nuevo nivel de calidad y madurez al desarrollo de software, y sin embargo todavía no es la técnica más usada en los proyectos de software. Cuando hay que elegir entre características, tiempo y calidad, siempre sufre la calidad. No queremos agregar tiempo extra para hacer pruebas, y tampoco queremos comprometer las características que vamos a entregar. Si no se pusieron como objetivo hacer TDD al iniciar el proeycto, es dificil hacerlo después.

Todos escuchamos excusas para no hacer TDD, pero nadie las juntó mejor que "Pragmatic Unit Testing in Java With JUnit", de la serie Pragmatic Bookshelf. Hace un par de años que leí ese libro, y desde entonces creo que no hay forma que un desarrollador responsable pueda leer este libro sin entender que las pruebas unitarias son uno de los aspectos más importantes del desarrollo de software.

La excusa más preocupante que escucho es que es demasiado dificil probar mi código. Esto puede ser por dos motivos. Uno es que el código sea principalmente de interfaces de usuario (UI), y automatizar las pruebas de UI es muy dificil. Entiendo que la automatización de UI son bastantes complejas (¡y no imposibles!), pero se debería dedicar todo el esfuerzo en automatizar lo más posible: piensen en las pruebas de regresión. Si tienen una suite de pruebas completamente automatizada, incluyendo el comportamiento del UI, podrán hacer cambios al código con total confianza de no romper nada.

El segundo motivo de que el código es demasiado dificil de probar es que hicieron desastre con el diseño. Quizás la lógica y el código de UI están muy acoplados. Es por esto que TDD ayuda a mantener un diseño limpio, siguiendo las mejores prácticas. Usar JUnit es simple, y si puedo ejecutar toda la capa lógica por tener un diseño limpio, entonces podré probar toda la lógica que el UI va a usar. ¿Qué les falta el modelo de datos? Entonces pueden usar objetos mocks - ¡hay muchos frameworks para esto!

Para quienes todavía no leyeron el libro, les dejo un breve resumen de las excusas para no hacer TDD:

Escribir pruebas lleva mucho tiempo

Este es el principal motivo que dan los desarrolladores, y creo que se debe a cómo nos enseñan a desarrollar software. En general, nos hacen creer que la estapa de pruebas ocurre al final del proceso, y no durante todo el desarrollo.

TDD fomenta el modelo "pagar a medida que se avanza", en donde escribimos las pruebas mientras desarrollamos, por lo que no tenemos que meter tiempo al final del proceso para escribir todas las pruebas que podamos.

Y de todas formas, si no estás escribiendo pruebas a medida que avanzás, ¿cómo comprobás que el código se comporte como esperás? ¿Lo ejecutás manualmente? ¿No tiene más sentido invertir algo de este tiempo de pruebas manuales en escribir una prueba JUnit para esto? Quiero decir, en algún momento vas a tener que ejecutar esa porción de código - no va a quedar sin tocar el resto de la vida del producto.

De hecho, ocurren muchas más penalizaciones de tiempo si no se escriben pruebas unitarias. Vas a tener que gastar tiempo haciendo debug del código intentando averiguar porque algo no funciona. O vas a hacer un refactor, y luego darte cuenta que nada funciona como antes del refactor. Si tuvieras las pruebas unitarias, tendrías una base segura.

Lleva mucho tiempo ejecutar las pruebas

Si, puede llevarse bastante tiempo ejecutar pruebas que involucran a entidades externas, o pruebas de la interfaz de usuario. Pero se supone que hay más de un nivel de pruebas. Las pruebas unitarias deberían ejecutarse rápido, y podría haber un nivel de integración que también corra sin mucho impacto de tiempo. Si hay pruebas de integración que toman mucho tiempo, será cuestión de correrlas con menos frecuencia - quizás de manera nocturna. Esto no quiere decir que debemos ignorar las pruebas unitarias. Estas siempre deberían correr lo suficientemente ráipdo como para ser parte natural del proceso de software.

Mi trabajo no es probar el código

Todavía no sé en qué momento un desarrollador de software decide que puede tirar código contra la pared así nomás. Si nuestro trabajo fuera de "Codificador" quizás ahí tendríamos una mejor excusa. Pero nuestro trabajo consiste en desarrollar código que funcione, y por lo tanto necesitamos alguna forma de mostrar que nuestro código es funcional. Si a la gente de QA les cuesta encontrar bugs en nuestro código, va a ser maravilloso para nuestra reputación.

En realidad no sé cómo funciona el código, por lo que no puedo probarlo

Esta es dificil de tomar sin ser incrédulos. Si no entendemos cómo debería funcionar el código, no deberíamos empezar a programar. Primero debemos entender el requerimiento.

El libro tiene un par de excusas más, pero estos son las principales. ¿Qué excusas escucharon ustedes para no escribir pruebas?

Fuente: DosIdeas

Consejos y sugerencias para tu primer iteración

Empezar a trabajar por iteraciones puede ser un cambio muy grande (¡y que asusta!) cuando llevamos mucho tiempo desarrollando con otros métodos. Scrum dice cómo llevar adelante el proceso, pero a muy alto nivel. En este artículo, Jared Richardson comparte varios consejos para un equipo que recién comienza a formarse en Scrum, y está a punto de empezar su primera iteración.

No sobre-analicen todo. No importa si no saben exactamente cuánto les va a llevar hacer algo, o cómo van a escribir pruebas unitarias perfectas, o cómo van a manejar los datos para las pruebas X, Y, Z. Simplemente, empiecen a hacer. Tomen una serie de tareas pequeñas y empiecen. Lo mejor de tener iteraciones cortas es que tienen la próxima semana van a poder cambiar sus expectativas!

No se vuelvan locos pensando quién será el Scrum Master. De hecho, hagan que este rol rote en todo el equipo. Al principio, cada miembro del equipo tiene que ser Scrum Master por una iteración antes de volver a ser Scrum Master por segunda vez.

Aprendan la votación con cinco dedos. El equipo entero vota cualquier sugerencia que alguien hace. Un dedo significa que odio esa sugerencia y no puedo aceptarla. Cinco dedos significa que me encanta totalmente. Los dedos en medio reflejan distintos niveles de aceptación. Tres dedos muestran que nos resulta indiferente. Buscamos soluciones que junten respuesta de "Me encanta" o "Puedo aceptarlo". Ninguna de las sugerencias son permanentes; en cambio, usaremos experimentos de entre una y tres iteraciones. Siéntanse libres de probar cosas nuevas, y dejar que otros prueben cosas nuevas. No va a durar por siempre, y los buenos equipos eliminan las prácticas que no funcionan.

Tengan reuniones diarias cortas. El Scrum Master las lidera. Usen algún token sencilla (una lapicera, una pelotita) que se pasa entre los miembros. Si lo tienen, pueden hablar. Sino el resto del equipo puede callarnos por no hablar en nuestro turno (¡y hasta puede resultar divertido!). Debemos asegurarnos que cada persona responda las 3 preguntas: ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Qué problemas tenés?

Usar integración continua para la compilación (¡como mínimo!). Si no tienen builds automáticos, o un servidor de integración continua, usen una "iteración cero" para configurar esta infraestructura. No dejen de hacerlo, los beneficios para el equipo son enormes y es una de los pasos más importantes.

Sólo trabajen en requerimientos estimados rápidamente entre uno y tres días. ¿Tienen una tarea de 6 semanas? Hay que dividirla en piezas más manejables.

Armen un equipo con desarrolladores y testers. Trabajen de a pares cuando escriban pruebas (¡ambos!). Los desarrolladores van a aprender a escribir mejores pruebas, y también los testers.

Tengan una reunión de planificación. El Dueño del Producto, el líder del producto (o quien cumpla con este rol) trae suficiente trabajo para una o dos iteraciones. Rechacen una tarjeta cuando no se pueden poner de acuerdo sobre qué significa la característica, o cómo se prueba que dicha característica. Hagan que el Dueño del Producto tenga la idea más en claro y traiga la tarjeta en una iteración futura.

Todo el trabajo se realiza tiene que realizarse con dos pares de ojos. Pueden lograrlo trabajando de a pares, o con revisiones de compañeros, pero nadie trabaja solo. Esto es tanto para la calidad de código como para compartir el conocimiento (por cierto, si piensan que sus compañeros no son lo suficientemente inteligentes para "entender" nuestro trabajo, el problema es nuestro. Siempre es nuestro. No sean ese tipo de desarrollador).

Agenden una demostración para mostrarle a los demás lo que hicieron durante la iteración. Es una oportunidad para mostrarnos, y dejar que otras partes de la empresa sepan lo que viene.

Por último, relájense. Los miembros del equipo que se viven preocupando con "¿Y qué pasaría si...? ¿Y qué pasa con...? ¿¿Y eso otro?? ¡¡¡Y que vamos a hacer si ocurre aquello!!!"... estos miembros son los que terminan haciendo menos. Simplemente empiecen a trabajar con equipo, y ajusten las iteraciones. Estoy seguro que no sólo lo van a encontrar muy productivo, sino sumamente divertido.

Fuente

Cumplir con la retrospectiva

Si alguna vez trataron de cambiar algún hábito personal (como comerse las uñas, por ejemplo) saben que es virtualmente imposible de lograrlo a menos que tengan algo para reemplazar el hábito viejo. Es más fácil adoptar un comportamiento nuevo que extinguir uno viejo. Lo mismo ocurre para los equipos en las organizaciones.

En su retrospectiva, el equipo de Lynn decidió dejar de empezar a codificar sin tener un plan. Pero en la siguiente reunión de planificación de la iteración, dos miembros del equipo abrieron sus notebooks para compartir código en el que habían trabajado durante el fin de semana. Creían que le estaban dando una ventaja al equipo.

Lynn les recordó a todos el acuerdo y compartió varias ideas para planificar que había leído en grupos de discusión Ágiles. El equipo acordó actuar de acuerdo a lo decidido y probar las ideas de Lynn para la planificación. A medida que el equipo empezó a hablar sobre el trabajo que debía hacerse, el equipo se dió cuenta que el código escrito durante el fin de semana no contribuía al objetivo de la iteración - fue un esfuerzo en vano.

Sin un reemplazo (como estas ideas para planificar), el equipo no tuvo más alternativa que caer en su comportamiento anterior.

Todos los comportamientos nuevos resultan extraños al principio. Las personas desarrollan tranquilidad con la práctica - sea tanto al aprender un nuevo saque de tenis como aprender a escribir código en un nuevo lenguaje. Debemos brindar apoyo y recordar que está bien cometer errores mientras se aprenden nuevas habilidades.

Brindar apoyo

El trabajo de provocar un cambio no termina con el cierre de la retrospectiva. Incluso los cambios más pequeños necesitan ser cuidados y apoyados. El apoyo proviene de diferentes formas: refuerzos, empatía, oportunidades de aprendizaje, oportunidades de práctica, y recordatorios. Algunos tipos de apoyo provienen del equipo (como la empatía y los recordatorios). Otros requieren de recursos y presupuesto externos. Los líderes de equipos, coaches y gerentes tienen la responsabilidad de obtener el apoyo que requiera de gastos.

Refuerzos

El cambio es difícil. Debemos apoyar al equipo (y a nosotros mismos) haciendo notar el avance. Demos frases de aliento sobre lo que estamos haciendo bien.

Debemos brindar información sobre lo que va bien para que el equipo pueda ver que están avanzando. Demos feedback que describa el comportamiento y destaque el impacto: "Noté que ayer no nos fuimos de tema en la reunión diaria. Acordamos sólo responder las preguntas del scrum diario, y eso hicimos. Nos ayudó a ver cuáles eran los obstáculos".

Empatía

Es válido que las personas sientan frustración o pérdida por el cambio. Veamos como Fred manejó mal la situación cuando un miembro del equipo le habló sobre los cambios. Fred escuchó a Katie explicar cómo se sentía sobre tener que dejar su cubículo personal cuando el equipo se ubicó en un espacio abierto. "Estuve pensando lo que me contaste", le dijo Fred, "y no hay ningún motivo para que te sientas así". ¡Eso no es empatía! Debemos respetar los puntos de vista de las otras personas, aunque no los compartamos. A veces un simple "Te escucho" es suficiente.

Oportunidades de aprendizaje

Debemos apoyar la exploración y el aprendizaje, y demostrarlo. Es posible que el equipo necesite aprender nuevas habilidades para tener éxito en los experimentos que eligieron para su plan de acción. Se pueden organizar almuerzos y sesiones para que los miembros aprendan entre ellos. Se pueden dar listas de recursos web y artículos para que el equipo investigue ideas nuevas. La programación de a pares ayuda a aprender nuevos lenguajes y técnicas. Y se puede hacer todo esto sin un presupuesto.

También debemos estar dispuestos en gastar dinero para apoyar un cambio. No todas las habilidades se pueden aprender desde un sitio web o leyendo un artículo. Invirtamos en capacitación para construir las bases de nuevas habilidades. Armemos una biblioteca de referencia para que el equipo pueda consultarla.

Oportunidades de práctica

Las personas necesitan practicar para ganar experiencia. Una forma es dejar al equipo con el proyecto para que prueben algo nuevo. Otra opción es crear un espacio formal de práctica usando algún proyecto pequeño, un área de práctica, o un programa tipo Hola Mundo.

Los proyectos cortos -uno que dure dos días, o incluso menos- sirven para explorar posibles soluciones y probar métodos nuevos. El límite de tiempo en los proyectos cortos crea un punto de verificación explícito en donde el equipo puede comprobar su aprendizaje y las decisiones en el experimento.

Las áreas de práctica son un lugar donde el equipo puede cosas nuevas sin afectar al producto real. Un área de práctica puede ser un área especial de desarrollo o prueba que no se utiliza para el desarrollo actual del producto.

Alentemos a que el equipo prueba programas del tipo Hola Mundo. Los programas Hola Mundo son muy simples (en general sólo muestran el mensaje "Hola, Mundo"), pero sirven para probar entornos de desarrollo, configuraciones y encontrar problemas rápido (o confirmar que algún concepto básico funciona).

Recordatorios

Los tableros grandes y visibles y los check-in son recordatorios que ayudan a que el equipo se enfoque en los cambios. Por ejemplo, el equipo de Terry decidió que necesitaban realizar refactors más seguido. Crearon un tablero grande donde cada miembro agregaba un punto verde cuando terminaban una tarea de refactor. Al final de cada día, revisaban el gráfico y discutían los resultados.

Un check-in le permite al equipo informar lo que están haciendo con un cambio en particular. Debemos mantener preguntas y respuestas cortas: "En una o dos palabras, ¿cómo estamos con las estimaciones?". Las respuestas nos pueden ayudar a saber cómo está avanzando el cambio.

Fuente

¿Inteligente o Tonto?

¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.

En el desarrollo de software, ¿qué tan lejos podés mirar? ¿Estás usando prácticas destructivas porque estás muy ocupado "terminando el trabajo"? ¿Estás ignorando buenas prácticas que podrían ahorrarte tiempo?

Podemos relacionarlo con armar un camino que atraviese un bosque. Estás trabajando muy, muy duro. Todos en el equipo están transpirando, astillándose las manos, todo el tiempo. No se puede cuestionar la lealtad ni dedicación de nadie.

Pero...

¿Cuándo fue la última vez que detuviste esta tala de árboles metafórica, te subiste a un árbol... o miraste el mapa... o afilaste el hacha? El problema con la mayoría de los equipos de software que talan árboles en el bosque es que no comprueban si el camino que están armando está dirigido hacia la ciudad correspondiente. No comprueban si es un camino recto. No analizan si podrían comprar algunas sierras eléctricas para reemplazar a las hachas obsoletas que vienen usando.

Por supuesto que esto también puede abusarse. No queremos pasar todo el día en el negocio buscando herramientas nuevas, pero de vez en cuando necesitamos mirar los alrededores, ver si seguimos en línea recta. Debemos asegurarnos de estar usando las herramientas correctas para el trabajo. Comprobar si siguen afiladas las hojas.

Les dejo algunas sugerencias como herramientas para asegurarnos que seguimos en el camino correcto.

• Integración Continua. Hay muchas herramientas de Integración Continua que ayudan muchísimo al equipo. Hace que el equipo siga escribiendo código en vez de arreglar compilaciones, mantiene limpio al producto, y encuentra problemas rápido.
• Demos frecuentes. Tanto si son internas o para el cliente, estas demostraciones públicas ayudan a entender lo que estamos haciendo, y nos sugiere correciones al curso. Si estamos cortando el camino en la dirección incorrecta, ¿cuánto tiempo queremos seguir perdiendo? Debemos mostrar lo que hacemos, y averiguar lo que piensan lo antes posible.
• Iteraciones de duración fija. Las iteraciones acotadas brindan una forma más efectiva de enfocar los esfuerzos y asegurarse de estar construyendo el software adecuado.
• Pruebas automatizadas. Cuando codificamos nuestro conocimiento del producto en una prueba automatizada (que se ejecuta en un servidor de integración continua), se hace imposible que alguien del equipo rompa el código sin que se descubra rápidamente.
• Pruebas guiadas por los defectos. ¿Encontraste un bug? Agregá una prueba. Siempre. Esta perspectiva extreme a la automatización de pruebas nos brinda cobertura justo en donde era necesaria. También, no agregues una sola prueba... buscá armar escenarios derivados de la situación.
• Desarrollo guiado por pruebas. Escribir una prueba antes de escribir el código productivo hace que surja un código completamente diferente. Es más pequeño, más enfocado y (¡sorpresa!) está probado. TDD es un camino de ida... ¡probalo!
• Reuniones diarias de parado. Estas reuniones diarias y breves hacen que todos hablen y se vean la cara, todos los días. Se responden 3 preguntas que ayudan a compartir información. ¿Cuántos equipos conocen que no se hablan a diario?

Fuente

Integración Continua para mantener el proyecto en rumbo

Hoy en día tenemos muchas herramientas que dicen limpiar de forma mágica nuestro código. Mueven, modifican, emprolijan y mágicamente resuelven todos nuestros problemas. Lamentablemente, como la mayoría ya sabe, escribir buen código lleva trabajo. No existen herramientas mágicas que puedan salvarnos (y no importa lo que nos digan los vendedores), pero si hay una herramienta que funciona muy bien para ayudarnos a mantenernos en forma.

La Integración Continua es una idea bien simple. Configuramos un programa que mire el código fuente. Cuando alguien hace algún cambio, el sistema de Integración Continua lo compila de inmediato. Si la compilación pasa, se ejecutan las pruebas automatizadas. Por último, se publican los resultados.

Simple, ¿no? ¿Por qué es tan poderoso?

La Integración Continua es como una tarjeta de crédito al revés. Una tarjeta de crédito nos permite comprar algo grande hoy, y pagarlo de a poquito más adelante. Sin embargo, las tarjetas de crédito tienen un pequeño secretito oscuro... el interés compuesto. Terminamos pagando mucho, mucho más de lo que tomamos prestado. Siempre resulta más barato pagar en efectivo si podemos.

Cuando usamos un sistema de Integración Continua, ocurre lo opuesto. Podemos hacer pequeños pagos todos los días, o podemos esperar hasta el final y hacer un único gran pago. ¡Desafortunadamente este último gran pago tiene todo el interés compuesto agregado! Si esperamos al final, terminamos pagando más... mucho más!

Esto ocurre por el "tiempo a oscuras" entre que un desarrollador escribe el código y lo combina con el código que escribió el resto del equipo. Si combinamos el código todos los días, o incluso un par de veces a la semana, los cambios son menores y relativamente indoloros. Pero si esperamos...

Si esperamos, los cambios crecen. Mientras más esperamos, más código escribimos. Y más código escribe el resto del equipo. Al terminar el mes, cuando nos vemos forzados a combinar y unir todos esos cambios, las colisiones son gigantes. Los desarrolladores trabajan en los mismos archivos, a veces en las mismas líneas... otras veces hay funcionalidad en la que un desarrallador dependía y ahora hay otro desarrollador que la cambió (quiero decir, "mejoró"). Y los cambios mutuamente excluyentes generan caos.

Durante este tiempo entre escribir el código y hacer la combinación, compilación y testeo con el código de los demás, es cuando no podemos ver lo que está pasando. ¿Nuestros cambios entran en conflicto con los de alguien más? ¿Alguien cambió algo que necesitamos? No podemos verlo todavía... estamos a oscuras. Y vamos a seguir a oscuras hasta que unamos el código.

Una herramienta de Integración Continua ayuda los desarrolladores a aprender el ritmo de "escribir una cosa, subirla al repositorio". Esto funciona mucho mejor que "escribir una cosa... y otra... y otra... y otra...", y después "dedicar horas y días a combinar el código". ¡Y ni siquiera empezamos a ahblar de los beneficios de ejecutar las pruebas automatizadas después de subir cada cambio!

Tenemos que encontrar los problemas lo más rápido posible, cuando todavía los arreglos son menores. ¡Es el mejor momento para arreglar los problemas!

Algunos productos de Integración Continua para empezar

• Cruise Control
• Anthill
• Hudson
• CC.net

Fuente: DosIdeas

Crear amor, no dinero

Algunas personas de negocios siguen una estrategia que no se enseña en las escuelas de negocios: la mejor forma de maximizar las ganancias es dejar de pensar en maximizar las ganancias y, en cambio, enfocarse en tratar bien a las personas. Es decir, la mejor forma de hacer dinero es enfocarse en amar a las personas.

Joel Spolsky ya lo dijo: "Las mejores condiciones de trabajo -> Los mejores programadores -> El mejor software -> ¡Ganancia!".

Tony Hsieh lo dice de esta forma: "La Cultura es nuestra prioridad número uno... Creemos que si generamos la cultura correcta, entonces muchas otras cosas como construir una marca van a ocurrir de forma natural por si mismas".

Quisiera distinguir esta visión de dos perspectivas similares: la primera es el estilo del colectivismo hippie de los '60, en el cual el capitalismo es malvado porque es inherentemente manipulativo, que el trabajo y el capital deberían beneficiar a todos los miembros de la organización, y que, en realidad, el dinero es una molestia y lo que importa es el amor. En contraste, la perspectiva de Crear amor, no dinero no dice que el dinero sea una molestia o cómo debería organizarse el capital. Tampoco quiere decir que sea inconsistente con el punto de vista hippie.

La segunda perspectiva proviene del mantra tradicional de Scrum: "El objetivo del equipo es maximizar el valor de negocio entregando software que funciona". Bajo la mirada de Crear amor, no dinero se podría re-escribir: "El objetivo de un equipo es optimizar su entorno de trabajo y, como efecto secundario beneficioso, va a incremental radicalmente el valor de negocio que se entrega". Es un hallazgo empírico que optimizar el entorno de trabajo suele llevar a incrementos significativos en los resultados financieros. Resulta consistente con el sentido común pero no necesarimante deriva de la premisa "optimizar el entorno de trabajo".

Una buena pregunta: ¿Por qué no hacen esto quienes maximizar las ganancias? El gerente típico medio, cuando se le pide que aumente las ganancias, responde despidiendo trabajadores o ahorrando en material de la oficina - no creando un gran entorno de trabajo. No sé porqué. Sospecho que tiene que ver con las limitaciones cognitivas de las personas. Nos resulta muy dificil comprender el enésimo efecto de nuestras acciones. Es mucho más simple comprar sillas baratas para lograrlo - cualquier otra cosa es más complicada.

Si se adoptara, quienes maximizan los beneficios podrían ver a la perspectiva de Crear amor, no dinero como una herramienta cognitiva que ayuda a tomar mejores decisiones, al igual que un coach de ajedrez enseña a desarrollar las piezas (en vez de pedirle que haga mate al rey).

En resumen: enfocarse en crear grandes ambientes de trabajo, y obtendremos gratis las ganancias extraordinarias.

Fuente: DosIdeas

Lista de comprobación para hacer TDD

El Desarrollo Guiado por Pruebas (o TDD) se suele describir como un ciclo de rojo-verde-refactor, que se repite continuamente, para ir agregando nuevas características o arreglar bugs. La siguiente lista de comprobación que comparte Giorgio Sironi contiene un grupo de preguntas que deberíamos hacernos a nosotros mismos mientras avanzamos por las fases de TDD, para no olvidarnos de la esencia de esta técnica.

Rojo

El desarrollo de cualquier característica nueva tiene que empezar con una prueba que falla.

• ¿Subiste el código al repositorio remoto o local? Si el código se rompe, es más fácil revertir los cambios que re-escribir.
• ¿Ya escribiste código productivo? Si lo hiciste, comentalo o, mejor todavía, eliminalo para no estar atado implícitamente a un API mientras escribís la prueba.
• ¿Elegiste la unidad apropiada para expandir? La clase modificada debería ser una que siga teniendo cohesión luego del cambio, y a menudo se deberían agregar claes nuevas en vez de acomodar la funcionalidad en las existentes.
• ¿Falla la prueba? Si no, re-escribila para exponer la falta de funcionalidad.
• ¿Una parte de la prueba ya falla? Si es así, eliminá el restante de la prueba; el resto lo podés agregar en métodos diferentes.
• ¿El nombre del método de prueba describe su propósito? Asegurate de no atarte a detalles de implementación.
• ¿Los mensajes de fallas son descriptivos sobre el problema? Asegurate que describan en dónde está fallando la funcionalidad, destacando la ubicación si se rompiera en el futuro.
• ¿Los números y strings mágicos están expresados dentro de constantes? ¿Hay código repetido? El refactor del código de pruebas es más fácil cuando se hace tempranamente y mientras aún falla, ya que en este paradigma es más importante hacer que siga fallando que hacer que pase.

Verde

Se debe escribir el código productivo necesario para que la prueba pase.

• ¿El código productivo hace pasar a la prueba? (así de simple)
• ¿Hay un subconjunto del código productivo que hace pasar a la prueba? Si es así, comentá, o mejor todavía, eliminá el código productivo innecesario. Cualquier otra línea de código que escribas no tendrá cobertura, y serán líneas sin pruebas que deberemos leer y mantener en el futuro.
• Cualquier otra acción específica será llevada a cabo en la fase de Refactor.

Refactor

Mejorar la estructura del código para facilitar los cambios futuros y el mantenimiento.

• ¿Existe código repetido en la clase actual?
• ¿El nombre de la clase es el apropiado?
• ¿Los métodos públicos y protegidos tienen un nombre descriptivo? ¿Son legibles? El refactor de renombrado es uno de los más poderosos.
• ¿Hay código repetido en diferentes clases? ¿Existe un concepto de dominio que está faltando? Podemos extraer hacia clases abstractas o hacer un refactor de composición. Este alto nivel de refactor también debería aplicarse a las clases de pruebas unitarias.

Fuente: DosIdeas