# 99 bottles - 4. Practicing Horizontal Refactoring

## Bruno
- Flocking Rules;
- SOLID;
- Esforço para escolher bons nomes se paga no futuro no momento da leitura do código;

## dalvi

- codigo eh lido muito mais vezes do que escrito, entao legibilidade acaba diminuindo custos
- fazer coisas gradualmente mais parecidas entre si, na esperanca de que, em algum ponto, se torne claro como torna-las identicas
- qualquer conhecimento eh uma dependencia (no caso do livro, se _quantity_ fosse mais consistente em seus retornos, _verse_ nao precisaria transformar tudo em string) -> _quantity_ cuidar disso internamente evita que _verse_ tenha que saber disso
- se ao juntar varios passos da refatoracao em um soh os testes quebraram, nao continue refatorando no _red_. Retorne ao _green_ e refatore incrementalmente ateh que vc entenda novamente o que esta acontecendo
- o codigo refatorado via flock rules traz beneficios invisiveis a ferramentas de analise estatica, ele revela conceitos previamente obscuros e os isola

## Gabs
- abstrair difereças
- name a concept
- Name the concept, create the method, and replace the difference with a commom message send
- stay horizontal and concentrate on the current goal
- stable code enables future refactorings
- make things more alike in hopes that it will then become clear how to make them identical
- sender of the message should not have knowledge of the return type (consistent return)
- dont refactor under red

## Igor
- "O esforço colocado em escolher bons nomes agora compensa tornando mais fácil identificar nomes perfeitos mais tarde."
- Flocking Rules
1. Select the things that are most alike.
2. Find the smallest difference between them.
3. Make the simplest change that will remove that difference.
- Abstração
- soLid - Princípio de substituição de Liskov
- Duck typing
- Difference x Sameness (remover diferenças)
- Violar o principio de liskov força as chamadas a saberem sobre os diversos tipos de retorno. (to.s.capitalize...)
- "Taking care of the small things often cuts the big ones down to size."
- "Dê nome ao conceito, crie um método que o represente, e então substitua essa diferença na chamada."
- "Reduzir o numero de dependencias impostas no envio da mensagem, requisitando que quem recebe deve retornar objetos confiaveis."

## Johny

- O aumento em abstração faz das coisas as mesmas. Sem isso, você fica preso a condicionais
- Regras de refatoração, apesar de simples, resultam em código preciso e com comportamento complexo
- Apesar de ser possível usar do bom senso, manter-se horizontal e concentrado no objetivo atual é melhor. Descreva abstrações assim como você as entende agora e então as nomeie. O esforço colocado em colocar o nome correto tem alto trade-off
- :FIXME como padrão para atingir else de condicional, você não perde tempo procurando o valor correto e o nome permite voltar para arrumar depois, sem esquecer o valor padrão lá
- Códigos são lidos mais vezes do que escritos, então QUALQUER coisa que aumente o entendimento diminui o custo
- Inconscistencia de tipos de retorno forçam o rementente da mensagem a saber mais do que deveria. Princípio de Liskov requerem que objetos sejam oq prometem ser

## Conclusões
- Esforço para escolher bons nomes se paga no futuro no momento da leitura do código.
- "Dê nome ao conceito, crie um método que o represente, e então substitua essa diferença na chamada."