# CDS 99 bottles

### jones:

- Dont Repeat Yourself - extrair duplicações em um único método comumm e então chamá-lo no lugar de código. Ótima ideia, mas não é grátis. Se bem escolhido, seu código será expressivo, inteligível, flexível e todos vão te amar <3. Caso contrário, será confuso, complicado e caro. Não buscar abstrações, mas resistir até que elas insistam em serem criadas

- primeiro código: conciso ao ponto da incompreenção, além de muita duplicação. Inconsistente, repetitivo e conceitos não nomeados. Cada vez que uma condição muda, o leitor precisa resetar sua linha de raciocínio. Aumenta o custo sem nenhum benefício.

- Métodos são *definidos* e mensagens são *enviadas*. Existem inúmeras formas de um objeto responder a uma mensagem da qual não define um método que case. Apesar de ser comum o nome de mensagens mapearem diretamente para nome de métodos, não é uma regra.

- Escrever código é como escrever um livro: seus esforços são para os *outros* lerem

- segundo código: mais código do que o necessário para passar nos testes, o que leva tempo. Confuso por ser extremamente indireto. Difícil de entender sem ser mais fácil de mudar

- terceiro código: métodos em excesso, impossível discernir. difícil de escrever e de entender. tem tanto DRY que fica custoso

- Shameless green: buscar passar no teste de forma simples.

### Dalvizera

- Escolhas de design tem custos, e se vale a pena se vc tiver o beneficio delas (vale a pena usar o DRY, por exemplo, sempre que possivel?)
- Nao eh possivel abstrair sem conhecer completamente o codigo, fazer isso precocemente mais atrapalha do que ajuda (a pessoa que esta abstraindo pode conhecer, mas o resto do time que talvez nao conheca? vale a pena abstrair mesmo assim?)
- Estilo inconsistente de codigo dificulta o trabalho (mantemos padrao em muitas coisas no criador, ate mensagem de commit, o que poderiamos fazer alem?)
- Escrever codigo tem que ser um esforco para os outros que vao ler
- Programador gosta de codigo tenso, mas a complexidade pode estar sendo adicionada onde nao deve
- DRY faz sentido quando facilidade de mudanca futura no codigo eh maior do que o custo adicional para entender o codigo (como podemos medir custo disso?)

### Igor:
- Design é escolher as abstrações certas.

- Você não deve buscar/procurar as abstracoes, mas sim resitir a elas até elas insistirem absolutamente a serem criadas.

- Seu codigo é menos concreto porém mais abstrato, voce inicialmente o fez mais dificil de entender na esperanca de q um dia ele será mais facil de manter.

- O codigo que tu escreve confronta 2 objetivos geralmente contraditorios. Ele deve ser concreto o bastante para ser compreendido enquanto simultaneamente abstrato o bastante para permitir mudancas.

- O codigo é facil de entender quando claramente reflete o problema q está resolvendo, e assim expões abertamente o problema do dominio.

- O quao dificil foi pra escrever?
- O quao dificl é para entender?
- O quao custoso será para mudá-lo?

### Gab:
- equilíbrio entre abstrato e "concreto"
- lógica duplicada

### Bruno
- DRY;
- - Abstrações confusas e desnecessárias;
- - Complexidade a mais;
- - Refatoração prematura;
- - Acoplamento desnecessário;
- Nomeação de funções e variáveis;
- Single Responsability principle;
- Open Closed principle;
- Abstração de funções;
- Cyclomatic Complexity;
- Red Green Refactor;
- Questões a serem feitas quando um código eh finalizado.

### Coisas que aprendemos e nos comprometemos a fazer daqui em diante

- preparar anotacoes sobre o capitulo antes da reuniao
- xerxes eh malandro e nao le o capitulo inteiro
- Otimização prematura é a raiz de todo o mal.
- código padronizado, variaveis com nomes descritivos (pregar foto no prefixo yata)

### Trade-offs do DRY
- não saber exatamente sobre o comportamento do método chamado.

### Ações

- MRs bem descritivos. ex.: Histórias de front que contemplem mudanças de comportamento, adicionar imagens/gif

- Melhorias/padronizacao na escrita de testes

- Estudar ferramentas de métricas de código (Rubocop e Credo)

- Sempre lembrar do senso crítico nas revisões de código, comentar e interagir mais nos comentários.
ex.: Fazer o exercicio mental:
- O quão dificil foi pra escrever?
- O quão dificil é para entender?
- O quão custoso será para mudá-lo?

- criar repo do criador-estudos, separar por ata por reunião