Serie Artesanía del Software
Las prácticas que mantienen el código cambiable: TDD, refactoring, diseño limpio y los hábitos alrededor.
13 partes
- 1
Un gran ingeniero no es solo un gran programador
Programar no es solo otro trabajo. En el entorno adecuado puede ser divertido, y hasta tu hobby. Sobre subir de nivel tu oficio.
- 2
Algunas reflexiones sobre la calidad del software en tu equipo
¿Qué hacer cuando trabajas en "software malo" y no puedes mejorarlo porque va en contra de las creencias de tus compañeros? ¿Deberías cambiar de empresa?
- 3
Desde el punto de vista de un desarrollador de software
Por qué deberías considerar el testing como parte de tu hábito diario de desarrollo y cómo está directamente vinculado a la calidad del software.
- 4
¿Qué tiene de desafiante?
TDD es una práctica de diseño, no solo una técnica de testing. Escribir tests primero cambia cómo piensas sobre el código y su estructura.
- 5
¿Diseño o Flujo de trabajo?
Estas son dos técnicas diferentes. La clave de cada una está en la mentalidad y el contexto de lo que quieres lograr.
- 6
Es una integración, no una elección
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).
- 7
Cómo escapar del infierno del mocking
Mockear es útil, pero 'qué mockear' suele resultar más complicado de lo esperado si no tratas esto con cuidado.
- 8
Testeando métodos privados. ¿Cuándo y cómo?
De vez en cuando he tenido que enfrentar esta pregunta: ¿cómo testear métodos privados? He recopilado en un artículo las técnicas que suelo usar.
- 9
Cuándo, cómo y por qué
Si ves algo, en el ámbito de tu tarea actual, que puede mejorarse fácilmente, mejóralo. Y si tienes alguna pregunta al respecto, pregunta.
- 10
Cómo escribir tests adecuados para código ya escrito
Cómo escribir tests de caracterización para código legacy y refactorizar de forma segura sin romper el comportamiento existente.
- 11
Abrazando prácticas de calidad en tu cultura de ingeniería
Guía práctica de pair programming que funciona: roles, rotación, cuándo hacerlo, errores comunes y cómo hacer sesiones productivas.
- 12
¿Por qué elegir cuando puedes tener ambos?
Hablemos de los beneficios de los Pull Requests y el Pair Programming, y mis reflexiones sobre estos después de algunos años de experiencia con ellos.
- 13
¿Cómo encaja una persona QA dedicada en tu equipo agile?
Hablemos de la posición de QA. La verdad detrás de la falta de calidad del software, y por qué te concierne si escribes código.












