2 minute read

Índice de temario

Día Tema a tratar
1 Definiendo objetivos
2 Proyecto inicial y value objects
3 Tratando con excepciones
4 Validando con Enum y parametrized test
5 Ampliando uso del Enum
6 Entidades

Día 1. Estableciendo objetivos y marco de trabajo

Para cambiar de lenguaje, hay que descubrir su estructura y reglas. Pero realmente, para sacar el máximo provecho, creo que es más útil plantearse un ejercicio que ya hayas resuelto en tu lenguaje favorito e intentes resolverlo en el nuevo sistema.

Pensando en cómo abordar el cambio, he hecho una lista de reglas para no perderme.


Reglas para cambiar de lenguaje

  • Para empezar, busca una kata que tenga elementos variados para poner a prueba tus habilidades.
  • Usa las buenas prácticas que ya conoces de tu lenguaje habitual y peléate por conseguir lo mismo. ¡No bajes la calidad nunca!. Puede que tengas que replantearte ciertos términos que parecían innegociables en tu lenguaje habitual y que en el lenguaje nuevo se enfoca de forma diferente… ese proceso mental de argumentar el porqué es diferente te dará el conocimiento profundo del nuevo lenguaje.
  • Aplica TDD con DDD siempre. Eso quiere decir que has de empezar planteándote cómo usar el framework de tests de ese lenguaje y luego escribiendo el código. Como sabemos, TDD sin una estructura como DDD es inútil. Puedes hacer algo ilegible pero testeado y no es el objetivo. Cambia el lenguaje, no la estructura.

Puede parecer algo bruto pelearse con el framework de tests antes que con el código. Pero si has decidido cambiar de lenguaje, es que ya has leído algo de cómo se articula y lo que ves te ha gustado, con lo que ahora toca ponerse serios (desde la amabilidad, por supuesto) y ver cómo montar los tests con el nuevo lenguaje. Al tener normas diferentes puede que te sorprenda y los tests también te hagan cambiar de mentalidad. Difícilmente podrás hacer lo mismo de la forma que estás acostumbrado.. y los tests no son una excepción.

En mi caso usaré la mower kata.


comments powered by Disqus