Chemaclass - tdd

bashunit

2024-10-30T00:00:00+00:00

bashunit es un framework de testing ligero y fácil de usar para Bash. Características como testing paralelo y de snapshots, dobles de test, data providers y toneladas de assertions incorporadas.

Respaldado por documentación clara y una comunidad activa, se ha convertido en un favorito para testing confiable en Bash. Lo que comenzó como una simple frustración de desarrollo ha crecido hasta convertirse en una herramienta open-source que hace que el testing en Bash sea mucho más fácil y divertido.

La historia detrás de bashunit
¿Por qué crear otra librería de testing?
¿Cómo está hoy en día?
Características principales
Lightning tech talk

La historia detrás de bashunit #

El viaje para crear bashunit comenzó con una simple frustración: trabajaba con un equipo donde cada commit tenía que empezar con el nombre del ticket. Como me gusta trabajar en pequeños pasos con commits rápidos e iterativos, añadir la clave y número del ticket a cada commit se convirtió en un gran obstáculo, ralentizando mi flujo de desarrollo con fricción innecesaria.

Después de unos días así, decidí automatizarlo. Git tiene un hook útil, prepare-commit-msg, que te permite alterar los mensajes de commit antes de que se finalicen. Creé un (script) en Bash que automáticamente obtiene la clave y número del ticket del nombre de la rama y lo inserta en el mensaje del commit, haciendo mi proceso más fluido y eficiente.

Como alguien que valora la mejora continua, comencé a añadir más características a este script. Sin embargo, se hizo evidente que mantener y probar estos cambios manualmente llevaba demasiado tiempo y era propenso a errores. Para hacer el desarrollo más seguro y eficiente, creé una función assert(enlace), permitiendo tests automatizados que verificaban el comportamiento esperado basado en la salida del script.

La función assert me permitió definir múltiples assertions en un archivo separado, facilitando la validación de que cualquier refactorización del hook original mantuviera el comportamiento esperado. Si un cambio rompía inadvertidamente la funcionalidad existente, lo señalaría instantáneamente, haciéndome saber de inmediato que algo necesitaba arreglarse. Esta configuración proporcionaba retroalimentación inmediata y ayudaba a asegurar que cualquier actualización al script no interrumpiera su lógica prevista. Por ejemplo:

En el ejemplo anterior, notarás que ejecuto el “SCRIPT” real como el segundo argumento en la función assert, comparando su salida con el valor esperado proporcionado como primer argumento. Aquí, tenemos dos casos de test, cada uno exportando TEST_BRANCH para simular cómo el mensaje del commit variaría según el nombre de la rama. Esta configuración emula el comportamiento real, permitiéndonos probar cómo diferentes nombres de rama afectan el formato del mensaje del commit. Más ejemplos aquí.

Decidí separar la función assert de los casos de test, como se muestra aquí, para mantener las cosas modulares y reutilizables. Luego, creé un runner para ejecutar cada caso de test independientemente, reduciendo la interferencia entre tests y mejorando la confiabilidad. Puedes ver esa configuración aquí. Esta estructura hizo el testing automatizado más fácil y la refactorización más segura.

Esta fue una gran mejora porque facilitó separar los casos de test de la lógica del runner de tests en sí. Esta estructura clara ha simplificado tanto la creación como la gestión de tests.

Ahora los tests estaban organizados y tuve una idea:

## Idea de seguimiento
Separar la lógica de testing en otro repositorio,
para que pueda ser reutilizada en cualquier lugar.

Y así comenzó. En ese momento, no sabía mucho sobre Bash o las mejores formas de usar un proyecto Bash como dependencia. Pero sabía que podía empezar usando un submódulo de Git, aunque no soy muy fan de ellos.

El 4 de septiembre de 2023, lancé la versión 0.1, que presentaba un runner funcional y una única función de assertion: assertEquals. Más tarde, se lanzó la versión 0.2, permitiendo que ./bashunit fuera un ejecutable independiente, ejecutable desde cualquier carpeta. Así es como se veía entonces:

Compartí el proyecto con algunos amigos que rápidamente se unieron para ayudar con la documentación, el sitio web, assertions adicionales, testing de snapshots y decisiones clave. Para enfatizar su espíritu open-source y propiedad comunitaria, lo moví a una organización que creamos específicamente para compartir proyectos OSS, convirtiéndolo en un proyecto verdaderamente colaborativo en lugar de uno individual.

¿Por qué crear otra librería de testing? #

Ahora sé que existen otras librerías de testing para Bash. Pero cuando empecé con bashunit, no las conocía, y francamente, todavía no soy un experto en Bash. Para cuando me enteré de estas alternativas, ya era demasiado tarde, bashunit había ganado suficiente impulso y entusiasmo para seguir adelante.

Mientras que esas otras librerías pueden servir casos de uso específicos, usar Bash moderno, o ser desarrolladas por desarrolladores de Bash más experimentados, bashunit aspira a diferenciarse ofreciendo una gran experiencia de desarrollador, moldeada por años de trabajo con varios frameworks de testing.

Me preguntaron sobre las diferencias el 7 de septiembre de 2023, y aquí está mi respuesta: Pregunta: Diferencia con pgrange/bash_unit.

¿Cómo está hoy en día? #

Hoy, puedes instalar bashunit via curl, Homebrew, MacPorts, descargando el último release de GitHub, o incluso compilándolo tú mismo desde el código fuente. Completamente open-source.

El proyecto está escrito en Bash 3.2 (de 2007) ya que esa es la versión por defecto en macOS, incluso ahora, en 2024. Esta compatibilidad significa que bashunit funciona sin problemas en esa versión, y planeo mantener el soporte para ella.

Para asegurar la calidad, probamos cada característica con tests unitarios, funcionales y de aceptación, haciendo que bashunit sea su propio “primer usuario” de cada nueva característica. También tenemos varios workflows de CI usando GitHub actions que ejecutan tests en diferentes plataformas para verificar compatibilidad y confirmar que todo funciona como se promete.

En junio de 2024, bashunit fue integrado en PHPStan para sus tests end-to-end, permitiendo el uso de las assertions de bashunit independientemente de su runner. Esta flexibilidad resultó ser muy útil.

El verano pasado, fui invitado a hablar sobre bashunit en la International PHP Conference en Berlín, junto con Manu, otro contribuidor. Este proyecto ha abierto puertas y ha llevado a mucha gratitud de usuarios que aprecian el trabajo que hemos puesto en él.

Características principales #

bashunit incluye funciones clásicas del ciclo de vida como set_up, tear_down, set_up_before_script y tear_down_after_script.

También soporta una amplia gama de parámetros de línea de comandos y valores de configuración. Algunos de mis favoritos incluyen:

--parallel
--filter
--stop-on-failure
--verbose

También proporcionamos data providers para ejecutar los mismos casos de test con diferentes inputs.

Para dobles de test, bashunit ofrece mocks y spies. Estos funcionan dentro del mismo proceso que el test, pero actualmente no funcionan entre procesos, un área para mejorar.

Incluye potente testing de snapshots, facilitando la verificación de salidas de comandos o scripts a lo largo del tiempo.

bashunit ofrece un amplio conjunto de assertions nativas para casos de test, incluyendo:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

Incluso puedes crear tus propias assertions personalizadas para extender las capacidades de bashunit.

Con más de 25 contribuidores y más de 325 estrellas en GitHub en solo un año de desarrollo en tiempo libre, estoy genuinamente orgulloso de lo que este proyecto se ha convertido.

Lightning tech talk #

Recientemente, presenté una lightning tech talk en un meetup de hackers, haciendo una demo de bashunit a una audiencia de más de 100 personas. ¡Fue una experiencia increíble compartir esta herramienta con una audiencia tan comprometida!

Logo original de bashunit diseñado por Antonio.

Pair Programming Efectivo

2024-03-28T00:00:00+00:00

¿Qué es el pair programming? Dos personas trabajando juntas en el mismo problema, al mismo tiempo.

No se trata de que una persona muestre sus habilidades frente a otra, ni de que una persona tenga miedo de cometer errores debido al síndrome del impostor.

Cada persona tendrá un rol:

Navegador: prestará atención al panorama general; ej: arquitectura, relación entre colaboradores, diseño de objetos, etc.
Conductor: prestará atención a los pequeños detalles; ej: naming, convenciones de código, sintaxis de escritura, diseño de objetos, etc.

La pareja podría, y debería, intercambiar roles ocasionalmente; ej: cada X commits pusheados, cada 10 min,… depende de ellos.

El pair programming no debería considerarse una práctica solo para “seniors” hacia juniors, sino independientemente del nivel de experiencia de los miembros del equipo.

Se trata del flujo de colaboración, la comunicación de calidad, la ausencia de sentirse juzgado y la idea de dar la bienvenida a la vulnerabilidad con tus compañeros, sabiendo que te apoyarán y ayudarán.

Se trata de desafiarse constantemente mutuamente, buscando la solución más pragmática mientras se mantiene simple. Siempre buscando retroalimentación rápida al hablar entre ustedes, pero también sobre la solución que acordaron implementar y su dirección.

Se trata del bucle de retroalimentación corto, rápido e inmediato mientras hablas con tu compañero, quien revisa tu código sobre la marcha. Puedes guiar como navegador o ayudar al conductor a validar sus ideas en un panorama más amplio.

Se trata de la atmósfera constante de compartir conocimiento por defecto, reduciendo bus-factors y áreas de conocimiento aislado al máximo. Aumentando el enfoque al tener dos mentes trabajando en la misma tarea simultáneamente.

Se trata de cohesión de equipo y afilar el sentimiento de que pertenecemos. Cuando entendemos las fortalezas y debilidades de cada uno, nos daremos cuenta de cuánto podemos ayudarnos a crecer mutuamente.

¿Cómo puedes practicar pair programming? #

El pair programming puede hacerse de diferentes maneras:

Puedes empezar y terminar una tarea con pairing. Puedes limitarlo a 30, 60, 90 minutos. De cualquier manera, se recomienda tener pausas en el medio - Pomodoro.
Puedes empezar la tarea juntos y parar cuando uno de tus compañeros se sienta lo suficientemente confiado para continuar solo.

Depende del equipo, y de la tarea en contexto, decidir cuándo y cómo aplicar pairing para sacar lo mejor de ello.

Esto no significa que debas trabajar constantemente “sin importar qué” en pareja. No se trata de crear reglas; por el contrario, se trata de abrazar esta práctica hasta el punto de que te sientas confiado para elegir cuándo y cómo usarla para sacar lo mejor de ella.

El pair programming podría convertirse en una de las mejores herramientas en la caja de herramientas de tu equipo para las interacciones diarias. No porque lo hayas leído en algún lugar, sino por los beneficios que tú y tu equipo encontrarán.

Patrones Comunes #

Diferentes estrategias para pairing efectivo #

Driver-Navigator: Una persona está conduciendo el código (con el teclado), enfocándose en el aspecto de detalle de la tarea en sí. La otra es navegadora (sin teclado), teniendo una imagen más abstracta de la tarea en mente.
Ping-Pong: Cambio frecuente de roles driver-navigator en pequeñas interacciones, ej: cada N minutos, cada N commits, etc.
Backseat driver: El navegador se involucra activamente con el conductor.
Tourist guide: El navegador aprende pasivamente con el conductor.

Anti-patrones mientras haces pairing #

The silent partner: El navegador no participa, está en silencio.
The solo act: El conductor ignora todas las aportaciones del navegador.
Distracted pair: La pareja no se enfoca en el problema a resolver.
The Dictator: Una persona está diciendo qué hacer, ignorando las aportaciones del otro.
Philosophical pair: La pareja está haciendo bikeshedding en temas irrelevantes.
The code war: La pareja no llega a un acuerdo y comienza una guerra innecesaria, que desperdicia tiempo y esfuerzo.

¿Quieres más? Mira esto: Learning Through KATAS

La conclusión #

El pairing no es una regla que imponer, es una herramienta a la que recurrir. Úsalo cuando la tarea es compleja, el conocimiento está aislado o lo que está en juego es importante. Sáltalo cuando el trabajo es trivial. El objetivo nunca es “hacer siempre pairing”, es mejor software y un equipo más fuerte. Elige una tarea real esta semana, hazla en pareja e intercambia roles a menudo. Los beneficios aparecen más rápido de lo que esperas.

¿Cómo Testear Métodos Privados?

2023-10-20T00:00:00+00:00

Esta pregunta me la han hecho muchas veces a lo largo de los años. Aquí recopilo mis ideas al respecto.

Respuesta corta #

Nunca.

Respuesta larga #

Nunca jamás.

¿Y si…? #

Si realmente quieres testear un método privado, considera extraer esa lógica del método privado en una clase separada, y escribe un test unitario para el comportamiento de esa clase.

Para este, me inspiré en el post original de Fran Iglesias.

¿Equipos de QA Dedicados en Software?

2023-05-17T00:00:00+00:00

Esto será controvertido, pero hablemos de la posición de QA. La verdad oculta detrás de la falta de calidad del software y por qué esto debería preocuparte si escribes software.

QA es un rol, no una posición #

Como desarrollador de software, cuando escribes software, eres responsable de la calidad de lo que sea que estés escribiendo. Una tercera persona actuando como QA podría encontrar que tu solución no funciona como se esperaba, pero ¿cómo es posible? Podrías argumentar que podrían encontrar casos límite, pero ¿cómo podría ser posible si el software ya fue testeado previamente?

El objetivo final de un equipo de software es hacer la posición de QA inútil porque no deberían encontrar nada más que software bien funcionando. Pero ¿cómo llegas a ese punto? ¿Cómo podemos asegurar que el software que escribimos funciona como se espera y no hay necesidad de una persona QA en nuestro equipo?

La verdad oculta detrás de la falta de calidad del software #

Desafortunadamente, en nuestra industria del software, la demanda de proyectos “rápidos, rápidos y sucios” terminó en MVPs pobremente desarrollados simplemente aplicando parches y código sobre código con solo testing manual comprobando caminos felices, a veces incluso ignorando casos límite.

“La fecha límite es en una semana, ¡así que mejor termínalo a tiempo!”

No aprendemos la importancia de lo que el testing automatizado puede aportar a nuestro trabajo diario, así que no lo tomamos en serio, y por lo tanto, no lo practicamos lo suficiente. Y, por esa misma razón, porque no lo practicamos, no sabemos cómo realizarlo correctamente. ¡Sí, estoy hablando de escribir tests automatizados que prueban el comportamiento de tu software!

Nuestra incapacidad para escribir código testeable resulta en software que es difícil de testear, y por lo tanto delegamos el testing a terceros trasladando la responsabilidad de la calidad final general del producto o servicio que escribimos.

La práctica hace al maestro #

Debes aprender y aplicar técnicas de testing apropiadas cuando tengan sentido. ¿Cómo y cuándo usar efectivamente dobles de test, preparar tests solitarios o sociables, qué compromisos y razones respaldan tu mente al elegir uno u otro camino hacia tus estrategias de testing?

Eres la última y principal persona responsable de tu conocimiento, así que mejor invierte en ti mismo porque nadie más lo hará por ti.

Mira todo lo que haces como una oportunidad de aprendizaje. Practica y mejora por defecto en todo lo que haces.

Si no sabes cómo empezar, aquí está mi consejo favorito: siempre puedes practicar y mejorar tus habilidades de testing usando katas de código. Lee más sobre este tema aquí.

Buena teoría, pero… ¿para qué molestarse? #

El testing manual es, por supuesto, necesario. Es otra estrategia de testing que no estoy culpando o atacando. Aún podríamos necesitar una persona dedicada a cargo de descubrir qué nuevas funcionalidades queremos construir para satisfacer a nuestros clientes. Pero este post no es sobre esa posición.

Se trata de acortar el bucle de retroalimentación. Si puedes escribir software para que funcione de maneras específicas, ¿no puedes escribir tests automatizados para probar que el software que escribiste se comporta de la manera que esperas?

Si has cubierto con tests automatizados el comportamiento de tu software a cualquier nivel que tenga sentido, ¿qué queda para una persona QA dedicada?

La próxima vez que pienses “Necesitamos una persona QA para testear esto”, intenta el ejercicio de pensar en cambio, “¿Cómo puedo escribir un test automatizado que verifique lo que esperaría si una persona QA estuviera comprobando esto?”

Y así es como cambias la “posición de QA a tiempo completo” en una “mentalidad de rol para todos los que escriben software.”

El código nunca miente y nunca olvida; una vez que está escrito y automatizado en tu pipeline, puedes ejecutarlo en cualquier momento sin coste.

Entrevista sobre XP y Agile

2023-01-09T00:00:00+00:00

Mi entrevista con devm.io sobre Agile y Extreme Programming.

devm.io: Hablamos con Chema, un desarrollador de software y experto en Extreme Programming, sobre su tema favorito y su próximo evento en vivo Update Your Team To Be More Extreme.

¿Podrías contarnos un poco sobre ti, quién eres y qué haces? #

Chema: Mi nombre es Jose Maria Valera Reales, pero todos me llaman Chema. Soy originalmente de España pero vivo en Berlín desde 2015. He estado trabajando como desarrollador de software desde 2013. En los últimos años, me he enfocado en alcanzar la excelencia y descubrir cómo ayudar a mis compañeros y, con ellos, a toda la comunidad de software a mejorar en nuestra profesión.

Actualmente soy Tech Lead en Lautsprecher Teufel GmbH, donde trabajo con el equipo del webshop de e-commerce. También disfruto del software de código abierto, así que me gusta crear pull requests para otros repositorios, y también me encanta cuando recibo pull requests de otros.

¿Cómo describirías Extreme Programming? ¿Qué lo hace tan “extremo”? #

Extreme Programming es el enfoque más directo y pragmático para abrazar Agile en tu equipo de software. Incorpora soluciones basadas en valores, principios y prácticas. No tienes que usar o hacer todo, sino lo que se ajuste a ti y a tu equipo en tu contexto. Sin embargo, estas son soluciones generales útiles que funcionan mejor cuando se combinan.

Desde mi experiencia, la palabra “extremo” puede ser engañosa, pero la veo como una oportunidad para enfatizar la dificultad de los fundamentos detrás de ella. El punto crítico es darse cuenta de que nuestro “sentido común” no es tan “común” como tendemos a pensar, ni las mejores prácticas para el trabajo en equipo efectivo. Por lo tanto, esto se trata de llevarnos a la efectividad extrema, colaboración y satisfacción mientras trabajamos con otros.

Organizarás un evento en vivo en devm.io sobre el tema el 19 de enero. ¿Podrías darnos un adelanto de lo que tu audiencia puede esperar? #

Exploraremos cómo funciona un equipo de software hoy en día, los problemas comunes que encontramos y qué soluciones podríamos aplicar para mejorar las rutinas de nuestro equipo. Buscaremos el verdadero significado de Agile, enfocándonos en las ideas de Extreme Programming.

Además, compartiré algunas ideas para ayudar a tu equipo a crear oportunidades de aprendizaje con ejemplos concretos que cualquier equipo puede incorporar en su trabajo actual.

Durante el evento, también nos contarás algo sobre Katas. ¿Qué son exactamente las Katas? #

El término “kata” proviene de los movimientos repetitivos hechos en karate que te ayudan a mejorar tus habilidades de combate.

¿Por qué “katas de código”? Porque como grupo, necesitamos practicar más. La mayor parte de nuestro aprendizaje ocurre en el trabajo, por lo que la mayoría de nuestros errores también se cometen allí. Y porque queremos mantener PROD, somos reacios a probar cosas nuevas.

Las katas existen para ayudar a los desarrolladores a obtener los mismos beneficios que obtendrías de la práctica en cualquier otra profesión. Estos ejercicios simples de simulación te permiten experimentar y aprender sin la presión de PROD. No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Hay katas para ayudarte a mejorar tus habilidades de refactoring (como Gilded Rose Refactoring Kata de Emily Bache) o tus habilidades de testing (fáciles como Fizz Buzz o Roman Numerals, o más avanzadas como Bank Kata de Sandro Mancuso). También son geniales para construir confianza al programar con otros, observar y practicar diferentes roles colaborativamente, fomentar la cohesión del equipo, etc.

¿Qué papel juegan los métodos Agile en el desarrollo de software para ti? #

La primera pregunta aquí es definir qué son los métodos Agile. Al final, todos se comunican de alguna manera, dan retroalimentación a otros y simplifican hasta cierto nivel. A veces las personas tienen el coraje de decir lo que piensan y a veces no, y usualmente intentan respetar a sus compañeros. Así que, para mí, Agile es más sobre “cómo” haces ciertas cosas en lugar de “qué” cosas haces.

Agile es un proceso de trabajo altamente colaborativo a cualquier nivel, que podría tener una curva de aprendizaje desafiante al principio, pero vale la pena antes de lo que podrías esperar.

¿Qué tema en el área de agile debería recibir más atención? #

La construcción de equipos y abrazar la agilidad, empezando por preguntar “¿por qué?” Necesitamos desafiar el statu quo más a menudo y preguntarnos por qué trabajamos de la manera en que lo hacemos y cómo y qué podríamos hacer diferente para seguir mejorando y nunca dejar de aprender.

También puedes leer la entrevista desde el enlace original: https://devm.io/agile/extreme-programming-agile.

Artesanía Limpia

2022-07-11T00:00:00+00:00

El libro tiene tres partes: disciplinas, estándares y ética.

La primera es la más técnica. Te guía con ejemplos de TDD y muestra cómo el testing te ayuda a diseñar tu código.

La segunda trata sobre productividad, calidad y coraje.

La tercera explica cómo hemos llegado hasta aquí como profesionales del software y nuestra responsabilidad ética: no hacer daño, integridad y trabajo en equipo.

Una de mis partes favoritas del libro:

Nuestra industria es dinámica y cambia constantemente. Hay que aprender de forma continua y agresiva.

¿Cómo y cuándo aprendes? Si tu empresa te da tiempo para ello, aprovéchalo al máximo. Si no, tendrás que hacerlo por tu cuenta.

Prepárate para dedicar varias horas al mes. Reserva ese tiempo.

Sí, ya sé: familia, facturas, viajes, la vida. Pero también tienes una profesión. Y las profesiones requieren cuidado y mantenimiento. Aprendamos de forma continua y agresiva.

Capítulo 11. Coraje - Aprendizaje Agresivo Continuo

Índice #

Parte I: Las Disciplinas #

Capítulo 1. Artesanía #

Extreme Programming
Test-Driven Development
Refactoring
Diseño Simple
Programación Colaborativa
Tests de Aceptación

Capítulo 2. Test-Driven Development #

Visión General
Lo Básico

Capítulo 3. TDD Avanzado #

Quedarse Atascado
Arrange, Act, Assert
Test Doubles
Arquitectura

Capítulo 4. Diseño de Tests #

Testeando Bases de Datos
Testeando GUIs
Patrones de Test
Subclase Específica de Test
Humble Object
Diseño de Tests
Rompiendo la Correspondencia

Capítulo 5. Refactoring #

¿Qué es Refactoring?
El Kit Básico de Herramientas
Extract Method
Las Disciplinas

Capítulo 6. Diseño Simple #

YAGNI
Cubierto por Tests
Cobertura
¿Diseño?
Maximizar Expresión
La Abstracción Subyacente
Minimizar Duplicación
Minimizar Tamaño

Capítulo 7. Programación Colaborativa #

Capítulo 8. Tests de Aceptación #

La Disciplina
El Build Continuo

Parte II: Los Estándares #

Capítulo 9. Productividad #

Nunca Enviaremos M***da
Adaptabilidad Económica
Siempre Estaremos Listos
Productividad Estable

Capítulo 10. Calidad #

Mejora Continua
Competencia Sin Miedo
Calidad Extrema
No Volcaremos en QA
QA No Encontrará Nada
Automatización de Tests
Testing Automatizado e Interfaces de Usuario
Testeando la Interfaz de Usuario

Capítulo 11. Coraje #

Nos Cubrimos Mutuamente
Estimaciones Honestas
Debes Decir NO
Aprendizaje Agresivo Continuo
Mentoría

Parte III: La Ética #

El Primer Programador
Setenta y Cinco Años
Nerds y Salvadores
Modelos a Seguir y Villanos
Gobernamos el Mundo
Catástrofes
El Juramento

Capítulo 12. Daño #

Primero, No Hacer Daño
Mejor Trabajo
Prueba Repetible

Capítulo 13. Integridad #

Ciclos Pequeños
Mejora Implacable
Mantener Alta Productividad

Capítulo 14. Trabajo en Equipo #

Trabajar como Equipo
Estimar Honesta y Justamente
Respeto
Nunca Dejes de Aprender

Charla de Uncle Bob donde cubre la mayoría de los temas del libro.

Escucha sobre:
* Cita e Intro - [00:00:00]
* Trayectoria Profesional - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programador como Profesión - [00:15:31]
* Artesanía - [00:18:45]
* Disciplinas - [00:22:45]
* Disciplinas: Test-Driven Development - [00:28:49]
* Disciplinas: Refactoring - [00:34:31]
* Cobertura de Código - [00:39:02]
* Estándar: Nunca Enviar M***da - [00:42:35]
* Estándar: Siempre Estar Listo - [00:47:15]
* Ética: No Hacer Daño - [00:50:00]
* Ética: Estimar Honestamente - [00:53:56]
* 2 Sabiduría de Tech Lead - [00:57:50]

El Camino a la Seniority en Software

2022-06-08T00:00:00+00:00

Todos hemos sido desarrolladores junior en algún momento. Esto es fácil de saber porque es al principio de tu carrera. Tus responsabilidades fueron delimitadas por otros compañeros que cuidaban de ti.

En algún momento, después de meses o años, conseguiste tu promoción u otro trabajo, donde ya no eras junior, sino intermedio.

Un intermedio (también conocido como middle) es algo entre junior y senior. Ahora sabes que ya no eres junior, sabes cómo entregar valor pero aún tienes sentimientos encontrados sobre la seniority. Quieres ser senior, pero no sabes cómo. No hay un camino claro para alcanzar este objetivo.

Espera un segundo… ¡en realidad hay dos formas fáciles de conseguir el título de senior! Puedes ser promovido como tal en tu empresa, o puedes empezar una nueva posición como “senior” en otra empresa, ¿fácil no?

Marketing y política #

Desafortunadamente, el nivel de “seniority” está muy contaminado por marketing y política. Primero, ¿qué significa “senior” en este contexto? En todas las empresas donde he trabajado (si no todas) siempre he estado rodeado de personas que afirmaban ser “seniors” cuando en realidad solo a unos pocos los consideraría como tales.

La etiqueta de senior está inflada por la necesidad de las empresas de tener expertos en papel más que en la realidad, y es un problema con el que debemos lidiar y del que debemos hablar.

Seniority generalmente significa más experiencia, pero ¿cómo calculas esto? Es fácil desde el punto de vista de una empresa: más años en la industria. Pero, ¿es realmente relevante el número de años que has estado trabajando en una industria que está en constante cambio y evolución? En realidad, esto no sería un gran problema si tienes los fundamentos del software bien interiorizados, pero curiosamente, he visto estos fundamentos solo en ~10% de los seniors que he conocido a lo largo de muchos años y varias empresas.

El hecho de que hayas estado trabajando durante 10 o más años no significa necesariamente que seas un “senior” con el software. ¿Qué más podemos medir para identificar si realmente mereces este título?

No todo se trata del dinero #

Seamos honestos, los títulos senior están mejor pagados que las posiciones junior o middle. Si tienes la oportunidad de conseguir un salario más alto porque tienes “senior” en tu título de trabajo, bueno, no sería inteligente rechazarlo. Pero, independientemente de la política y el marketing, debemos abordar algunos fundamentos de seniority para entender mejor qué significa la palabra “senior” en este contexto.

No todo se trata del dinero, sino también de las responsabilidades que vienen con la seniority.

Fundamentos de la seniority #

Ser senior en nuestra industria del software no se trata del “número de años de experiencia” sino:

¿Qué tan bien transmites tu conocimiento a otros? Compartir lo que sabes es una tarea esencial para una persona senior.
¿Qué tan bien colaboras con otras personas, incluyendo al PM/PO y a otros equipos? La colaboración es crucial para crear un bucle de retroalimentación constante.
¿Qué tan bien trabajas en conjunto con tus compañeros? El pair-programming fomenta la cohesión del equipo y ayuda a que todos mejoren.
¿Qué tan fuertes son tus habilidades de testing? El testing está ligado a la calidad de tu trabajo, y un senior debería apuntar a un diseño incremental.
¿Qué tan bien entiendes entregar valor constantemente en pequeñas partes? Cuanto antes entregues valor, antes obtendrás retroalimentación sobre ello.
¿Qué tan profundo es tu conocimiento técnico sobre software de calidad y los trade-offs para llegar allí? Principios SOLID, código limpio, TDD, refactoring como parte de tu trabajo diario, bajo acoplamiento, alta cohesión, estructuras de datos apropiadas y elegir la solución correcta (KISS, YAGNI…).
¿Qué tan bien te adaptas y lidias con el cambio? El cambio es inevitable, así que debemos aprender a gestionarlo, especialmente lo que no podemos controlar.
¿Qué tan desarrollado está tu pensamiento emprendedor? Siempre manteniendo los objetivos de la organización en mente.

Como puedes ver, no hay mención de tecnología concreta o años de experiencia. ¿Por qué? Porque la tecnología es solo un “detalle de implementación”, y la experiencia viene de practicar y la actitud, no de dejar pasar el tiempo.

La actitud es importante #

Tenemos dos personas:

A) una persona que trabaja desde hace 15 años, haciendo relativamente lo mismo cada día, y sin preocuparse por sus propias habilidades. Simplemente hace lo que otros le dicen que haga.

B) una persona que trabaja desde hace 5 años, desafiándose a sí misma cada semana, probando diferentes enfoques al lidiar con problemas, y afilando sus propias habilidades constantemente.

¿Puedes ver la diferencia principal? No, no son los 10 años de diferencia de “experiencia” entre ellos, sino su actitud.

Entendemos erróneamente que un año de experiencia debe venir con aprendizaje y conocimiento, así que tendemos a usar el tiempo como medida de seniority. Pero argumento que el “factor actitud” es igual o incluso más importante. He estado rodeado de muchas personas que se llaman a sí mismas seniors con 3, 6, 10 y más años de “experiencia” pero sin actitud, y podías ver claramente este problema a diario.

Necesitas esta combinación para construirte como un desarrollador verdaderamente senior; tiempo, experiencia, y lo más importante: actitud hacia mejorar tus propias habilidades y las de quienes te rodean.

Por dónde empezar #

La seniority no se concede, se practica. No esperas el título, construyes el comportamiento hasta que el título te alcanza. Empieza pequeño, y empieza ahora:

Enseña lo que sabes. Elige una cosa que entiendas y explícasela a alguien esta semana. Si no puedes explicarla, aún no la dominas.
Busca lo incómodo. Ofrécete para la tarea que te queda algo grande. El crecimiento vive en el borde de lo que ya sabes hacer.
Reflexiona con intención. Después de cada proyecto, pregúntate qué harías diferente. Experiencia sin reflexión es solo repetición.

El camino no es una promoción. Es la decisión diaria de mejorarte a ti mismo y a quienes te rodean. Hazlo el tiempo suficiente, y el título se vuelve un trámite.

Actualiza tu Equipo para Ser Más Extreme

2022-02-26T00:00:00+00:00

Nuestra profesión del software está en constante evolución y exige aprendizaje continuo. El cambio no es opcional en nuestra industria.

Hay que crear espacios para salir de nuestra zona de confort. Nuestro cerebro necesita entrenarse para adaptarse a un entorno que cambia constantemente.

¿Por qué katas de código, charlas técnicas o viernes de investigación? #

El objetivo es crear un ambiente que fomente la mejora continua. Buscar aprender en todas partes, todo el tiempo, como actitud central para cada persona y para el equipo.

Crear oportunidades de aprendizaje #

Programa tiempo cada X semanas para practicar juntos.

Al final de cada iteración, o cada 2-4 semanas, trabajamos en katas en parejas o mob durante 2 horas. Ese espacio también sirve para preparar charlas técnicas internas y compartir conocimiento interesante que no sea del “negocio diario”.

El objetivo es salir de nuestra zona de confort. Mejorar nuestra capacidad de adaptación mientras aprendemos otros temas.

¿Qué es una kata de código? #

Los desarrolladores no practicamos lo suficiente. La mayor parte del aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de errores.

El término “kata” viene del karate: movimientos repetitivos que mejoran tus habilidades de combate.

Las katas de código dan a los desarrolladores los mismos beneficios que practicar en cualquier profesión. Son ejercicios simples que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en una kata: el beneficio viene del proceso, no del resultado.

Motivación #

Practicar técnicas de refactoring.
Practicar TDD.
Aplicar principios SOLID.
Hacer sesiones de live coding.
Ejercitar el concepto driver-navigator.
Mejorar la cohesión del equipo.
Pasarlo bien mientras aprendes con otros.

Si te interesa mi visión sobre TDD y katas, escribí un post hace poco: Test-Driven Development.

¿Qué es una charla técnica? #

Las charlas técnicas nos permiten compartir conocimiento de nuestra industria con el equipo.

Puede ser sobre FrontEnd, BackEnd, DevOps. Pero también animo a compartir:

un nuevo lenguaje que estás aprendiendo,
un resumen de un libro que terminaste,
una tecnología que te da curiosidad,
un software que te gustaría presentar,
una herramienta que mejora tu productividad,
en realidad: cualquier cosa que aporte valor o conocimiento.

¿Cómo presento una charla técnica? #

Escribí un artículo con consejos sobre cómo mejorar tu charla técnica. Algunas preguntas que pueden ayudarte:

¿Qué has aprendido recientemente?
¿Qué conocimiento sería interesante compartir con tus compañeros?
¿Qué aspecto de ti te gustaría mejorar profesional o personalmente?

Una sola regla: sé curioso y “abraza el cambio.”

Viernes de investigación y aprendizaje #

Reserva el último viernes del mes para investigar y aprender. Todo el equipo tendrá un espacio dedicado al crecimiento y la experimentación.

Es clave construir confianza con tu equipo. Que todos sepan que cada uno usará este tiempo bien. No microgestiones forzando un registro detallado en una wiki.

Eso sí, estaría bien que el equipo comparta lo que hace. Crea transparencia. Un anuncio verbal el día antes con las intenciones, y el día después con los aprendizajes clave.

Resumen #

Puedes ayudar a tu equipo a ser más extreme creando un espacio dedicado al crecimiento y la experimentación.

Da flexibilidad para experimentar con estas ideas.
Es una oportunidad para crecer y aprender a la vez.
La responsabilidad es de cada persona y del equipo.

No microgestiones este tiempo. Enfócate en el resultado. Ayuda a tu equipo a crecer, y disfrutarán creciendo contigo.

Charla Técnica #

Tras escribir este post (originalmente en febrero de 2022), me invitaron a dar una charla técnica sobre este tema en varias conferencias.

London vs Chicago

2021-11-20T00:00:00+00:00

Hay dos escuelas conocidas en TDD: la escuela mockista (también conocida como Outside-in) y la escuela clasicista (también conocida como Inside-out).

¿Por qué London y Chicago? #

Dos empresas, una de Londres y otra de Chicago, afirmaban hacer TDD pero con enfoques diferentes. La de Londres construía software de afuera hacia adentro; la de Chicago, de adentro hacia afuera. Veamos cada una.

Outside-in: Escuela de Londres #

Un enfoque guiado por comportamiento para TDD. Empiezas desde el exterior de la aplicación y vas hacia adentro, bajando a capas inferiores. Por ejemplo, desde la API/Controladores hacia las capas de aplicación o dominio.

PROS #

Enfocado en Comportamiento: requiere muchos dobles de test porque testeas abstracciones que aún no existen (creas lógica de alto nivel primero). No escribirás código muerto, pero es fácil crear tests muy acoplados a la lógica, lo que dificulta el refactoring.
Separación Comando-Consulta: es una disciplina para gestionar efectos secundarios. O realizas una acción (comando) o pides un valor (consulta).

CONTRAS #

Tests Frágiles: tiende a crear tests que se rompen fácilmente porque suelen estar muy acoplados al código de producción.
Refactoring Difícil: por la misma razón, tener tests acoplados hace que el refactoring continuo sea lento y complicado.

Inside-out: Escuela de Chicago #

Un enfoque informal, exploratorio, basado en estado. Empiezas desde el interior de la aplicación (normalmente el dominio) y vas hacia afuera, hacia las APIs.

PROS #

Red de Seguridad Fuerte: produce tests desacoplados de la implementación. Puedes cambiar el software sin miedo a romperlo, ideal para el refactoring continuo.
Alta Cohesión: a medida que los tests se vuelven más generales, el código de producción se vuelve más específico. Alta cohesión lleva a bajo acoplamiento, lo que mejora extensibilidad, mantenibilidad y testeabilidad.
Minimiza Dobles de Test: construir de adentro hacia afuera requiere menos dobles porque construyes sobre tests previamente escritos. Esto ayuda a tener tests menos frágiles.

CONTRAS #

YAGNI: a menudo sobre-diseña soluciones, con código que realmente no se necesita (¡o ni siquiera se usa!) al final.

Londres y Chicago funcionan mejor juntas #

No se trata de elegir uno u otro. Se trata de entender tu contexto y optimizar las cualidades que lo necesitan. London y Chicago tienen sus pros y contras. El mejor enfoque para TDD es integrar ambas escuelas.

Referencias #

TDD vs BDD

2021-09-25T00:00:00+00:00

Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.

BDD es una “funcionalidad guiada por tests” #

Básicamente, es un desarrollo test-first, donde el enfoque principal es asegurar el comportamiento final esperado, y por lo tanto el resultado de la lógica de software que quieres tener al final.

En BDD el enfoque principal es el comportamiento de tu lógica de dominio que aún no existe. Es, desde un punto de vista abstracto, sobre toda la funcionalidad y los requisitos del dominio.

TDD es sobre el ritmo #

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

TDD no es solo la ya conocida mentalidad “red-green-refactor”, sino principalmente sobre el flujo de trabajo que te ayuda a entender las constantes decisiones de diseño que haces cada vez para cada lógica que estás diseñando.

TDD es sobre retroalimentación constante de tus decisiones.

En el contexto de OOP (para hacer los ejemplos más claros), siempre hay toneladas de formas diferentes de diseñar tu clase:

¿Cuál es el nombre de la clase de este método?
¿Cuáles son las dependencias o colaboradores de esta clase?
¿Cómo se comportará esta clase cuando use esta otra clase dentro de ella?
¿Cuál es el resultado esperado de este método cuando le doy estos argumentos?
etc, etc…

Hacemos estas preguntas (y muchas más) cada vez, y también les damos una respuesta, pero normalmente sin ningún pensamiento racional o reflexión sobre ello. Simplemente hacemos lo que creemos que es “lo mejor” en ese momento particular enfocándonos en hacer que algo funcione, pero ¿es suficiente hacerlo funcionar?

El bucle de retroalimentación constante #

El testing no es solo una gran herramienta porque te da una red de seguridad para refactorizar con confianza, sino también porque ayuda a diseñar mejor el sistema. ¿Cómo es eso? Porque antes de implementar cualquier solución, te obliga a pensar en las decisiones que necesitas tomar. Te desafías a ti mismo para entender los argumentos de tus decisiones, y por qué A y no B es mejor solución en un contexto particular.

BDD y TDD no son mutuamente excluyentes, de hecho, pueden y deben coexistir. Depende principalmente del contexto de lo que quieres construir y testear.

BDD es sobre desarrollo de funcionalidades Test-First. El objetivo no es el cómo sino el qué. El bucle de retroalimentación es largo porque obtendrás el “verde” una vez que la funcionalidad esté implementada y funcionando como se esperaba.

TDD también es otro desarrollo guiado por Test-First pero, a diferencia de BDD, se trata de un bucle de retroalimentación más corto y rápido.

Primero, especificas lo que quieres. Piensas sobre el diseño de tu clase o método. Su nombre o firma. Sus dependencias. Pero todo esto con pequeños pasos, uno a la vez.
Segundo, haces que esa pequeña cosa funcione de la manera más simple posible.
Finalmente, lo haces mejor. Porque el software es lo suficientemente difícil y complicado como para hacerlo bien al primer intento, así que el refactoring es imprescindible para mantener un sistema saludable. En este punto, con un “test verde ejecutándose”, puedes refactorizar y mejorar tu lógica de forma segura.

Lo anterior es básicamente TDD, cierto, pero… ¿qué tiene de especial? El bucle de retroalimentación constante y las decisiones de diseño que necesitas tomar antes de escribir realmente la solución. Este es el poder de TDD.

¿Por qué pasos tan pequeños en TDD? #

Teóricamente “debes” escribir pequeños pasos para cada iteración, pero ¿por qué? Se trata del bucle de retroalimentación. Esto depende de ti, tus expectativas y tu experiencia con testing.

Recursos #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

La complejidad aquí no está en escribir tests en sí, sino en los hábitos que tenemos que cambiar para crear software que sea fácil de testear.

La raíz del problema #

Sin experiencia sólida en testing, los desarrolladores lo pasan mal al intentar aplicar tests en su trabajo diario. No es solo por la complejidad del tema, sino porque están acostumbrados a escribir código difícil de testear.

Escribir tests para software que ya funciona (sobre todo cuando se hizo sin pensar en testing) se siente aburrido y casi inútil. Viene acompañado de falta de motivación, culpando al sujeto equivocado: “los tests me hacen ir más lento”.

En un contexto de dominio, si una pieza de lógica de software es difícil de testear, el problema no es el test, sino el código que no estaba bien escrito.

Ya hay cientos de tutoriales, libros y documentación sobre testing. Aquí comparto mi experiencia y cómo aplico esta filosofía en mi trabajo diario.

Test-Driven se basa en esta simple regla #

En lugar de: diseñar código -> desarrollar código -> escribir tests.

Se trata de: escribir test automatizado que falla -> ejecutar test que falla -> desarrollar código para hacer pasar el test -> ejecutar test -> repetir.

La idea de guiar tu código con tests depende del nivel de abstracción de lo que estés escribiendo. No quieres acoplar mal los tests con el código testeado. Quieres testear el comportamiento de tu lógica.

TDD se basa en un bucle de pequeños pasos que te ayuda a encontrar patrones y guiar tu diseño de software con refactorizaciones constantes. Es la mejor opción si quieres asegurar el comportamiento esperado de todos los caminos posibles de tu lógica.

Lo bonito es que no necesitas conocer el algoritmo completo desde el principio. Vas descubriendo cómo debería ser tu lógica expresando la implementación deseada, paso a paso, en tests automatizados.

Escribir tests al mismo tiempo que escribes el código te obliga a escribir mejor software. Porque quieres que sea fácil de testear, y eso lleva a mayor calidad.

Ya escribí otro post sobre la relación entre calidad y testing del software: El Arte del Testing: donde el diseño se encuentra con la calidad.

Mejora tus habilidades de Test-Driven #

La mejor manera de aprender Test-Driven es haciendo katas de software. Pruébalas solo y con otros. Ambas son igualmente importantes.

Solo: para desafiar tu yo interior sin ninguna distracción excepto tú mismo.
Con otros: el pair-programming es esencial en nuestro trabajo. Las katas son las mejores herramientas para entrenar nuestras habilidades de comunicación y aprender juntos unos de otros.

¿Qué es una Code Kata? #

Los desarrolladores no practicamos lo suficiente. La mayor parte de nuestro aprendizaje ocurre en el trabajo, y ahí es donde cometemos la mayoría de nuestros errores.

Otras profesiones creativas sí practican: los músicos tocan piezas técnicas, los poetas reescriben obras constantemente. En karate, un estudiante dedica la mayor parte del tiempo a aprender y perfeccionar movimientos básicos. Esas son las katas.

¿Cuál es el objetivo de una kata? ¿Qué deberíamos tener al final? #

Las katas existen para que los desarrolladores obtengamos los mismos beneficios que practicar en otras profesiones. Son ejercicios simples y artificiales que permiten experimentar y aprender sin la presión de producción.

No hay respuestas correctas o incorrectas en ninguna kata de software: el beneficio viene del proceso, no del resultado.

Consejos #

Cuando resuelvas una kata, vuelve a intentarla en unas semanas o meses.
Explora nuevas soluciones. Sé creativo y no te apresures.
En grupo, no es una competición para ver quién logra más.
El foco debe estar en el proceso, nunca en el resultado.
El verdadero valor de cualquier kata son los aprendizajes que obtendréis después de hablar y compartir experiencias.

Puedes encontrar muchas katas en Internet. Por ejemplo:

TDD es más un flujo de trabajo que un diseño #

“TDD es una herramienta de diseño.” Eso es lo que Sandro dijo durante años. Pero ya no. Tras trabajar con diferentes equipos y organizaciones, y observar cómo trabaja él mismo, Sandro cambió de opinión sobre el rol de TDD en el diseño de software.

TDD en pocas palabras; se trata del ritmo.

Especifica lo que quieres.
Hazlo funcionar.
Hazlo mejor.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Imágenes originales de Emmanuel Valverde Ramos.

Mockear o No Mockear

2021-01-11T00:00:00+00:00

Mockear es útil, pero “qué mockear” suele resultar más complicado de lo esperado si no tratas esto con cuidado.

Cómo escapar del infierno del mocking #

¿Qué pasa realmente cuando creamos un mock? ¿Qué tipos hay? ¿Es bueno o malo mockear? Como siempre, depende del contexto. Aquí veremos las situaciones principales: cuándo mockear, cuándo no hacerlo, y sobre todo por qué.

¿Qué pasa cuando mockeas algo? #

Primero, deberíamos definir qué es un mock:

En un test unitario, los objetos mock pueden simular el comportamiento de objetos reales complejos y por lo tanto son útiles cuando es impracticable o imposible incorporar un objeto real en un test unitario.

Mockear tiene sentido en testing unitario. Un test de integración pasa por la implementación real, verificando cómo interactúan varias unidades. Estos tests sí pueden hablar con la BD o el sistema de archivos. Partimos de esta base: un test unitario es rápido, determinista, no depende de recursos externos y no requiere contexto especial para ejecutarse.

Los mocks cumplen el contrato de la interfaz. Nos permiten testear funcionalidad sin invocar clases colaboradoras complejas.

Un mock es un doble de test que sustituye la implementación real. Además, puede verificar cómo el código bajo test lo utilizó durante la ejecución.

Recomiendo encarecidamente que leas este post si quieres entrar en los detalles de por qué Mockear es un code smell (Temas como estos: ¿Qué es un mock? ¿Qué es un test unitario? ¿Qué es la cobertura de tests? ¿Qué es el acoplamiento fuerte? ¿Qué causa el acoplamiento fuerte? ¿Qué tiene que ver la composición con el mocking? ¿Cómo eliminamos el acoplamiento? ¡y más!)

El problema con mockear #

Cuando mockeas, anulas la lógica de la clase mockeada. La lógica real queda oculta, y ahí es donde los bugs se esconden. Ten en cuenta que:

El mock puede tener atributos, métodos o argumentos que el objeto real no tiene.
Los valores de retorno del mock pueden diferir de los reales. Por ejemplo, puede devolver un tipo distinto con atributos diferentes.
Los efectos secundarios y comportamiento del mock pueden diferir del objeto real. Quizás el mock no lanza una excepción que el objeto real sí lanzaría.

Alternativas a mockear #

“¿Estás diciendo que mockear es malo y no deberíamos mockear?” No.

Depende de lo que estés “anulando”.

¿Es tu lógica de dominio de negocio lo que estás mockeando? Entonces está mal.
¿Es la conexión a la BD lo que estás mockeando? Entonces está bien.

Depende del contexto de la lógica y dónde pertenece esa lógica.

¿Es parte de tu lógica de dominio de negocio? Entonces no deberías mockearla sino instanciarla.

¿Es una dependencia de infraestructura como conexión a BD, sistema de archivos, red, o cualquier servicio externo que no tiene que ver con tu dominio de negocio? Entonces mockéala usando abstracciones/interfaces.

La interfaz es el contrato entre tu lógica de dominio y sus dependencias de infraestructura. Imagina lo fácil que es testear tu dominio instanciándolo y llamando a sus métodos con diferentes argumentos, todo bajo tu control total.

Algunos trucos #

Cuando estés escribiendo un test unitario:

Intenta instanciar tus clases primero.
Evita mockear clases concretas. Escribí un artículo exclusivamente sobre esto: fomentando clases finales e interfaces.

Mockea interfaces. Instancia clases concretas.

“El uso excesivo de mocks lleva a código legacy.” - Philippe Boargau

¿Cómo podemos evitar el mocking excesivo? #

Favorece el estado inmutable sobre el estado mutable.
Haz las dependencias explícitas.
Programa hacia una interfaz, no hacia una implementación.

Referencias #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Testeando Código Legacy de Forma Efectiva

2020-08-17T00:00:00+00:00

Estos tests también se conocen como tests de caracterización.

Un test de caracterización describe el comportamiento real de una pieza de software existente, y por lo tanto protege el comportamiento existente del código legacy contra cambios no intencionados mediante testing automatizado. Este término fue acuñado por Michael Feathers.

Permiten y proporcionan una red de seguridad para extender y refactorizar código que no tiene tests adecuados. Se puede escribir un test que afirme que la salida del código legacy coincide con el resultado observado para las entradas dadas.

¿Cómo empezar? #

Estos son mis aprendizajes un año después de leer Working Effectively with Legacy Code y aplicarlo a los diferentes proyectos en los que he trabajado desde entonces.

1. ¿Qué quieres testear? #

Averigua las aserciones. Crea un archivo de test para tu clase, y un método de test para la función que quieres testear. Pista:

Si tienes el siguiente método applySomeLogic(): ReturnType,
el test que podrías escribir es test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // caja negra responsable de crear un ReturnType
 // basado en el Input dado
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // Quiero afirmar que "aplicando alguna lógica"
 // de MyBusinessLogic con el Input dado
 // recibiré un ReturnType concreto con un
 // cierto valor como su propiedad. Algo como:

 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instancia la clase concreta/final que quieres testear. #

No mockees tus clases concretas. Especialmente tu dominio de negocio. Mockea solo interfaces. De lo contrario, puedes estar ocultando bugs sin querer (¡con tests verdes/pasando!). Trata tus clases de dominio de negocio como finales.

O mockea la interfaz o instancia una clase anónima si quieres crear un Stub:

Los Stubs proporcionan respuestas a llamadas hechas durante el test, normalmente sin responder a nada fuera de lo programado para el test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // O
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Donde FakeDependency es una implementación concreta de DependencyInterface con “datos/implementación falsos” ya preparados que solo es útil para propósitos de testing.

3. Llama al método de esa clase proporcionando la entrada deseada. #

La salida será determinada por el estado inicial de la clase de lógica de negocio que queremos testear MÁS los argumentos de entrada que estamos usando.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Afirma la salida con el valor esperado. #

Del paso 1 necesitas saber qué quieres. Aplica la(s) aserción(es) ahora.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. Puede que quieras afirmar diferentes valores esperados. #

Puedes proporcionar fácilmente diferentes argumentos a tu lógica de negocio ya sea a través de la construcción de la lógica o diferentes argumentos dados. Para hacerlo, usa la anotación @dataProvider. El método “dataProvider” debe ser público y devolver cualquier iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Por último: limpia lo que hiciste. #

Sí, limpia los tests. Merecen estar tan limpios como tu código de producción. De lo contrario, se pudrirán con el tiempo y ¡permanecerán sucios para tus compañeros y tu yo futuro!

Por ejemplo, puedes aplicar el refactoring extract method para mover los detalles de implementación (de la creación de los diferentes objetos) y mantener el mismo nivel de abstracción mientras lees el código del test.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Por supuesto, todo depende del contexto. ¿Realmente tiene sentido extraer a un método privado createBusinessLogic() o incluso createInput()? Bueno, eso depende de ti. Depende del número de líneas y, lo más importante, del nivel de abstracción que pertenece a ese contexto.

Solo recuerda: mantén tus métodos pequeños.

Ahora puedes refactorizar el código de producción que cubriste con tests sin ese miedo a romperlo.

Todo junto #

El código legacy es código sin tests #

Por supuesto, hay mucho más que aprender sobre testing y trabajo con código legacy. De hecho, especialmente cuando tratamos con código legacy, encontrarás situaciones donde el código está acoplado de alguna manera que podrías querer mockear tus clases concretas porque no hay interfaz (todavía) para ello.

Este libro te presenta muchas técnicas sobre cuándo, por qué, dónde y cómo puedes aplicar estos cambios.

Cuando trabajas con código necesitas retroalimentación. La retroalimentación automatizada es la mejor. Por lo tanto, esto es lo primero que necesitas hacer: escribir los tests.

Primero, añade tests, luego haz tus cambios. #

Cambia la menor cantidad de código posible para poner los tests en su lugar con la receta: #

Identifica “puntos de cambio” para romper las dependencias de tu código.
Rompe las dependencias.
Escribe los tests.
Haz tus cambios.
Refactoriza.

El Arte del Testing: Donde el Diseño se Encuentra con la Calidad

2020-04-07T00:00:00+00:00

¿Por qué considerar el testing parte de tu desarrollo diario? Porque está directamente vinculado a la calidad del software.

No voy a explicar las diferentes técnicas de testing ni las diferencias entre tests unitarios, de integración, funcionales o end-to-end.

Me sigue sorprendiendo la falta de experiencia con testing en el mundo del software. Hay una ignorancia generalizada sobre buenas prácticas. Si has trabajado en varios proyectos y equipos, seguro que lo has visto.

Testing de software #

Algunos patrones horribles que he visto (y hecho):

Testear por testear: testear cada archivo individual, confundiéndolo con una “unidad”.
Mockear cada clase, anulando la implementación real y creando comportamiento falso. Esto da una falsa sensación de cobertura.
Acoplar código de producción con tests por todas partes. Imposible cambiar nada sin romper tests, aunque la funcionalidad siga funcionando.
No testear nada porque “ya funciona, ¿para qué perder más tiempo?”

Una razón principal del testing es verificar el comportamiento esperado del software. Pero el testing puede (y debería) ser mucho más que eso.

Diseño de software #

El diseño de software abarca desde algoritmos hasta arquitectura. Aunque estos dos niveles tienen necesidades distintas, comparten patrones comunes. Por ejemplo, el testing:

Si es fácil de testear, probablemente será debido a un buen diseño.

Calidad del software #

Medir la calidad es difícil. Hay muchas métricas a considerar. Aun así, seguro que podemos estar de acuerdo en esto:

Si aspiras a la calidad en tu software, mejor busca un buen diseño.

Testear significa “probar”. ¿Cuántas veces hemos abandonado tests por la complejidad de probar cierta lógica?

El arte del testing consiste en usar los tests para contribuir al resultado final. Si usamos el testing a nuestro favor, según el contexto, mejoraremos la calidad del producto.

Por tanto, el testing no solo verifica comportamiento. También guía el software hacia un mejor diseño.

¿Deberíamos testear todo? Depende del contexto. Habrá situaciones donde los tests no aporten beneficio. Aun así, escribe código como si fuera a ser testeado.

El código testeable tiende a un mejor diseño y, por lo tanto, a mejor calidad.

Agile Limpio

2020-03-12T00:00:00+00:00

Clean Agile viene de Uncle Bob, uno de los padres fundadores de Agile. Fue una de las diecisiete personas que escribieron el Manifiesto Ágil en 2001.

El libro trata sobre Agile: lo que fue, lo que es y lo que será. Es un regreso a lo básico que cubre la historia de Agile, qué lo motivó y qué ha pasado desde entonces. Cubre las prácticas básicas y las compara con la variedad actual de procesos ágiles.

Programación Extrema Explicada

2020-03-05T00:00:00+00:00

Definición #

Extreme Programming (XP) es un framework ágil que busca producir mejor software y mejor calidad de vida para el equipo de desarrollo. Es el más específico de los frameworks ágiles en cuanto a prácticas de ingeniería.

Valores #

Los cinco valores de XP son comunicación, simplicidad, feedback, coraje y respeto.

Comunicación #

El desarrollo de software es un deporte de equipo. Depende de la comunicación para transferir conocimiento entre los miembros. XP enfatiza la comunicación cara a cara, preferiblemente con una pizarra a mano.

Simplicidad #

Simplicidad significa “¿qué es lo más simple que funcionará?” El objetivo es evitar el desperdicio y hacer solo lo necesario. Mantener el diseño lo más simple posible facilita el mantenimiento y la revisión. También significa abordar solo los requisitos que conoces ahora, sin intentar predecir el futuro.

Feedback #

Con feedback constante sobre el trabajo previo, los equipos identifican áreas de mejora y ajustan sus prácticas. El equipo construye algo, recoge feedback sobre el diseño e implementación, y ajusta el producto en consecuencia.

Coraje #

Kent Beck definió el coraje como “acción efectiva ante el miedo”. Necesitas coraje para:

Plantear problemas organizacionales que reducen la efectividad del equipo.
Dejar de hacer algo que no funciona y probar algo diferente.
Aceptar y actuar según el feedback, aunque sea difícil de escuchar.

Respeto #

Los miembros del equipo necesitan respetarse mutuamente para comunicarse bien, dar y recibir feedback de forma constructiva, y trabajar juntos en diseños y soluciones simples.

Principios #

Humanidad #

Los seres humanos desarrollan software. El libro menciona 5 cosas que necesitan los desarrolladores para crecer: seguridad básica, logro, pertenencia, crecimiento e intimidad.

La magia de los grandes equipos es que, una vez que desarrollan confianza, sus miembros se sienten libres de ser más ellos mismos.

Economía #

El software cuesta dinero. Alguien pagó o invirtió en él.

Asegúrate de que lo que haces tenga valor de negocio y sirva a sus necesidades. Resolver primero la necesidad más prioritaria maximiza el valor del proyecto.

Cuanto antes el software genere dinero, antes el desarrollo será valioso.

Beneficio Mutuo #

El beneficio mutuo en XP busca actividades que beneficien a todos los involucrados: a mí ahora, a mí después, y a los clientes.

El libro presenta 3 formas de comunicarte con el futuro:

Escribo tests automatizados que me ayudan a diseñar e implementar hoy. Los dejo para que los futuros programadores también los usen.
Refactorizo para eliminar complejidad accidental. Menos defectos y código más fácil de entender para quien venga después.
Elijo nombres de un conjunto coherente de metáforas. Acelera mi desarrollo y hace el código más claro para nuevos programadores.

Auto-Similaridad #

Copiar la estructura de una solución a un nuevo contexto.

Por ejemplo, la estructura básica del desarrollo: escribes un test que falla y luego lo haces funcionar. Esta estructura opera a todas las escalas. Ojo: es un buen comienzo, pero no siempre funciona.

Mejora #

Haz lo mejor que puedas hoy, pero esfuérzate por hacerlo mejor mañana. XP brilla aquí: se trata de mejorar siempre.

Pon la mejora a trabajar sin esperar la perfección. Encuentra un punto de partida, comienza y mejora desde ahí.

Diversidad #

Los equipos necesitan personas de diferentes orígenes, experiencias y actitudes. Así tienen diferentes formas de pensar y resolver problemas.

Los programadores deberían trabajar juntos en el problema y valorar ambas opiniones.

Reflexión #

Los buenos equipos reflexionan después de la acción, regularmente. Piensan sobre por qué y cómo están trabajando.

¿Por qué tuvimos éxito? ¿Qué deberíamos seguir haciendo?
¿Por qué fallamos? ¿Qué podemos hacer mejor?

Aunque todo parezca perfecto, siempre hay espacio para mejorar:

¿Por qué las cosas parecen perfectas? ¿Qué hacemos bien? ¿Qué podemos mejorar?

Flujo #

El flujo en desarrollo de software es entregar valor constante participando en todas las actividades simultáneamente. No entregues software en grandes porciones. Despliega incrementos más pequeños con más frecuencia.

Oportunidad #

Aprende a ver los problemas como oportunidades para aprender y mejorar.

Parte de ser extremo es elegir conscientemente transformar cada problema en una oportunidad: para el crecimiento personal, profundizar relaciones y mejorar el software.

Redundancia #

Los problemas difíciles deberían resolverse de múltiples maneras.

El costo de la redundancia se paga con creces por los ahorros de evitar un desastre.

Fracaso #

A veces no sabes qué camino tomar. Prueba las ideas que tienes, aunque fallen. El fracaso no es desperdicio, sino aprendizaje.

Cuidado con la trampa de discutir o pensar eternamente sin hacer nada.

Cuando no sabes qué hacer, arriesgarte al fracaso puede ser el camino más corto hacia el éxito.

Calidad #

Los proyectos no van más rápido bajando la calidad. Suele ser al revés. Resulta en entregas más tardías y menos predecibles por el tiempo dedicado a corregir bugs.

Aumentar la calidad suele resultar en entregas más rápidas.

La preocupación por la calidad no es excusa para la inacción. Si no conoces una forma limpia de hacer algo que hay que hacer, hazlo lo mejor que puedas. Si conoces una forma limpia pero tomaría demasiado tiempo, haz el trabajo tan bien como el tiempo te permita. Resuélvelo de forma limpia después.

Pasos Pequeños #

Da pasos pequeños. Hacer grandes cambios de golpe es peligroso. Las personas y equipos pueden dar muchos pasos pequeños y parecer que avanzan rápido.

Los pasos pequeños reconocen que su sobrecarga es mucho menor que cuando un equipo retrocede desperdiciando cambios grandes abortados.

Responsabilidad Aceptada #

La responsabilidad no puede asignarse; solo puede aceptarse. Si alguien intenta darte responsabilidad, solo tú puedes decidir si la aceptas o no.

Prácticas #

Se pueden hacer de forma aislada, pero muchos equipos han descubierto que algunas prácticas refuerzan a otras. Hacerlas juntas elimina los riesgos típicos del desarrollo de software.

Sentarse Juntos #

La comunicación es uno de los cinco valores de XP. Haz que tu equipo se siente junto en el mismo espacio sin barreras como paredes de cubículos.

Equipo Completo #

Incluye personas con todas las habilidades y perspectivas necesarias para que el proyecto tenga éxito.

Espacio de Trabajo Informativo #

Configura el espacio para facilitar la comunicación cara a cara, permite algo de privacidad cuando la necesiten, y haz el trabajo transparente para el equipo y las partes interesadas.

Trabajo Energizado #

Eres más efectivo en el desarrollo de software cuando estás enfocado y libre de distracciones.

Programación en Parejas #

Todo el software de producción lo desarrollan dos personas en la misma máquina. Dos cerebros y cuatro ojos son mejores que un cerebro y dos ojos. Obtienes revisión de código continua y respuestas más rápidas a problemas que podrían bloquear a una persona sola.

Los equipos que usan programación en parejas descubren que mejora la calidad sin tomar el doble de tiempo. Resuelven problemas más rápido y se mantienen más enfocados, escribiendo menos código para lograr lo mismo.

Los programadores en pareja:

Se mantienen mutuamente en la tarea.
Hacen lluvia de ideas sobre mejoras al sistema.
Clarifican ideas.
Toman la iniciativa cuando el compañero está atascado, reduciendo la frustración.
Se hacen mutuamente responsables de las prácticas del equipo.

La programación en parejas es un diálogo entre dos personas programando simultáneamente (analizando, diseñando y probando) e intentando programar mejor.

Si necesitas privacidad y tiempo para trabajar en una idea, adelante. Necesitamos tanto compañía como privacidad. Rota parejas frecuentemente y toma descansos: el pairing puede ser agotador, pero es gratificante.

Historias #

Describe lo que el producto debería hacer en términos significativos para clientes y usuarios. Son descripciones cortas de cosas que los usuarios quieren hacer. Sirven para planificar y como recordatorios para conversaciones más detalladas.

Dale a las historias un título corto y una descripción. Escríbelas en tarjetas y ponlas en una pared visible.

En XP las historias se estiman muy temprano. Esto hace que el equipo piense en cómo obtener el mayor retorno de la pequeña inversión.

Ciclo Semanal #

El Ciclo Semanal es una iteración. El equipo se reúne el primer día de la semana para reflexionar sobre el progreso. El cliente elige las historias que quiere entregar esa semana, y el equipo determina cómo abordarlas.

La idea es producir algo para mostrar al cliente y obtener feedback.

Build de Diez Minutos #

El objetivo es construir automáticamente todo el sistema y ejecutar todos los tests en diez minutos.

Integración Continua #

Los cambios de código se prueban inmediatamente al añadirse al código base. El beneficio: detectas y corriges problemas de integración antes.

Requiere disciplina extra y depende mucho del Build de Diez Minutos y el Desarrollo Test-First.

Programación Test-First #

Escribe un test automatizado que falle antes de cambiar cualquier código.

El libro menciona 4 problemas que aborda:

Expansión del alcance: Es fácil dejarse llevar y poner código “por si acaso”. Al declarar explícitamente lo que el programa debe hacer, te das un foco. Si quieres ese otro código, escribe otro test después.
Acoplamiento y cohesión: Si es difícil escribir un test, tienes un problema de diseño, no de testing. El código débilmente acoplado y altamente cohesivo es fácil de probar.
Confianza: Es difícil confiar en el autor de código que no funciona. Al escribir código limpio que funciona y demostrar tus intenciones con tests, das a tus compañeros razones para confiar en ti.
Ritmo: Es fácil perderse horas programando. Con test-first, siempre sabes qué hacer: escribir otro test o hacer que el test roto funcione. Se desarrolla un ritmo natural: test, código, refactorizar, test, código, refactorizar.

Diseño Incremental #

Invierte en el diseño del sistema todos los días.

Haces un poco de trabajo inicial para entender el diseño general, y luego profundizas en los detalles cuando entregas características específicas.

Este enfoque reduce el costo de los cambios y te permite tomar decisiones de diseño basándote en la información más actual.

Roles #

XP especifica prácticas, pero no establece roles específicos. Según la fuente, o no hay orientación, o hay descripciones de cómo los roles tradicionales se comportan en proyectos XP.

El Cliente #

Responsable de tomar todas las decisiones de negocio del proyecto.

Se asume que es una sola persona, pero la experiencia muestra que una persona no puede proporcionar toda la información de negocio de un proyecto.

El Desarrollador #

Como XP no necesita definición de roles, todos (excepto el cliente y un par de roles secundarios) se llaman desarrolladores. Son responsables de realizar las historias identificadas por el Cliente.

El Rastreador #

Su propósito es llevar el seguimiento de métricas relevantes para rastrear el progreso e identificar áreas de mejora.

El Coach #

Usualmente un consultor externo (o alguien de otra parte de la organización) que ha usado XP antes. Ayuda a mentorear al equipo en las prácticas XP y a mantener la autodisciplina.

¿Qué es XP? (en 2 min) #

Tech Talk de Kent Beck: XP 20 años después #

Trabajando con código legado

2019-07-01T00:00:00+00:00

¿Qué es código legacy? #

El código legacy es simplemente código sin tests.

Beneficios de los tests #

El comportamiento es clave para entender los beneficios del testing:

El comportamiento es lo más importante del software. Los usuarios dependen de él. Les gusta que añadamos funcionalidad (si es lo que querían), pero si cambiamos o rompemos comportamiento del que dependen, pierden la confianza.

Cómo implementar tests en bases de código legacy #

Para cambiar código necesitas tests. Pero para añadir tests muchas veces tienes que cambiar código.

El enfoque sugerido:

Identificar puntos de cambio.
Encontrar puntos de test.
Romper dependencias.
Escribir tests.
Hacer cambios y refactorizar.

Un término útil es “costura” (seam): un lugar donde puedes cambiar el comportamiento sin editar ese código directamente. Como la costura en la ropa, donde dos partes se unen. En software, estos lugares suelen tener interfaces bien definidas. Puedes aprovecharlos para cambiar implementaciones con inyección de dependencias o mocking en tests.

El Programador Limpio

2016-08-01T00:00:00+00:00

Los programadores que triunfan bajo presión e incertidumbre comparten algo: les importa de verdad crear buen software. Lo tratan como un oficio. Son profesionales.

Aprenderás #

Qué significa ser un verdadero artesano del software
Cómo lidiar con conflictos, plazos ajustados y jefes difíciles
Cómo entrar en flujo y superar el bloqueo
Cómo manejar la presión y evitar el agotamiento
Cómo combinar actitudes clásicas con nuevos paradigmas de desarrollo
Cómo gestionar tu tiempo y evitar atascos
Cómo crear entornos donde los programadores y equipos prosperen
Cuándo decir No y cómo hacerlo
Cuándo decir Sí y qué implica realmente

Resumen #

Capítulo 1: Profesionalismo #

Ser profesional significa asumir responsabilidad total de tus acciones.
Primera regla: no dañes ni la función ni la estructura del software.
Siempre cometerás errores, pero aprende de cada uno.
Confía en el código que liberas. Espera que QA no encuentre nada.
- Prueba una y otra vez.
- Automatiza tus tests.
- Diseña el código para que sea fácil de probar.
Sigue la regla del Boy Scout: deja el código un poco más limpio de como lo encontraste.
Tu carrera es tu responsabilidad, no la de tu jefe.
- Dedica 20 horas semanales extra a mejorar tus habilidades.
- Lee, experimenta, practica (katas), habla con otros, colabora, mentoriza.
- Que sea divertido.
Conoce tu dominio e identifícate con tu cliente (nunca “nosotros vs. ellos”).

Capítulo 2: Decir No #

Los profesionales tienen el coraje de decir no a sus jefes.
Managers y desarrolladores a menudo chocan porque sus objetivos a corto plazo entran en conflicto.
Cuanto mayor el riesgo, más valioso es un “no” y más difícil de decir.
Los buenos equipos trabajan hacia un sí, pero solo un sí correcto que funcione en la práctica.

Capítulo 3: Decir Sí #

Hay tres partes para hacer un compromiso:
- Dices que lo harás
- Lo dices en serio
- Realmente lo haces
Tu compromiso debe respetar los límites de lo que esperas (basado en tu experiencia) poder y no poder hacer.
- Si reconoces que probablemente no podrás cumplir un compromiso, necesitas levantar una bandera roja inmediatamente.

Capítulo 4: Codificación #

Programar requiere un nivel de concentración que pocas disciplinas exigen.
“La zona” (o flujo) no es tan buena como parece: serás productivo localmente, pero puedes perder la visión global y producir diseños mediocres.
Las interrupciones son malas distracciones.
- El pair programming ayuda a gestionarlas.
- TDD hace que el contexto pre-interrupción sea reproducible.
  - Minimiza el tiempo de depuración.
Programar es una maratón, no un sprint. Conserva energía y creatividad.
Vete cuando sea hora, aunque estés en medio de algo importante.
Reestima continuamente tu tiempo de finalización y avisa en cuanto veas que llegarás tarde.
- No dejes que nadie te meta prisa.
- Define bien qué significa “terminado”, con requisitos de calidad altos.
Programar es difícil para todos. Pide ayuda y ofrécela, especialmente como mentor.
- No tengas vergüenza de preguntar.

Capítulo 5: Test-Driven Development #

TDD no es una cura milagrosa y es impráctico o inapropiado en algunos casos (raros).
Ciclo TDD:
1. Añade un test
2. Ejecuta todos los tests. El nuevo test debería fallar por razones esperadas
3. Escribe el código más simple que pase el nuevo test
4. Todos los tests deberían pasar ahora
5. Refactoriza según sea necesario
6. Repite

Capítulo 6: Practicar #

Una Kata de programación es un conjunto preciso de pulsaciones de teclas y movimientos de ratón coreografiados que simula la resolución de algún problema de programación.
- Una Kata es sobre el proceso, no la solución.
- No estás resolviendo el problema porque ya conoces la solución.

Capítulo 7: Tests de Aceptación #

Evita “basura entra, basura sale”. Asegúrate de entender los requisitos.
- Entenderlos bien significa eliminar ambigüedad.
La mejor forma es definir tests de aceptación:
- Los tests automatizados verifican que el software cumple las condiciones del cliente.
- Pasar esos tests define “Terminado”.
Empieza a implementar solo cuando los tests estén definidos.
Los tests unitarios son para programadores. Los tests de aceptación son para negocio y desarrolladores.
Ejecuta todos los tests en integración continua y arregla los fallos de inmediato.

Capítulo 8: Estrategias de Testing #

QA es parte del equipo. Escriben tests de aceptación, casos de fallo, casos límite y hacen testing exploratorio.
Pirámide de testing:
- La mayoría son tests unitarios: por y para desarrolladores.
- Muchos son tests de componentes o integración: por QA/Negocio con ayuda de desarrolladores, para ambos.

Capítulo 9: Gestión del tiempo #

En desarrollo de software, gestionar bien el tiempo es esencial.
Las reuniones son necesarias pero a menudo una pérdida de tiempo. Evita las que no aporten valor claro: es una obligación profesional.
Las reuniones deben tener agenda y objetivo claro.
- Las dailies ágiles son un formato eficiente.
- La planificación de iteración debería ocupar el 5% de la iteración.
La concentración es un recurso escaso.
- Úsala cuando la tengas y recarga con tareas simples y descansos.
- Para mejorarla:
  - Haz deporte.
  - Busca estímulos creativos.
  - Toma descansos cortos cada 45 minutos.

Capítulo 10: Estimación #

Las estimaciones son la mayor fuente de desconfianza entre negocio y desarrolladores. Los desarrolladores dan estimaciones que negocio trata como compromisos.
- Ambos olvidan que una estimación es una distribución de probabilidad, no un número fijo.

Capítulo 11: Presión #

El profesional mantiene la calma bajo presión. Sigue sus disciplinas porque sabe que es la mejor forma de cumplir plazos.
Evita situaciones de presión:
- Haz solo compromisos que puedas cumplir.
- Mantén tu código limpio.
- Trabaja de forma que no necesites cambiar de método en crisis.
No entres en pánico. Habla con tu equipo. No te aceleres. Confía en tus disciplinas.
Ofrece hacer pairing a compañeros en crisis.

Capítulo 12: Colaboración #

A la mayoría de programadores les gusta trabajar solos. Pero hay que entender los objetivos de quienes nos rodean, incluido negocio.
- Eso requiere comunicación.
Dentro del equipo: solo la propiedad colectiva del código y el pairing producen buena comunicación.
- Programar es comunicarse.

Capítulo 13: Equipos y proyectos #

Los equipos necesitan meses para consolidarse, conocerse y aprender a trabajar juntos.
- Asignar personas a varios proyectos a la vez es mala idea. Romper un buen equipo también.
- Mejor asignar varios proyectos a un mismo equipo.

Capítulo 14: Mentoría, aprendizaje y artesanía #

Los programadores jóvenes necesitan mentoría, ya sea implícita o explícita.
El software controla todos los aspectos de nuestras vidas. Un período de entrenamiento y práctica supervisada es más que apropiado.

En esta lección, Uncle Bob explica por qué es necesario escribir código limpio y establece las bases para lograrlo, tanto sociales como técnicas. El futuro de la programación se basa en un código ético y bien educado.

En esta segunda lección, Uncle Bob habla del propósito de los comentarios. Rompe la idea de que comentar es algo que “hay que hacer” por ser supuestamente buena práctica. Para él, escribir un comentario es señal de fracaso: el buen código se explica solo. Menos comentarios = mejor código.

En esta tercera lección, Uncle Bob quiere crear conciencia sobre la necesidad de elevar el criterio al producir código. Señala la falta de preparación de muchos programadores como una de las principales causas de la ineficiencia en el desarrollo de software actual.

En esta cuarta lección, Uncle Bob introduce el Test-Driven Development (TDD). Es una práctica con curva de aprendizaje larga, pero produce código más robusto, seguro, mantenible y desarrollado con mayor eficiencia.

Código Limpio

2016-05-01T00:00:00+00:00

El código malo puede funcionar, pero si no está limpio, puede hundir a una empresa. Cada año se pierden horas y recursos por culpa de código mal escrito. No tiene por qué ser así.

Resumen #

Capítulo 1: ¿Qué es el código limpio? #

El código se puede medir como “bueno” o “malo” en una revisión, o por cuánto tiempo tardas en explicarlo.
El código limpio es elegante, eficiente, legible, simple, sin duplicaciones y bien escrito.
Tu código debe añadir valor al negocio.
Al abrir un archivo fuente, el código limpio transmite calidad y se entiende fácilmente.
Haz tu código limpio y legible para que cualquiera pueda entenderlo rápido. No hagas perder tiempo a otros.

Capítulo 2: Nombres significativos #

Los nombres de las clases, variables y métodos deben ser significativos e indicar claramente lo que hace un método o lo que es un atributo.
Crea nombres pronunciables para facilitar la comunicación.
Evita acrónimos y nombres confusos, que pueden llevar a conclusiones erróneas a cualquiera que lea el código.
Usa nombres que reflejen el dominio del sistema, el contexto y los problemas que deben resolverse.

Capítulo 3: Funciones #

Los métodos deben ser fáciles de leer y entender.
Deben transmitir su intención.
Deben ser pequeños: hasta 20 líneas.
Deben hacer solo una cosa.
Usa nombres que digan claramente qué hace el método.
El número ideal de parámetros es cero, luego uno, luego dos.
Evita tres parámetros; si los usas, justifícalo.
Un Boolean como parámetro indica que el método hace más de una cosa.
Evita la duplicación.

Capítulo 4: Comentarios #

Cuando necesitas comentarios suele ser porque el código es malo.
Si piensas escribir un comentario, mejor refactoriza el código.
Los comentarios no salvan el código malo.
El código debe explicarse por sí mismo.
A veces los comentarios son útiles en ciertos lugares específicos.
No expliques el código con comentarios. Usa nombres descriptivos de variables y métodos.
Los comentarios pueden destacar la importancia de ciertos puntos.
No escribas comentarios redundantes, inútiles o falsos.
Para saber quién cambió qué y por qué, usa control de versiones.
No comentes código sin usar. Elimínalo.

Capítulo 5: Formato #

El formato es una forma de comunicación entre desarrolladores.
El código desordenado es difícil de leer.
La legibilidad afecta a todos los cambios futuros.
Las clases pequeñas son más fáciles de entender.
Pon un límite de caracteres por línea (por ejemplo, 120).
Mantén los conceptos relacionados cerca verticalmente para crear un flujo natural.
Usa espacios entre operadores, parámetros y comas.

Capítulo 6: Objetos y estructuras de datos #

Sigue la Ley de Demeter:
- Cada unidad debe tener solo conocimiento limitado sobre otras unidades: solo unidades “estrechamente” relacionadas con la unidad actual.
- Cada unidad solo debe hablar con sus amigos; no hables con extraños.
- Solo habla con tus amigos inmediatos.
No hagas objetos tontos.
Los objetos ocultan la abstracción de datos y exponen métodos que operan los datos.
Las estructuras de datos exponen sus datos y no tienen métodos significativos.

Capítulo 7: Manejo de errores #

Planifica el manejo de errores con cuidado.
Cuando algo falla, hay que hacer que el sistema responda correctamente.
Lanza excepciones en lugar de ocultarlas.
Crea mensajes de error informativos: qué falló, dónde y, si es posible, por qué.
Separa las reglas de negocio del manejo de errores.
Evita devolver NULL; devuelve un objeto vacío.
Evita pasar NULL a los métodos; puede causar NullPointerExceptions.

Capítulo 8: Límites #

Al usar código de terceros, encapsula las APIs para no exponer objetos externos.
Haz tests de las APIs de terceros.
Estudia la documentación y prueba la API antes de usarla.
Conoce bien las características que vas a usar.

Capítulo 9: Tests unitarios #

Asegúrate de que cada pieza de código hace lo que esperas.
Sigue las leyes de TDD:
- No escribas código sin tener primero un test que falle.
- No escribas más tests de los necesarios para fallar.
- No escribas más código del necesario para pasar el test.
Mantén tus tests limpios.
Los tests evolucionan junto con el código.
Código sucio = tests difíciles de mantener.
Usa la regla F.I.R.S.T:
- Fast: ejecución rápida.
- Independent: independientes entre sí.
- Repeatable: repetibles en cualquier entorno.
- Self-validating: auto-validantes.
- Timely: escritos a tiempo.
Los tests son tan importantes como el código de producción.

Capítulo 10: Clases #

Organiza las clases así:
- Constantes públicas estáticas.
- Variables privadas estáticas.
- Variables de instancia privadas.
- Luego los métodos.
El nombre de la clase debe reflejar su responsabilidad.
Cada clase debe tener una sola responsabilidad: una razón para cambiar.
Intenta describir la clase en una frase breve.
Los métodos deben ser pequeños y con una sola responsabilidad.

Esta entrevista se basa en el libro de Uncle Bob “Código Limpio”. Repasan algunas guías que te ayudarán a ser mejor programador y exploran cómo los libros y tendencias actuales están moldeando el mundo del software.