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.

Software Craftsmanship: una visión distinta de nuestra profesión

Recientemente terminé de leer el libro Software Craftsmanship: The New Imperative de Pete McBreen. Es un libro que trata conceptualmente, o incluso podría decir filosóficamente, sobre la profesión del desarrollador de software. Creo que no hay muchos libros sobre esta temática, rápidamente se me vienen a la mente los tres que tengo en mi biblioteca: The Pragmatic Programmer (Thomas & Hunt), Soft Skills(Sonmez) y The Software Craftsman (Mancuso). Pero ninguno de estos libros tiene un enfoque filosófica tan profunda.

Es un libro que tiene casi 20 años y tal vez por ello hay cuestiones que hoy en día suenan como obvias pero que sin duda en su momento resultaron innovadoras y/o polémicas. El libro fue publicado en agosto de 2001, esto es apenas un par de meses después de la publicación del manifiesto ágil. Muchos de los puntos planteados en el libro suenan muy alineados con el manifiesto, cosa muy común hoy en día pero posiblemente muy llamativa en aquel momento.

Hace un par de semanas escribí sobre la idea de Good Enough Software que se expone en este libro. En línea con esa idea el autor hace una fuerte crítica al modelo de desarrollo propuesto por la ingeniería de software. A mi parecer algunas de esas críticas han quedado sin efecto en la actualidad por el simple hecho de que la ingeniería de software ha «evolucionado» incorporando, entre otras cosas, muchas ideas de los métodos ágiles. Sin embargo, hay algunas críticas que me parece siguen vigentes. En la visión del autor, la ingeniería de software propone una forma de trabajo basada en «hordas de programadores promedio» en contraposición con la propuesta de craftsmanship que sostiene «equipos pequeños de programadores muy buenos». Y no termina ahí, dice que muchos de esos «programadores promedio» están «sobre remunerados». Ante esto cree que las organizaciones, en lugar de contratar 15 programadores promedio sobre remunerados, deberían utilizar ese mismo presupuesto pero para contratar 3 programadores muy buenos (craftsmen). Esto haría que estos 3 programadores estuvieran muy bien remunerados y colateralmente esto ayudaría a elevar el nivel y de la profesión y la calidad del software generado.

EL libro me encantó y creo que es una lectura muy recomendada para aquellos profesionales de sistemas (no solo desarrolladores) que tengan ganas de reflexionar sobre el desarrollo de software.

Les dejo aquí algunos títulos/frases del libro:

  • Good developers are more valuable than their managers
    (totalmente de acuerdo, pero pocas veces reflejado en las remuneraciones)
  • Software Engineering forces us to Forget the individual
    (este planteo parece muy bueno, pero creo que en la actualidad es más preciso decir «software factories forces us to forget the individual»)
  • Craftsmanship is personal
    (de acuerdo)
  • Mastery implies taking responsibility for passing on the craft
    (esta idea me pareció muy buena)
  • Let your Software Craftsman pick the rest of the development team
    (esto me parece conceptualmente fantástico aunque nunca lo viví)
  • Avoid bleeding-edge technology is at all posible
    (muy de acuerdo, aunque dependiendo del contexto no siempre es posible)
  • Think applications, not projects
    (me gusta, muy en linea con ideas de equipos de producto y #noProjects)

The Pragmatic Programmer

La primera edición de este libro fue publicada en 1999 pero yo no lo conocí hasta ~2005. Y no lo leí hasta 2009 cuando lo encontré la biblioteca de la empresa en la que trabajaba en aquella época. El año pasado se publicó la edición 20 aniversario y no dudé en comprarlo. Ayer terminé de leerlo.

Mas allá de la elegancia de la edición tapa dura, a nivel contenido el libro no tiene desperdicio y creo que es una lectura obligada para todo developer. Cubre temas muy variados que van desde principios de diseño, estimación, hasta ética profesional pasando por programación concurrente, técnicas de testing y recomendaciones de organizacional personal.

Complementariamente a la usual división en capítulos, el libro está organizado en «temas» (topics) que son subdivisiones de los capítulos y la extensión de cada uno es tal que su lectura puede realizarse en 30 minutos (lo cual a mi personalmente me facilita mucho la lectura). Asimismo al final de cada tema se listan los temas relacionados y se ofrece una serie de ejercicios, algunos de reflexión, otros de programación, etc.

Los autores son Dave Thomas y Andrew Hunt, ambos autores del Agile Manifesto. Tal vez por eso muchas de las cuestiones tratadas en el libro están abordadas desde una perspectiva ágil.

Esta edición 20 aniversario es bastante distinta a la edición original de 1999. La esencia de libro es la misma pero el contenido ha sido totalmente actualizado. De hecho los propios autores reconocen que hay partes del libro que fueron completamente reescritas.

El mejor libro de arquitectura

La semana pasada terminé de leer el libro «Building Evolutionary Architectures» y me resultó posiblemente el mejor libro de arquitectura que lei en mi vida (y eso que he leído varios libros sobre el tema).

Compré el libro porque me atrapó el título y ya había leído otras cosas de los autores. El libro no delira con definiciones abstractas, es muy concreto y el planteo de «evolvability» como propiedad de la arquitectura me resultó muy novedoso y super apropiado en la actualidad. Si bien por momentos me hizo un poco de ruido el tono «grandilocuente» con el que se refiere a los arquitectos corporativos, finalmente me terminó convenciendo el lugar y las responsabilidades que les asigna (que lejos está de lo que suelo ver cotidianamente en la industria).

Algunos otros puntos que me parece vale la pena destacar son:

  • La idea de usar fitness functions para verificar el cumplimiento de ciertas propiedades de la arquitectura
  • ¡Habla de testing! Lo cual no es común en los libros de arquitectura
  • Trata diversas cuestiones de negocio/organización que no siempre están presenten en los libros de arquitectura. Entre estas cosas habla de la estructura de equipo.
  • Toma muy en cuenta la arquitectura física y el potencial acoplamiento que esta puede generar.
  • Cubre cuestiones tanto de green field projects como de brown field projects

Si tienen la oportunidad, bien merece dedicarle un tiempo.