software-craftsmanship-lisbon / dojos

O monorepo dos dojos do Software Craftsmanship Lisbon.

Processo para a criação, execução e encerramento dos dojos

Escolha do problema

Eu enviarei uma sugestão de Kata para cada dojo. Se alguém tiver outra sugestão de Kata, criaremos um poll para votarmos entre as N sugestões disponíveis.

Agendamento

Escolheremos uma data que seja boa para a maioria, e criaremos o evento no meetup.

Discussão do problema / TO-DO

(10 a 20 minutos): Com um problema previamente escolhido, antes de iniciarmos a seção, discutiremos o passo-a-passo para resolvê-lo, terminando com uma lista de de tarefas para orientar os pares durante a implementação.

Sessão de codificação

(1 a 2 horas): Com uma lista de tarefas para resolver o problema, começaremos a programar no formato Randori.

Time-boxing (5 min)

Durante a programação vamos praticar pair programming, TDD (test-driven development) e refactoring como regra geral.

Além disso, devemos explorar outros princípios e boas práticas, como por exemplo:

• OOP design / Simple design
• Clean code
• Don’t Repeat Yourself (DRY)
• YAGNI (You aren’t gonna need it)
• KISS (Keep it simple stupid)
• Defensive Programming / Guard clauses

Retrospectiva

(10 a 20 minutos): Ao final da sessão, vamos parar de codificar (mesmo que o problema não tenha sido totalmente resolvido) para refletir sobre a experiência e compartilhar as lições aprendidas com o grupo.

“O que aprendemos?”: Refletir e discutir o que foi aprendido é uma forma eficaz de tornar o aprendizado um processo ativo e de verificar se a sessão atingiu seus objetivos.

“O que tem dificultado a aprendizagem?”: São discutidos os aspectos negativos de uma reunião e identificados os principais impedimentos.

Compartilhamento de resultados

Vamos publicar o código, o resultado da retrospectiva, e a gravação do dojo. Criando assim um histórico dos dojos, e compartilhando o nosso aprendizado com outras pessoas.

---

Regras gerais

• Não podemos desrespeitar o time-boxing (5 minutos);
• Não podemos copiar e colar uma pré-implementação;
• Podemos reescrever a implementação feita por alguém antes de nós;
• Discussões e sugestões só devem ser feitas quando a dupla chegar na barra verde, com todos os testes atuais passando. O motivo é que, enquanto estiver na barra vermelha, a dupla deve se concentrar e trabalhar em conjunto para que a implementação seja feita e os testes passem.
• O público sempre pode sugerir refatorações e otimizações em uma barra verde.
• O código deve ser sempre bem refatorado antes de começar a escrever um novo código;
• O par usará TDD

---

Ferramentas

Como os dojos serão online (pelo menos enquanto durarem as restrições do COVID), é necessário instalar o Visual Studio Live Share, que está disponível para ambos Visual Studio e Visual Studio Code.