Monday, October 29, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (III) Conclusiones



Continuamos con el resumen del Capitulo 6 Parte 2. En este caso finalizamos con las conclusiones.
Si no lo has hecho, puedes leer los anteriores posts sobre el capitulo (parte 1  parte 2).

Conclusiones

  • El código se pudre porque tenemos miedo a cambiarlo
  • Para mantenerlo limpio tenemos que eliminar el miedo a cambiarlo
  • Sólo con una batería de tests en la que confiamos se elimina el miedo a cambiar el código
  • Reglas del TDD
    • No se puede escribir código de producción excepto para pasar un test que está fallando
    • Escribe solo lo suficiente de un test para demostrar el fallo (no compilar es un fallo)
    • Escribe solo lo suficiente del código en producción como para pasar el test fallando
  • Siguiendo estas reglas de TDD se consigue:
    • Menos defectos
    • Tiempos de depuración más bajos
    • Documentación de bajo nivel confiable y detallada
    • Código altamente desacoplado
    • Y una batería de tests en la que puedes confiar
  • TDD te hace ir más rápido
  • Los desarrolladores profesionales debemos esperar que el departamento de QA no encuentre ningún defecto (ese es el objetivo)
Con este post concluimos el resumen de este interesante capitulo de clean coders 

Sunday, October 28, 2012

Review Agile product management with scrum

Agile product management with scrum creating products that customers love

Este es uno de los pocos libros dedicados al rol de Product Owner que he visto... Es un rol, que aun siendo fundamental, es muy difícil hacerlo bien y no cuenta con tanta literatura como el rol de Scrum Master o como las prácticas de desarrollo de software que debe usar cualquier equipo de desarrollo ágil.

El libro se centra en entender el rol de product owner, crear la visión general del producto, trabajar con el backlog, planificar las versiones (releases), y cómo introducir el rol de product owner en empresas que no estén acostumbradas a ese tipo de rol.

La parte que más me ha gustado es la que se centra en crear la visión general del producto y el trabajo con el backlog. En estas partes, da bastantes herramientas y trucos para ayudarnos en el proceso creativo y en la toma de decisiones.

Enlace a goodreading

Thursday, October 25, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (II)



Continuamos con el resumen del Capitulo 6 Parte 2. Tal y como comentamos el capitulo es muy completo y contiene gran cantidad de información por lo que hemos dividido el resumen en tres posts. Este es el segundo.

Si no lo has leido, puedes comenzar por el anterior post sobre este capitulo.

Para trabajar con código legacy en el que no tenemos tests:

  • Encuentra un modulo pequeño que puedas probarlo sin realizar demasiados cambios
  • Realiza los tests para realizar esos cambios con más seguridad
  • Para funcionalidades nuevas, se hacen pequeños cambios para poderlas testear
  • Si en una modificación, existe la posibilidad de modificar y hacer los tests a posteriori o hacer un nuevo módulo, deberemos hacer un nuevo módulo, usando TDD Siempre que sea código nuevo, se hace con TDD

Como testear GUI/View

  • Para la parte de vista pura, no merece la pena, puesto que es una parte que se presta a muchos cambios (estilo, presentación, …) y que además no tiene un resultado prefijado sino que se suele ajustar continuamente
  • Pero se puede probar todo el código relacionado en las capas anteriores...
  • Es decir podemos probar el contenido de los elementos de pantalla, pero no merece la pena testar cómo están posicionados, qué forma tienen, colores, etc...
  • Para ello se separa el GUI en dos componentes Presenter / View
    • Presenter interroga objetos de negocio y prepara estructuras de datos
    • Las estructuras de datos generadas por el Presenter, son renderizadas por el objeto View
    • Se testea el Presenter
  • Algunos hacen tests para las vistas (a nivel de interface), pero en ese caso lo hacen después de realizar las vistas, con el objetivo de que una vez que han conseguido un resultado, detectar si cambia. El, en general no lo recomienda.

Como testear la BD

  • Se testea que tu esquema y tus consultas funcionan como se supone
  • Necesitas tener la aplicación y la capa de BD separada
  • Esto permite probar la aplicación sin la BD real
  • Luego se puede probar la capa de BD separada. Por ejemplo se puede testear:
    • Se puede testear que se genera el SQL correcto
    • Incluso se puede probar que el SQL se comporta bien cargando una pequeña cantidad de datos

Disciplina y profesionalismo

  • El software es una disciplina que tiene que atender a muchísimos detalles, cualquier pequeño cambio y/o error hace que la aplicación deje de funcionar. Es muy propenso al fallo humano y las consecuencias (a nivel de la aplicación) suelen ser importantes.
  • Esto no pasa en otras disciplinas, y quizás en la que si pasa es en contabilidad y por eso establecieron como “buena práctica” el “sistema de partida doble” (Double-entry bookkeeping system) por el que cada entrada se realiza de dos formas independientes con cálculos independientes de forma que si existe una discrepancia se detectase de forma más o menos inmediata.
  • El TDD sería el equivalente en desarrollo de software a esta buena práctica del “sistema de partida doble” puesto que todo se desarrolla con un doble flujo (el de test y el de producción) que se validan el uno al otro.
  • Como desarrolladores profesionales debemos esperar conseguir que el departamento de QA no encuentre errores en nuestras entregas y en caso de que los encuentre debemos esforzarnos en que no pueda volver a pasar ese tipo de error.
  • Debemos liberar código que sabemos que funciona (lo contrario es irresponsable y no profesional).
  • La mejor forma conocida para asegurarnos de que el código que liberamos funciona es seguir la disciplina del TDD en su creación.
  • Debemos buscar tener una cobertura de código del 100%, ese es el objetivo, aunque puede que en algún caso no sea totalmente posible, pero el 100% debe ser lo que se persiga.

En el próximo post terminaremos con las conclusiones de este capitulo...

Monday, October 22, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (I)



Continuamos con las acciones de mejora / compartiendo videos cleancoders. En esta ocasión toca el resumen del Capitulo 6 Parte 2


Este capitulo está lleno de detalles interesantes, por lo que voy a hacer varios posts para resumirlos...
Comencemos....

@unclebob, comienza con una sesión (ligera) de diseño de la solución al problema, el la que:
  • Obtenemos el vocabulario del sistema
  • Identificamos los componentes básicos
En la práctica no se sigue el diseño que hemos hecho, se usa como guía o referencia, pero el diseño final será el que emerja mientras resolvemos el problema usando TDD.

@unclebob Comienza con una estructura de test y un test vacío  de forma que se verifica que todo está en su sitio antes de comenzar la sesión de TDD propiamente dicha.

Al principio, cuando todavía no hemos entrado en el problema, podemos identificar los primeros pasos haciéndonos la siguiente pregunta: ¿Qué test tengo que escribir para forzarme a escribir el código que se que quiero escribir?

Es común escribir un test, simplemente para poder escribir cierto código inicial de producción y que luego, según evoluciona la solución, ya no tenga sentido (o no pruebe nada) y se elimine (canCreateGame, canRoll, …)

Nunca escribimos tests que sabemos que van a pasar.

El código de los tests es tan importante como el de producción y tenemos que tener el mismo cuidado con el. Es decir tiene que ser clean code y se debe refactorizar de forma continua.

En muchas ocasiones, desarrollando con TDD, el resultado no se corresponde con el diseño original. Normalmente es más sencillo, puesto que sólo tiene el código necesario para la funcionalidad actual.

Respuestas a las objeciones típicas a usar TDD:

  • Objeción: Se debe de tardar más con TDD, puesto que se escribe mucho código de test... Se tarda mucho menos, puesto que se avanza más rápido trabajando siempre sobre clean code, además se gasta mucho menos tiempo en depuración. No nos pasamos todo el tiempo peleando con código sucio y dificil de entender.
  • Objeción: Los managers no dejarán practicar TDD a los desarrolladores... Es una práctica interna, que no tiene porqué entrar en discusión con los managers.
  • Objeción: Refactorizar es volver a realizar trabajo, seria mejor hacerlo bien a la primera... Asi es la vida... efectivamente es volver a realizar el trabajo, pero lo normal (y adecuado) para trabajos creativos es hacerlo de forma iterativa con pequeños cambios, puesto que es practicamente imposible hacerlo perfecto a la primera.
  • Objeción: Quién/Qué prueba los test... Con TDD disponemos de dos flujos alternativos para una funcionalidad, los tests y el código de producción, por lo que cada flujo testea el otro, los tests, testean el código de producción y al reves.
  • Objeción: Quizás el mantenimiento de los tests es demasiado caro... No tiene que serlo, puesto que los tests, también deben estar correctamente diseñados y deben de ser clean code, por lo que su coste de mantenimiento debe ser bajo.
  • Objeción: Un test puede probar que un bug ya no se produce, pero no puede probar que no existen bugs. Es decir no puede probar que el software es completamente correcto. El objetivo no es estar 100% sino disponer de una red de seguridad que nos elimine el miedo a cambiar el codigo puesto que tenemos una confianza/certeza sobre que el código funciona correctamente muy alta.
  • Objeción: TDD es un disciplina, seguir reglas en vez de pensar y usar la cabeza... Las disciplinas nos ayudan a no tener que realizar las mismas decisiones una y otra vez... Necesitamos que sea una disciplina para poder ser eficientes (tener mecanizado e interiorizada la práctica) lo que no quita para que de vez en cuando nos planteemos como mejorar la disciplina.
  • Objeción: No importa si se hacen los tests antes o después del código de producción... Si se hacen los tests a posteriori, nos parecerán opcionales y se tenderá a no hacerlos o a que no sean completos, por tanto no confiaríamos en ellos. Además, haciéndolos después perdemos la ventaja de que los tests primero nos obligan a hacer nuestro diseño testable (es decir con bajo acoplamiento).

Seguiremos en el próximo post...

Monday, October 15, 2012

Review NoSQL Distilled

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence

He tardado algo de tiempo en sacar un rato... pero mejor tarde que nunca...

Hace como un mes que termine de leer el libro NoSQL Distilled, de Martin Fowler y Pramod J. Sadalage y la verdad es que me ha parecido muy interesante.

Este libro se centra en dar una rápida visión de los tipos de bases de datos que se suelen llamar NoSQLs.
El libro trata bases de datos clave-valor, de columnas, de documentos y de gráfos. Para cada uno de los tipos, habla de los pros y contras, los casos de uso típicos y el uso más general que se le puede dar.

En general el libro me ha gustado bastante, sobre todo porque explica muy bien los conceptos y da una visión general sobre en qué casos se puede usar cada una de las tecnologías.... Eso si, en caso de que necesitemos un libro de referencia, este no es el libro, pero como no pretende serlo, no hay problema.

El libro se lee muy fácil y esta muy bien escrito... además como es tan cortito en unos pocos días se puede leer.

Recomendable para los que quieran introducirse en el tema  y no tengan demasiado tiempo o no quieran entrar en demasiada profundidad a cada uno de los tipos de bases de datos.

Enlace a Goodreads