Los libros que como software developer no deberían faltar en tu estantería

Hace unos meses tuve la fortuna de acudir a la JS CraftCamp de Munich, una muy, muy interesante conferencia centrada en JavaScript desde la perspectiva del Craftsmanship. En ella, una de las sesiones que planteé en este Open Space y que resultó verdaderamente enriquecedora, fue la de revisión de Libros. La idea era simple, cuarenta y cinco minutos para charlar de libros que habíamos leído y por el hecho de que nos habían resultado de mucho interés. Amazing!! :)

No cabe decir que la lista que salió como resultado fue muuuuuuy larga, mas jamás os estreséis por lo grande o bien enorme que pueda resultar una labor en un inicio, sencillamente escoged una de las referencias propuestas y empezad a leer.

A lo largo de este género de sesiones, al lado de recoger valiosas referencias, lo más esencial es ver que motivaciones tienen otros en el momento de prosperar sus skills. En el artículo os presentaré cuales son mis libros preferidos, pues han sido esenciales para mi carrera como desarrollador y exactamente en qué orden me hubiese agradado consumirlos.

Empezando por el principio

Hay contenido que puede considerarse más de fondo de guardarropa, de manera que siempre y en todo momento nos viene bien haberlo adquirido y nos da mucha flexibilidad y perspectiva en nuestro trabajo. Tal vez si tuviera que resaltar uno, me quedaría con el Extremme programming explained: Embrance the change de Kent Beck. Su visión del proceso diligente y de las técnicas que componen XP han marcado mi forma de aprender y de trabajar los últimos años.

Por otro lado, hay muchas lecturas aconsejables 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 hoy. Una con la que me siento más identificado recientemente es el The software Craftsman: Professionalism, Pragmatism, Pride de Sandro Mancuso.

Para finalizar, creo que aparte de centrarnos en prosperar nuestros skills como desarrolladores, es del mismo modo esencial o bien más desarrollar nuestra capacidad de aprender, entendiendo mejor en que consiste el proceso de aprendizaje y de qué manera sacarle el máximo partido posible. Para conocer más detalles sobre todo esto, échale una ojeada a este artículo que publiqué hace ya un tiempo y no te pierdas referencias como Apprenticeship Patterns, Thinking and learning o bien Thinking fast and slow.

Dando una vuelta de tuerca

Ya con una buena base y con las baterías cargadas de sabios consejos sobre de qué manera aprender y como es la visión más agile de lo que debería ser un desarrollador, un buen punto para proseguir es comprender de forma más profunda exactamente en qué consisten las prácticas diligentes y por el hecho de que son tan esenciales en el momento de desarrollar software y administrar proyectos y equipos.

Tal vez un buen punto de inicio es comprender Lean y porqué sus principios empapan todo cuanto hacemos en el planeta diligente. Para esto, el Lean from the trenches de Henrik Kniberg nos da una perspectiva práctica y aplicada de de qué manera aproximar un ciclo diligente a las organizaciones.

Para seguir, podemos iniciar con un enfoque más práctico y más próximo al código, de manera que podamos aprender a distinguir el buen código o bien código limpio del código que tiene un mal diseño, no escala y no es flexible ni extensible. Ciertas buenas referencia acá pueden ser tradicionales como el Clean Code de Robert C. Martin o bien las Four rules of simple design de Corey Haines.

Avanzando en el diseño de software y sobretodo en el planeta orientado a objetos en el que muchos vivimos, los principios de OOP y los patrones de diseño son herramientas que debemos añadir lo antes posible a nuestro toolbox. Lejos del Design Patterns de Erich Gamma, el que es más una referencia para preguntar que un libro a leer de principio a fin, podemos decantarse por el práctico y también ilustrado Head First Design Patterns o bien sencillamente centrarnos en las técnicas de diseño orientado a objetos descritas en Practical Object-Oriented Design in Ruby.El objetivo en cualquier caso es exactamente el mismo, aprender a reconocer en el código que escribimos los primordiales patrones de diseño de software orientado a objetos para poder aplicarlos más tarde.

Para finalizar y centrado en el término de mejora continua y calidad del código, no debemos olvidar referencias como Refactoring Ruby Edition, que nos introducen al planeta del refactoring como técnica usada para lograr la mejora de nuestro código sin trastocar su comportamiento perceptible. Esta guía contiene la definición del catálogo de olores que nos dejarán advertir y prosperar las áreas problemáticas de nuestro código, como una descripción detallada de las transformaciones que podemos ir haciendo sobre nuestro código con seguridad.

No debemos olvidar además de esto que, unido al término de refactoring va siempre y en toda circunstancia el de testing, puesto que empleamos este último como herramienta de diseño que nos guía en el proceso de razonar sobre el código, teniendo además de esto el ventajoso efecto colateral de la reducción de fallos y de darnos una red de seguridad, tal como nos cuenta Agile Testing o bien Effective Unit Testing.

Materiales avanzados

Si bien los materiales propuestos en el apartado precedente ya empiezan a ser parcialmente avanzados, es preciso que nuestros superpoderes se prosigan desarrollando con más materiales interesantes. Así, es el instante de pasar al siguiente nivel.

Tal vez, antes de seguir empezaría por el no demasiado tratado Implementation Patterns de Kent Beck. Esta joya nos deja ahondar en los mecanismos alén de los formalismos de definición del diseño de un sistema, como por poner un ejemplo las cláusulas de guarda, la propagación de salvedades, la definición del estado intrínseco o bien extrínseco de las entidades o bien de de qué forma sostener nuestras interfaces públicas para asegurar su extensibilidad.

Siguiendo con la una parte de patrones, es prácticamente obligatoria la referencia de Refactoring to Patterns de Joshua Kerievsky, en tanto que va un paso más en la identificación de los patrones ya aprendidos, mostrándonos como se advierten los equilibrios de fuerzas en un proceso de refactoring y qué resoluciones tomar cuando se decide actuar sobre ellas.

De vuelta al planeta del testing, GOOS o bien Growing Object-Oriented Software Guided by Tests de Steve Freeman, nos enseña como partiendo del término de Waling Skeleton podemos crear un sistema desde 0 a producción aprovechando los beneficios de cada género de test en todos y cada uno de ellos de los estratos de nuestro diseño. En determinadas fases, puede ser realmente recomendable fortalecer nuestros conocimientos sobre Mocks, Fakes and Stubs, sobretodo teniendo presente que el GOOS nos introduce a un flujo de trabajo con TDD muy outside-in y próximo sobre todo a su vertiente más mockist o bien de la London School.

Finalmente DDD Distilled de Vaughn Vernon es la versión sintética de su Implementing Domain-Driven Design, el que nos guía mediante una serie de formalismos que definen de qué forma un dominio rico puede ser definido desde sus repositorios, pasando por los agregados, acontecimientos de dominios o bien la definición de un lenguaje omnipresente en nuestros sistemas/negocio.

A inconvenientes específicos soluciones concretas

Y es que muchas veces, no todo de depende de los fundamentos generales que hemos ido cultivando con esfuerzo en los precedentes apartados. A mi juicio más personal, creo que si bien nuestra actividad laboral se centre en un ambiente o bien conjunto de lenguajes con unas peculiaridades específicas, no debemos dejar de la lado el resto de paradigmas, estudiándolos en profundidad con exactamente la misma perseverancia (como por poner un ejemplo el paradigma funcional con referencias como Professor Frisby’s Mostly adequate guide to functional programming). En este sentido, tal vez no vayamos a programar de manera directa en ningún lenguaje funcional como Haskell, mas si estudiamos sus motivaciones y empleo vamos a aprender multitud de lecciones esenciales que aplicar a nuestra forma de desarrollar software, como pueden ser la relevancia de las funciones pequeñas, con escasos factores, sin efectos colaterales, la imperturbabilidad o bien la memoización.

Aparte de el análisis del paradigma funcional, muchos otros paradigmas pueden resultar de interés como el de la programación reactiva, el trabajo con código legado o bien de qué manera hacer presentaciones públicamente. En este cajón desastre que procura ser esta apartado me agradaría resaltar ciertas referencias más notables que me he encontrado y que no tienen un sitio específico en el mapa trazado en apartados precedentes.

Análisis del código actual y de qué forma identificar sus inconvenientes, hot spots o bien áreas de mejora: Your Code As A Crime Scene.

De qué manera encarar proyectos de trabajo sobre código legado y qué técnicas podemos emplear para sistematizar el proceso y ser efectivos: Working Effectively with legacy code y The Mikado Method.

Mejora de nuestro proceso de despliegue con la intención de que sea lo más flexible posible y esté ceñido a nuestros procesos internos diligentes de trabajo: Continuous delivery y Ship it.

Comunicar es una necesidad que todos tenemos. Seamos efectivos en de qué manera mostramos al planeta 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 decantarse por el paradigma más conveniente, incorporado con el mejor lenguaje y en el ambientes más recomendable para el inconveniente que debamos solucionar

Nuestra carrera como desarrollador estará marcada por el cambio incesante en la tecnología, la que se convierte a una velocidad mareante. En este sentido, nuestro sacrificio no puede estar enfocado al cien por ciento en desarrollar nuestros conocimientos en torno a una tecnología o bien framework que puede estar fallecido en un año o bien 2.

Debemos evolucionar y parar de ser Android Developer o bien PHP Developer. Debemos aspirar a ser un Software Developer que sea capaz de decantarse por el paradigma más conveniente, incorporado con el mejor lenguaje y en el ambientes más recomendable para el inconveniente que debamos solucionar. Este género de aspiración requiere un background considerablemente más cultivado que la simple devoción a una tecnología, con lo que enfoquemos nuestro trabajo y también invirtamos tiempo en conocimientos que no serán caducos y que nos acompañasen en nuestra carrera alén del próximo lenguaje o bien framework de tendencia.

¿Qué referencias agregarías y qué te han aportado como profesional?