Hace unos meses tuve la suerte de asistir a la JS CraftCamp de Munich, una interesantísima conferencia centrada en JavaScript desde el punto de vista del Craftsmanship. En ella, una de las sesiones que propuse en este Open Space y que resultó realmente enriquecedora, fue la de revisión de Libros. La idea era simple, 45 minutos para hablar de libros que habíamos leído y porque nos habían resultado de gran interés. Amazing!! :)
No cabe decir que la lista que salió como resultado fue muuuuuuy larga, pero nunca os agobiéis por lo grande o titánica que pueda resultar una tarea inicialmente, simplemente elegid una de las referencias propuestas y comenzad a leer.
Durante este tipo de sesiones, al margen de recolectar valiosas referencias, lo más importante es ver que motivaciones tienen otros a la hora de mejorar sus skills. En este artículo os presentaré cuales son mis libros favoritos, porque han sido fundamentales para mi carrera como desarrollador y en qué orden me hubiera gustado consumirlos.
Empezando por el principio
Hay contenido que puede considerarse más "de fondo de armario", de forma que siempre nos viene bien haberlo adquirido y nos da mucha flexibilidad y perspectiva en nuestro trabajo. Quizá si tuviese que destacar uno, me quedaría con el Extremme programming explained: Embrance the change de Kent Beck. Su visión del proceso ágil y de las técnicas que componen XP han marcado mi forma de aprender y de trabajar los últimos años.
Por otra parte, existen muchas lecturas recomendables para tener una clara visión de lo que puede llegar a representar nuestra profesión y donde nos dejan movimientos como el Software Crafmanship, tan extendidos a día de hoy. Una con la que me siento más identificado últimamente es el The software Craftsman: Professionalism, Pragmatism, Pride de Sandro Mancuso.
Por último, creo que además de centrarnos en mejorar nuestros skills como desarrolladores, es igualmente importante o más desarrollar nuestra capacidad de aprender, entendiendo mejor en que consiste el proceso de aprendizaje y cómo sacarle el máximo partido posible. Para conocer más detalles sobre todo esto, échale un vistazo a este artículo que publiqué hace un tiempo y no te pierdas referencias como Apprenticeship Patterns, Thinking and learning o Thinking fast and slow.
Dando una vuelta de tuerca
Ya con una buena base y con las baterías cargadas de sabios consejos sobre cómo aprender y cual es la visión más agile de lo que debería de ser un desarrollador, un buen punto para continuar es entender de forma más profunda en qué consisten las prácticas ágiles y porque son tan importantes a la hora de desarrollar software y gestionar proyectos y equipos.
Quizá un buen punto de partida es entender Lean y porqué sus principios impregnan todo lo que hacemos dentro del mundo ágil. Para ello, el Lean from the trenches de Henrik Kniberg nos da una perspectiva práctica y aplicada de cómo acercar un ciclo ágil a las organizaciones.
Para continuar, podemos comenzar con un enfoque más práctico y más cercano al código, de forma que podamos aprender a diferenciar el buen código o código limpio del código que tiene un mal diseño, no escala y no es flexible ni extensible. Algunas buenas referencia aquí pueden ser clásicos como el Clean Code de Robert C. Martin o las Four rules of simple design de Corey Haines.
Avanzando en el diseño de software y sobretodo en el mundo orientado a objetos en el que muchos vivimos, los principios de OOP y los patrones de diseño son herramientas que debemos incorporar cuanto antes a nuestro toolbox. Lejos del Design Patterns de Erich Gamma, el cual es más una referencia para consultar que un libro a leer de principio a fin, podemos optar por el práctico e ilustrado Head First Design Patterns o simplemente centrarnos en las técnicas de diseño orientado a objetos descritas en Practical Object-Oriented Design in Ruby.El objetivo en todo caso es el mismo, aprender a reconocer en el código que escribimos los principales patrones de diseño de software orientado a objetos para poder aplicarlos posteriormente.
Por último y centrado en el concepto de mejora continua y calidad del código, no debemos olvidar referencias como Refactoring Ruby Edition, que nos introducen al mundo del refactoring como técnica utilizada para conseguir la mejora de nuestro código sin alterar su comportamiento observable. Esta guía contiene la definición del catálogo de olores que nos permitirán detectar y mejorar las áreas problemáticas de nuestro código, así como una descripción detallada de las transformaciones que podemos ir haciendo sobre nuestro código de forma segura.
No debemos olvidar además que, unido al concepto de refactoring va siempre el de testing, ya que utilizamos este último como herramienta de diseño que nos guía en el proceso de razonar sobre el código, teniendo además el beneficioso efecto colateral de la reducción de errores y de proporcionarnos una red de seguridad, tal y como nos cuenta Agile Testing o Effective Unit Testing.
Materiales avanzados
Aunque los materiales propuestos en el apartado anterior ya comienzan a ser "relativamente" avanzados, es necesario que nuestros superpoderes se sigan desarrollando con más materiales interesantes. Así pues, es el momento de pasar al siguiente nivel.
Quizá, antes de nada comenzaría por el no demasiado tratado Implementation Patterns de Kent Beck. Esta joya nos permite profundizar en los mecanismos más allá de los formalismos de definición del diseño de un sistema, como por ejemplo las cláusulas de guarda, la propagación de excepciones, la definición del estado intrínseco o extrínseco de las entidades o de cómo mantener nuestras interfaces públicas para garantizar su extensibilidad.
Siguiendo con la parte de patrones, es casi obligatoria la referencia de Refactoring to Patterns de Joshua Kerievsky, ya que va un paso más en la identificación de los patrones ya aprendidos, mostrándonos como se detectan los equilibrios de fuerzas en un proceso de refactoring y qué decisiones tomar cuando se decide actuar sobre ellas.
De vuelta al mundo del testing, GOOS o Growing Object-Oriented Software Guided by Tests de Steve Freeman, nos muestra como partiendo del concepto de Waling Skeleton podemos crear un sistema desde 0 a producción aprovechando las ventajas de cada tipo de test en cada uno de los estratos de nuestro diseño. En ciertas fases, puede ser muy conveniente reforzar nuestros conocimientos sobre Mocks, Fakes and Stubs, sobretodo teniendo en cuenta que el GOOS nos introduce a un flujo de trabajo con TDD muy outside-in y cercano sobre todo a su vertiente más mockist o de la London School.
Por último DDD Distilled de Vaughn Vernon es la versión sintética de su Implementing Domain-Driven Design, el cual nos guía a través de una serie de formalismos que definen cómo un dominio rico puede ser definido desde sus repositorios, pasando por los agregados, eventos de dominios o la definición de un lenguaje ubicuo en nuestros sistemas/negocio.
A problemas concretos soluciones concretas
Y es que en muchas ocasiones, no todo de depende de los fundamentos generales que hemos ido cultivando con esmero en los anteriores apartados. En mi opinión más personal, creo que aunque nuestra actividad laboral se centre en un entorno o conjunto de lenguajes con unas características concretas, no debemos dejar de la lado el resto de paradigmas, estudiándolos en profundidad con la misma constancia (como por ejemplo el paradigma funcional con referencias como Professor Frisby’s Mostly adequate guide to functional programming). En este sentido, quizá no vayamos a programar directamente en ningún lenguaje funcional como Haskell, pero si estudiamos sus motivaciones y uso aprenderemos multitud de lecciones importantes que aplicar a nuestra manera de desarrollar software, como pueden ser la importancia de las funciones pequeñas, con pocos parámetros, sin efectos colaterales, la inmutabilidad o la memoización.
Además de el análisis del paradigma funcional, otros muchos paradigmas pueden resultar de interés como el de la programación reactiva, el trabajo con código legado o cómo hacer presentaciones en público. En este cajón desastre que intenta ser esta apartado me gustaría destacar algunas de las referencias más notables que me he encontrado y que no tienen un lugar concreto en el mapa trazado en apartados anteriores.
Análisis del código actual y cómo identificar sus problemas, hot spots o áreas de mejora: Your Code As A Crime Scene.
Cómo afrontar proyectos de trabajo sobre código legado y qué técnicas podemos utilizar para sistematizar el proceso y ser efectivos: Working Effectively with legacy code y The Mikado Method.
Mejora de nuestro proceso de despliegue con el fin de que sea lo más flexible posible y esté ajustado a nuestros procesos internos ágiles de trabajo: Continuous delivery y Ship it.
Comunicar es una necesidad que todos tenemos. Seamos efectivos en cómo mostramos al mundo nuestras ideas: Presentation Zen y Slide:ology: The Art and Science of Creating Great Presentations.
Conclusiones
Debemos aspirar a ser un "Software Developer" que sea capaz de optar por el paradigma más adecuado, implementado con el mejor lenguaje y en el entornos más conveniente para el problema que tengamos que resolver
Nuestra carrera profesional como desarrollador va a estar marcada por el cambio constante en la tecnología, la cual se transforma a una velocidad vertiginosa. En este sentido, nuestro esfuerzo no puede estar enfocado al 100% en desarrollar nuestros conocimientos en torno a una tecnología o framework que puede estar muerto en un año o dos.
Debemos evolucionar y dejar de ser "Android Developer" o "PHP Developer". Debemos aspirar a ser un "Software Developer" que sea capaz de optar por el paradigma más adecuado, implementado con el mejor lenguaje y en el entornos más conveniente para el problema que tengamos que resolver. Este tipo de aspiración requiere un background mucho más cultivado que la simple devoción a una tecnología, así que enfoquemos nuestro trabajo e invirtamos tiempo en conocimientos que no van a ser perecederos y que nos acompañaran en nuestra carrera profesional más allá del próximo lenguaje o framework de moda.
¿Qué referencias añadirías y qué te han aportado como profesional?
