Tweet
Tweet

Slide 1

Slide 1 text

Refatoração PHPSP Talks 2017-04-18 Davi Marcondes Moreira @devdrops

Slide 2

Slide 2 text

Introdução

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Broken Window Theory Por James Q Wilson e George L Kelling, Março 1982 https://en.wikipedia.org/wiki/Broken_windows_theory “Desordem gera desordem.”

Slide 5

Slide 5 text

Refatoração: O que é? ● Processo de reestruturar o código sem alterar seu comportamento.

Slide 6

Slide 6 text

Refatoração: O que é? ● Processo de reestruturar o código sem alterar seu comportamento. Mas IMHO também é: ● Sempre deixar a casa melhor do que você encontrou. ● Tornar o software mais confiável para você e para quem vai mexer nele amanhã.

Slide 7

Slide 7 text

Além dos sistemas legados

Slide 8

Slide 8 text

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

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)

Slide 10

Slide 10 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 11

Slide 11 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 12

Slide 12 text

Trabalho em equipe

Slide 13

Slide 13 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 14

Slide 14 text

Ferramentas para toda obra

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

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

Métodos (simples porém úteis)

Slide 25

Slide 25 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 26

Slide 26 text

1. Renomeando métodos // Classe usada por toda a aplicação class Foo { public function oldScaryMethod( $foo, $bar, $baz ) { // Complexidade no contexto } } // Chamada encapsulada em outro método class Foo { public function newMethod( $foo ) { // Podemos agir aqui $this->oldScaryMethod(...); } public function oldScaryMethod(...) { // Complexidade isolada } }

Slide 27

Slide 27 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 28

Slide 28 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 29

Slide 29 text

Benefícios

Slide 30

Slide 30 text

Entregas pontuais O código fica mais compreensível, organizado e flexível à mudanças.

Slide 31

Slide 31 text

Entregas pontuais O código fica mais compreensível, organizado e flexível à mudanças. Confiança ao editar o código Maior visibilidade dos problemas.

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Entregas pontuais O código fica mais compreensível, organizado e flexível à mudanças. Confianç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 34

Slide 34 text

Conclusões

Slide 35

Slide 35 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 36

Slide 36 text

Muito obrigado! =P @devdrops devdrops.me/about Gostou? Estamos contratando! [email protected]