Tweet
Tweet

Slide 1

Slide 1 text

Refatoração HHBR 2016-12-10 Davi Marcondes Moreira @devdrops

Slide 2

Slide 2 text

Introdução

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Objetivos principais: 1. Sempre deixar a casa melhor do que você encontrou. 2. Tornar o software mais confiável para você e para quem vai mexer nele amanhã.

Slide 5

Slide 5 text

Além dos sistemas legados

Slide 6

Slide 6 text

Correções ● Débito técnico (o famoso TODO) ● Vulnerabilidades e bugs ● Acúmulo de más práticas

Slide 7

Slide 7 text

Correções ● Débito técnico (o famoso TODO) ● Vulnerabilidades e bugs ● Acúmulo de más práticas Melhorias ● Atualização de dependências ● Melhorar performance ● Diminuir complexidade (o código deve ser simples)

Slide 8

Slide 8 text

Correções ● Débito técnico (o famoso TODO) ● Vulnerabilidades e bugs ● Acúmulo de más práticas Melhorias ● Atualização de dependências ● Melhorar performance ● Diminuir complexidade (o código deve ser simples) Criação ● TDD: red, green, e, qual era o terceiro mesmo?

Slide 9

Slide 9 text

Correções ● Débito técnico (o famoso TODO) ● Vulnerabilidades e bugs ● Acúmulo de más práticas Melhorias ● Atualização de dependências ● Melhorar performance ● Diminuir complexidade (o código deve ser simples) Criação ● TDD: red, green, e, qual era o terceiro mesmo? Refactor.

Slide 10

Slide 10 text

Trabalho em equipe

Slide 11

Slide 11 text

Colaboração ● Refatorar não é uma atividade isolada. ○ Pedir ajuda aos colegas ○ Discutir em grupo/equipe ○ Alinhar métricas e regras ■ Mínimo de % na cobertura de testes, padrões de estilo ○ Não ser negligente e assumir responsabilidade

Slide 12

Slide 12 text

Ferramentas para toda obra

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Métodos (pequenos porém úteis)

Slide 19

Slide 19 text

1. Renomeando métodos ● Usando forma mais claras, curtas e concisas, ou mesmo verbosas se necessário. ● Ser o mais explícito possível. ● Em casos críticos, reescreva a nova chamada dentro do método antigo, depreciando o método anterior e evitando quebrar compatibilidades enquanto a adoção do novo método é feita por toda a equipe.

Slide 20

Slide 20 text

2. Extrair responsabilidades de um método em um novo(a) método/classe ● Identificar que parte de um código pode ser reescrita em outro lugar, reduzindo a complexidade. ● Abre espaço para refletir sobre princípios como 'o que de fato isso deveria estar fazendo?', 'qual a verdadeira responsabilidade desse método?' e encaixar boas práticas como SRP de orientação à objetos.

Slide 21

Slide 21 text

3. Eliminar código morto ● Código que não tem mais uso, ou é fruto de copiar de uma parte específica do projeto para outra, que ficou para trás. ● Não ter medo de excluir código. Partes antigas podem ser recuperadas pelo SCV. ● Requer uma boa estratégia de teste.

Slide 22

Slide 22 text

Benefícios

Slide 23

Slide 23 text

Entregas pontuais O código fica mais compreensível, organizado e flexível à mudanças. Confiança e segurança ao editar o código Maior visibilidade dos problemas. Garantia de qualidade Fim da síndrome da casa de vidro. Uma bela noite de sono =P

Slide 24

Slide 24 text

Conclusão

Slide 25

Slide 25 text

No episódio de hoje… ● Tudo o que se precisa é intenção. ● Refatoração acontece em vários momentos. E todos podem e devem ajudar. ● Quanto mais cedo e pontual, mais fácil de fazer. ● Nem toda refatoração é simples, e cada caso precisa ser muito bem analisado para verificar todo impacto e esforço.. ● "A única certeza sobre software é que ele muda."

Slide 26

Slide 26 text

Muito obrigado! =P @devdrops devdrops.me/about