Etiqueta: book-review

Libro Recomendado: Tidy First?

Ayer terminé mi primer lectura de vacaciones, el libro más reciente de Kent Beck: «Tidy First?: A Personal Exercise in Empirical Software Design».

Primero los datos: el libro es bastante corto, apenas 99 páginas distribuidas en 33 capítulos lo cual sigue el estilo típico de los libros de Beck: capítulos cortos. En este caso está llevado al extremo porque hay capítulos de menos de 2 páginas. El libro es el primero de una serie, que según el propio Beck, tendrá 3 libros. El libro arranca con cuestiones muy concretas y gradualmente se va poniendo más teórico/filosófico.

Pero… ¿qué es un «tidy»? Como la traducción puede sugerir, un tidy es un emprolijamiento. Una mejora en la estructura del código de cara a facilitar su entendimiento/evolución. En un punto es cómo un refactor, pero más chico.

Ahora mi opinión: el libro me gustó mucho, mezcla cuestiones muy concretas/prácticas (los «tidyings») con cuestiones más teóricas/filosóficas (cuando tidy y cuando no, cuánto tidy, etc). Todo esto analizado una visión económica. Creo que son muy pocos los libros que tratan este tipo de cuestiones. A su vez, la organización en capítulos cortos hace que la lectura me resulte muy cómoda. Si bien es libro que cualquier programador debería poder entender sin dificultad, creo que los programadores más experimentados van a sacarle mayor provecho.

Libro: Hexagonal Architecture Explained

Hace un par de días terminé de leer este libro, escrito por el mismo Alistair Cockburn, descubridor de este patrón. Curiosamente la publicación inicial fue hace unos 20 años en algunos artículos informales. A lo largo de todos esto años fueron apareciendo diversas publicaciones sobre la arquitectura hexagonal, algunas de ellas del propio Alistar, pero recién hace un par meses fue publicado este libro.

El libro está muy bien. Explica claramente la técnica/patrón, no solo desde un punto de vista práctico y con ejemplos de código sino también desde un punto de vista conceptual.

Lo leí en el kindle con lo cual no tengo en claro la extensión del libro pero creo que aproximadamente la mitad del libro son reproducciones de artículos previamente publicados con algunas correcciones/comentarios. No pretendo hacer un juicio sobre esto, solo describo el hecho.

Una cuestión que me gustó mucho del libro es que deja bien claro el alcance del patrón lo cual me parece muy necesario ya que he visto muchas publicaciones de otros autores incluyendo cuestiones que claramente no son parte del patrón. Un ejemplo muy habitual de esto es decir que el interior del hexágono (o sea la lógica de negocio) se estructura de acuerdo a un estilo Domain-Driven Design, algo que yo suelo hacer pero que está más allá de la arquitectura hexagonal, o sea, la arquitectura hexagonal no se mete en qué hacemos dentro del hexágono.

En lo personal creo que si alguien pretende simplemente aplicar la arquitectura hexagonal en un proyecto, no necesita leer todo el libro, posiblemente con leer la primera parte o algunos de los artículos (recientes) del propio Alistair puede ser suficiente. Sin embargo, para aquellos curiosos que quieran ir más allá y hacer el ejercicio de profundizar en el patrón, sus implicancias y sus conexiones, este libro es un pieza fundamental.

Libro: Formulation (The BDD Books)

Terminé de leer este libro hace un par de días. Me gustó y me alegró ver que varias de las cuestiones que menciona coinciden con lo que vengo aplicando en mis proyectos y enseñando en MeMo2.

Al margen de que ya sabía, descubrí algunos conceptos y capacidades de Gherkin de las que nos estaba al tanto como ser los «journey escenarios» y la diferencia entre las «data tables» y «example tables».

El texto está escrito de forma tal que intercala explicaciones conceptuales con fragmentos de diálogos de un equipo de desarrollo que aplica esos conceptos. En cierto modo esto hace que la explicación de cómo formular buenos ejemplos contenga muchos ejemplos.

Creo que es fundamental para todo equipo pretenda aplicar BDD que al menos una persona del equipo de desarrollo maneje fluidamente las cuestiones descriptas en este libro (¿el facilitador/Scrum Master? ¿un tester?).

Libro: Código Sostenible

Hace un par de días terminé de leer este libro escrito por Carlos Blé. Me pareció muy bueno y me gustó mucho.

El libro es un muy buen compendio de buenas prácticas de programación y diseño. Reúne temas ya tratados en otras publicaciones y agrega temas que personalmente nunca había visto en un libro. En cada tema, más allá de la explicación y algún ejemplo, se suma la opinión de Carlos, siempre pragmática, constructiva y basada en la experiencia.

El libro está escrito en castellano, lo cual también suma puntos, ya que no tengo presente otros libros de esta temática escritos en castellano. Un punto a mi parecer negativo es que los ejemplos de código están en inglés, lo cual me resultó molesto por tener que cambiar de idioma entre el código y la prosa, pero es un tema menor.

Varios de los temas que cubre el libro son temas de MeMo2, o mejor dicho, son temas que nos gustaría que los alumnos de MeMo2 ya tengan asimilados. Lamentablemente no siempre los tienen asimilados y por ello nos vendría muy bien contar con este libro como recurso de estudio. La editorial del libro (Savvily) tiene un acuerdo para que los estudiantes puedan acceder gratuitamente a sus libros, pero dada la burocracia de UBA, veo muy difícil que se logre firmar el acuerdo. De todas formas, no pierdo la esperanza.

Al igual que Code Complete y The Pragmatic Programmer, este libro tiene contenido que todo programador debería conocer.

Agradezco a Carlos por haber escrito este libro pues lo considero un gran aporte a la comunidad IT de habla castellana.

Libro: Modern Software Engineering

Hace un par de semanas terminé de leer este libro escribo por David Farley. Me gustó. Mucho. Ofrece fundamentos acompañados con ejemplos concretos, teoría y práctica muy bien combinada. Industria y academia complementadas en la medida justa.

Por momentos el libro se torna bastante filosófico y a continuación baja el nivel de abstracción a cuestiones muy concretas. Son muy pocos los libros que visto haciendo oscilación. Al compararlo con otro libros que llevan el término «software engineering» como los clásicos de Pressman (o Sommerville), siento que algunos de los dos tiene un título incorrecto.

Tal vez el hecho de que el libro me haya gustado tanto esté levemente influenciado porque describe las cuestiones que intento transmitir en mis materias, ¡ja!

Sin embargo, no es un libro que utilizaría para una materia introductoria de Ingeniería de Software, creo que para poder sacarle buen provecho y poder seguir algunos los argumentos es necesario ya tener asimiladas ciertas cuestiones fundamentales de la disciplina.

Libro: Discovery (The BDD Books)

Ayer terminé de leer este libro cuyo nombre completo es «Discovery: Explore behaviour using examples«. Es el primer libro de la serie «The BDD Books» de Seb Rose y Gaspar Nagy. El foco del libro está en la utilización de ejemplos como «técnica de especificación funcional». En este sentido el libro provee una guía respecto de cómo, quien y cuando utilizar la técnica, dando respuesta no solo a las particularidades de la técnica sino también a cómo usar la técnica en el contexto de un proceso de desarrollo de una equipo/organización.

Debo decir que el libro me gustó mucho, es cortito y muy concreto. Provee ejemplos muy claros y fáciles de entender. Al mismo tiempo atiende dudas/situaciones que habitualmente surgen al intentar aplicar BDD en distintos contextos de proyecto.

Si bien mi referencia preferida en este tema son los libros de Gojko (Specification by Example y Bridging the Communication Gap), creo que este libro es más directo y por ello que puede resultar un muy buen punto de entrada para quienes no están familiarizados con la técnica. Claro que los libros de Gojko son mucho más amplios y profundos pero justamente por eso me parece que es mejor arrancar por aquí y eventualmente continuar con los otros.

El libro está disponible en LeanPub.

Libro: Refactoring, Improving the Design of Existing Code

Recientemente terminé de leer este libro. Había leído algunos fragmentos sueltos, algunos refactorings del catálogo, pero resulta que el libro es mucho más que el catálogo. Toda la primera parte del libro explica diversos conceptos de refactoring y diseño orientado a objetos en general.

Entre lo que más me gustó del libro (más allá de algunos refactorings) están el capítulo 2 (Principles) y el capítulo 3 (Bad Smells in Code).

El autor del libro es Martin Fowler pero hay capítulos en los que colaboraron otros autores. Destacan las colaboraciones de Kent Beck, en esos capítulos se evidencia el mismo tono de «charla de café» que en los libros Beck (TDD by Example, Extreme Programming Explained, etc)

Dada la época en que se escribió el libro (2001), los ejemplos y las menciones a lenguajes de programación están en torno a Smalltalk, C++ y Java (versión 1.2).

Importante aclaración: hay 3 ediciones de este libro una de 2001 y otras 2 de 2018 (una es la actualización de la versión 2001 y la otra es una versión ajustada a Ruby). Yo leí la versión 2001 porque me interesaba entender el tema desde la raíz, sin embargo si alguien está interesado en leer este libro le recomiendo leer la versión 2018.

Test-Driven Development for Embedded C

Ayer terminé de leer este libro. En una palabra: Excelente.

Lo había tenido en radar por mucho tiempo pero recién ahora con el envión de mi trabajo de investigación sobre TDD decidí invertir tiempo en leerlo. El autor del libro es James Grenning, uno de los 17 autores del Agile Manifesto pero lo que puso el libro en mi radar fue la charla de Grenning «TDD Guided by ZOMBIES» en la cual propone una heurística para definir el orden de la secuencia de tests al hacer TDD.

El hecho de que el título del libro haga referencia a Embedded C es en gran medida anecdótico ya que casi todo el contenido es directamente aplicable a cualquier lenguaje o eventualmente fácilmente extrapolable. Es cierto que algunos capítulos están muy centrados en C y en el desarrollo de software embebido, pero varias de las problemáticas relacionadas a la dependencia del hardware son fácilmente extrapolables a las dependencias de infraestructura que uno se encuentra en el desarrollo de aplicaciones de más alto nivel.

Al margen de TDD, creo que el libro resulta muy valioso para gente trabajando en software embebido ya que provee un conjunto de técnicas que sin duda facilitan/aceleran el desarrollo del software embebido. De hecho lo interesante de las técnicas que propone son aplicables a todo desarrollo a bajo nivel, sea o no embebido. Personalmente he trabajado muy poco con software embebido pero sí he hecho desarrollo en C/C++ y de haber sabido las técnicas mencionadas en este libro creo que habría obtenido mejores resultados.

El libro me ha parecido muy completo, explica los fundamentos de TDD, trata con suficiente detalle las cuestiones de tooling para poder automatizar pruebas en C, escribir código modular y hasta implementar mocking en C. También trata cuestiones de patrones, code smells y trabajo con código legacy.

Para mi es 10 puntos, muy recomendado.

Diseño ágil con TDD

Ayer terminé de leer la edición 2020 de este libro escrito por Carlos Blé. Ya había leído (parcialmente) la edición anterior allá por 2011, pero el año pasado Carlos tuvo la gentileza de regalarme esta nueva versión (¡gracias!) y me comentó que tenía modificaciones importantes así que aproveché que estaba estudiando TDD para mi tesis de maestría y decidí leer el libro de punta a punta.

En una oración: el libro me gustó mucho. Sentí mucha afinidad en la forma de trabajo que relata y también en los consejos que el autor ofrece a título personal.

Encontré un punto de contraste interesante con otros libros de TDD. Creo que la mayoría de los libros que he leído sobre TDD (al igual que la mayoría de charlas, cursos y videos sobre TDD que he visto/presenciado) tienen un tono muy extremo, muy «todo o nada», muy «esto es así» (creo que yo mismo muchas veces peco con ese tono) pero este libro (y creo que Carlos en general) tiene un tono «de mesura», un matiz que me resultó muy ameno y que imagino puede resultar mucho más efectivo a la hora de intentar convencer a alguién de utilizar TDD.

Otra cuestión destacable del libro es no se queda en la explicación de la técnica sino que también trata sobre el uso de la técnica en distintos contextos «reales» de aplicación: en qué tipos de proyectos utilizarla TDD, cómo utilizar TDD en proyectos de código legado, como empezar a utilizar TDD, etc. Trata también la clásica rivalidad de los estilos Chicago vs London de sin necesariamente tomar partido (menciona su preferencia pero no la considera una bala de plata para todo contexto).

Otro punto no menor a destacar es que es uno de los pocos libros (¿acaso el único?) de TDD en castellano.

Creo que es un recurso interesante para aprender TDD, tal vez no entra en tanto detalle como otros libros de TDD pero al mismo cubre muchas más cuestiones, o sea: va más en anchura que en profundidad lo cual me parece bueno para un libro introductorio.

El libro está disponible en formato digital en LeanPub. Muy recomendado.

Highlights sobre el libro «Test-Driven Development By Example»

Esta semana terminé de releer este libro fundacional de TDD. Como ya mencioné no estoy convencido de que sea el punto de entrada más apropiado para aprender TDD, pero sí estoy convencido que todo practicante de TDD debería leerlo.

Personalmente creo que es un libro para leer de punta a punta, sin los capítulos de la tercera parte de libro tratan sobre patrones y se pueden leer en forma descolgada a modo de consulta, los capítulos de las dos primeras partes están dedicados al desarrollo de dos ejemplos en profundidad que luego son referenciamos en los patrones de la tercera parte.

El libro trata ciertas cuestiones de TDD que muchas veces se pasan por alto, algunas veces se las menciona a la pasada y otra vez ni siquiera se mencionan. Algunas de estas cuestiones que me parece vale la pena destacar:

  • El trabajo en forma iterativa y en pequeños pasos es realmente central a TDD. Beck habla de ciclos de 10 minutos (pag. 143).
  • Es completamente válido retroceder para avanzar, si llegamos a un punto donde estamos integrando nuestro código y vemos que hemos roto algo, puede resultar conveniente tirar lo hecho y comenzar de nuevo (pag. 149). Como estamos trabajando en incrementos realmente chicos, lo que vamos a estar tirando no es mucho, es solo el último incremento. Esto lo veo muy relacionado a la técnica Test and Commit or Revert.
  • La técnica «Log String» (pag. 146) es increíblemente simple y útil a la vez que definitivamente le voy a dedicar un artículo exclusivo.
  • Para el programador el código de test es tan importante como el código de dominio. Esto está mencionado de distintas formas a lo largo del libro y como consecuencia de esto no es raro que la cantidad de código de test sea similar a la cantidad de código de dominio. Asimismo el uso de patrones de diseño aplica tanto al código de dominio como al código de test.
  • Si bien el flujo de trabajo es codear un test a la vez, Beck recomienda comenzar la sesión de programación haciendo una lista de los casos que intentaremos cubrir durante la sesión (pag. 126). Esta lista también la utiliza para registrar casos/situaciones que puedan ir surgiendo durante la sesión sin perder el foco de trabajo: estoy trabajando en un caso, surge una idea, la anotamos en la lista y seguimos con los que estábamos (pag. 137)
  • A la hora de escribir los tests puede resultar conveniente comenzar por escribir el Assert (pag. 128)
  • Refactorizar es fundamental, no es posible hacer TDD sin refactorizar y una de las principales razones (o posiblemente la más importante) para refactorizar es evitar la duplicación de código (en realidad más que evitar duplicación de código lo que buscamos es evitar la duplicación de conocimiento). Esto es mencionado en varios lugares a lo largo del libro. Como que Beck está obsesionado con esto.
  • El apéndice 2 del libro desarrolla un ejemplo muy chiquito pero muy clarificador de la esencia de TDD.
  • El orden en que codeamos los tests puede impactar enormemente en el proceso de TDD (pag. 200). Un determinado orden puede hacer que el proceso fluya armónicamente mientras que la misma lista de tests codeada en un orden distinto puede llevar a un callejón sin salida.

Sin duda hay varias cuestiones más para destacar de este libro, pero estas son las que a mi me resonaron.