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.

Recomendación de libros de «autoayuda»

En esta ocasión voy a referirme a un conjunto de libros que en algún momento (y por puro prejuicio) los habria categorizado como libros de «autoayuda» sin siquiera tener en claro que implica «autoayuda». El punto es que más allá de la categoría son libros que me han resultado muy útiles e interesantes.

El primero de estos libros que quiero mencionar lo leí allá por 2008: Los 7 hábitos de la gente altamente efectiva. Ya en aquel momento este libro era un best seller. Tanto es así que a pesar de que originalmente está en inglés, también ha sido traducido a varios idiomas. De hecho, yo lo leí en castellano. Su autor, Stephen Covey, ha escrito varios libros más en relación a esta misma temática. A partir de este libro fue que empecé a trabajar la formación de ciertos hábitos en mi materia de Ingeniería de Software.

Otro libro que también leí por aquella época es el ya clásico de Francesco Cirillo: «The Pomodoro Technique«. Esta técnica ha cobrado tal popularidad que se han generado una importante cantidad de recursos relacionados entre los que se incluyen varios videos, apps y cursos. Personalmente esta técnica me ha ayudado mucho a enfocar mi trabajo y suelo recomendarla a mis alumnos y colegas. De hecho recuerdo que en la época que dictaba Ingeniería de Software en UNQ, esta era una de las lecturas obligatorias de la materia (mientras escribo estas líneas creo que debería incluir esta lectura en mi materia de UBA).

Finalmente esta semana terminé de leer el libro «Atomic Habits» de James Clear. Este lo compré a comienzos de 2020 a partir de una mención que hizo en Twitter mi colega @hhiroshi. El libro me gustó mucho por varias cuestiones. Encontré justificación «teórica» para varias cuestiones que suelo hacer. También encontré muchas cuestiones para experimentar. Muchos de los capítulos comienzan con anécdotas/historias que hacen muy llevadera la lectura. Un tema no menor en relación con la lectura es la extensión de los capítulos, tienen una extensión tal que permite completar un capítulo en unos 15 minutos (al menos a mi ritmo de lectura). El tema de la generación de hábitos me parece fundamental para trabajar de forma más efectiva. El tener incorporadas ciertas tareas como hábitos hace que uno pueda ejecutar esas tareas de forma «automática» sin necesidad de poner energía/atención extra y de esa forma poder ahorrar esa energía/atención para dedicarla a otras cuestiones de mayor prioridad/valor. Este libro ofrece todo un marco teórico junto con técnicas concretas para generar hábitos y también para eliminar hábitos.

Notas sobre Clean Architecture

Apenas Bob Martin publicó su libro Clean Architecture allá por 2017, leí el índice y me pareció que ya conocía todos los temas tratados. Sin embargo, hace un par de meses, sin haber cambiado de opinión decidí igualmente leerlo. Ayer lo terminé.

Efectivamente considero que el libro no me trajo nada nuevo a mi. O sea, he leído mucho sobre arquitectura de software y tal vez por eso no encontré nada revelador. Sin embargo creo que el libro puede resultar muy valioso para muchos lectores porque de hecho creo que es un muy buen resumen de temas con un enfoque muy concreto y pragmático. Spoiler: la idea central de Clean Architecture es lo que hace unos 20 años Alistair Cockburn bautizó inicialmente como Ports & Adapters y más tarde como Hexagonal Architecture.

Si bien los temas los conocía, algo que encontré muy valioso son algunas explicaciones y argumentos.

Me gustó mucho el capítulo «Clean Embedded Architecture» en el cual trata sobre arquitectura de sistemas embebidos.

También me gustó la «desmitificación» sobre «los micro-servicios».

Una perlita interesante son los capítulos «The Database is a Detail», «The Web is a detail» y «Frameworks are details». Me parece que la posición del autor es demasiado extrema pero igualmente vale la pena leerlos.

Una cuestión que parece importante y que no he visto de forma tan explícita en otros libros es que los principios de diseño «son universales», si bien muchos de ellos han sido popularizados en relación con la programación orientada a objetos, los mismos pueden aplicarse tanto a programas desarrollados en C (que no tiene objetos) como a APIs y Servicios.

En fin, el libro me gusto y lo recomiendo sobre todos para aquellos que no esten muy familiarizados con cuestiones de diseño de software.

4 libros de Agile no tan conocidos pero excelentes

Continuando el aniversario de los 20 años del manifiesto ágil parece un buen momento para compartir algunas recomendaciones de libros.

El primero es la joya oculta de mi biblioteca: Planning Extreme Programming. Estoy seguro que mucha gente ni lo escuchó nombrar pero definitivamente vale una mirada aunque más no sea por sus autores: Kent Beck y Martin Fowler. A pesar de ser un libro de XP no es un libro de código, como su nombre lo indica es un libro de planificación que cubre también varias cuestiones de generales de gestión obviamente desde una perspectiva de XP. No es un libro reciente, es del año 2000, o sea que es previo a la publicación del manifiesto. Al igual que todos los libros la serie XP, el contenido está organizado en capítulos cortos, lo cual facilita la lectura.

Tengo dudas de incluir en este listado el libro The Art of Agile Development de Shore y Warden porque tengo la sesión que es un bastante conocido. Si bien no lo indica en el título, es un libro de XP. Fue publicado en 2007 y en estos días (marzo 2021) se está escribiendo en forma abierta la segunda edición la cual parece muy prometedora. El libro es excelente y es la referencia central de mi materia de Ingeniería de Software. Cubre muchísimas cuestiones que van desde mindset, pasando por temas de gestión y hasta cuestiones de código. Es en un libro de ingeniería de software al estilo XP.

Agile!: The Good, the Hype and the Ugly es un libro un tanto polémico para «los agilistas». Lo conocí gracias a mi amigo @dfontde. El autor del libro es Bertrand Meyer, un referente en el mundo académico de la ingeniería de software. El libro es tal cual lo que indica su título: lo bueno, lo feo y lo popular de agile. Personalmente no comparto algunas de las apreciaciones del autor y justamente por eso lo recomiendo. Resulta interesante leerlo porque Meyer es un referente que lleva muchos años en esta disciplina y que en cierto modo muchos lo asociamos a métodos más tradicionales/pre-agile. Un aporte interesante del libro es que para parte del análisis que hace de agile toma las 10 prácticas ágiles que considera más relevantes/representativas de agile.

Otro libro de un autor reconocido es More Effective Agile, este libro aún lo estoy leyendo, pero lo que llevo leído me pareció excelente. Es un libro reciente, fue publicado a mediados de 2019. Su autor es Steve McConnell, un reconocido autor de libros de ingeniería de software entre los que se encuentran Code Complete, Rapid Development y Software Estimation: Demystifying the Black Art. Hay dos cuestiones que me llevaron a leer este libro. Por un lado, ya había leído mucho material de McConnell (además de sus libros también tiene publicados muchos artículo interesantes) y quería saber su visión de agile. Por otro lado, al ser un libro reciente, me resultaba interesante averiguar qué hay para decir de agile a casi 20 años del manifiesto cuando ya se han publicado cientos de libros de agile. La visión de agile que ofrece McConnell la sentí muy afín con mis propias ideas. En esa visión McConnell desmistifica y corrige algunas falsas creencias (y argumentos de venta) de Agile.