Dev Book Studies Estudos Deb

Chapter 2. Refactoring

Neste capítulo, ofereço algumas reflexões sobre o que é refatoração e o que você precisa fazer para ser bom nisso. Este capítulo é melhor lido em acompanhamento com o capítulo “Princípios de Refatoração”

What Is Refactoring?

O qu eé Refatoraçâo: Refatoração uma “transformação de preservação de comportamento” ou, como Martin Fowler define, “uma alteração feita na estrutura interna do software para torná-lo mais fácil de entender e mais barato de modificar sem alterar seu comportamento observável” (Refactoring, MartinFolwer).

O que é o procesos de rafatoração: O processo de refatoração envolve a remoção da duplicação, a simplificação da lógica complexa e o esclarecimento do código obscuro. Ao refatorar, você incansavelmente cutuca e estimula seu código para melhorar seu design. Essas melhorias podem envolver algo tão pequeno quanto alterar o nome de uma variável ou tão grande quanto unificar duas hierarquias.

Com garantir que a refatoraçâo nao quebrre nada? Para refatorar com segurança, você deve testar manualmente se suas alterações não quebraram nada ou executar testes automatizados. Você terá mais coragem para refatorar e estará mais disposto a tentar projetos experimentais se puder executar rapidamente testes automatizados para confirmar que seu código ainda funciona.

Quando é a hora de refatorar: É melhor refatorar continuamente, em vez de em fases. Quando você vir um código que precisa ser melhorado, melhore-o (Lei do escoteiro). Por outro lado, se o seu gerente precisar que você termine uma feature antes de uma demonstração que acabou de ser agendada para amanhã, termine o recurso e refatore mais tarde. O negócio é bem servido por contínua refatoração, mas a prática da refatoração deve coexistir harmoniosamente com as prioridades de negócios.

What Motivates Us to Refactor?

As principais razões para refatorar mencionadas no texto são as seguintes:

  1. Facilitar a adição de novo código: Refatorar o código existente permite modificar o projeto para acomodar melhor um novo recurso. Isso evita a criação de dívida de projeto e torna mais fácil e elegante adicionar o novo recurso posteriormente.

  2. Melhorar o design do código existente: Ao melhorar continuamente o design do código, torna-se mais fácil trabalhar com ele. A refatoração contínua ajuda a identificar e corrigir problemas de design, removendo “cheiros de codificação” assim que são encontrados. Isso resulta em um código mais limpo e facilita a extensão e a manutenção futuras.

  3. Obter uma melhor compreensão do código: A refatoração ajuda a melhorar a legibilidade e a compreensão do código. Quando o código não está claro, em vez de adicionar comentários, é preferível realizar refatorações para eliminar os “odores” do código, tornando-o mais expressivo e compreensível.

  4. Tornar a codificação menos irritante: A motivação emocional também pode ser um fator para a refatoração. Quando o código é difícil de trabalhar, irritante ou gera atritos constantes, refatorar pode ser uma forma de tornar a experiência de programação mais agradável. Eliminar problemas de design, como uma classe enorme e sobrecarregada, pode reduzir o tempo necessário para integração do código e melhorar a satisfação geral.

Em resumo, as razões para refatorar incluem facilitar a adição de novo código, melhorar o design do código existente, obter uma melhor compreensão do código e tornar a codificação menos irritante, melhorando a experiência de programação.

Many Eyes

Em seu livro “Simples e direto”, Jacques Barzun explica que toda boa escrita é baseada na revisão [Barzun , 227]. Revisão, ele aponta, significa re-ver. Ter muitos olhos revisando o trabalho de um indivíduo ajudou a produzir melhorias dramáticas.

O mesmo vale para o código. Para obter os melhores resultados de refatoração, você precisará da ajuda de muitos olhos. Esta é uma das razões pelas quais a programação extrema sugere as práticas de pairprogramming e propriedade coletiva de código [Beck, XP

Human-Readable Code

Martin Fowler disse melhor: Qualquer tolo pode escrever um código que um computador possa entender. Bons programadores escrevem código que os humanos podem entender. [F , 15]

Keeping It Clean

Para manter o código limpo, devemos continuamente remover a duplicação e simplificar e esclarecer o código. Não devemos tolerar bagunças no código e não devemos retroceder em maus hábitos. O código limpo leva a um design melhor, o que leva a um desenvolvimento mais rápido, o que leva a clientes e programadores satisfeitos. Mantenha seu código limpo.

Small Steps

O autor descreve a expericneid e um programador que falou que faria uma rfatoraçao em 5miutos mas demorou 1h. Isso ocorreu pois ele fez em grandes passso e nao em pequenos passos. Se você for refatorar, refatore umpoquinho (até um ponto aceitavel) e realize os tets unitarios. Nao pense que vai refatorar tudo de uma vez e vai passar, nao, pode ocorre de falhar. Aí, como voce fez muita cosia, voce vai ter que lhar muita coisa para descobrir o que é que causuou aquele eror.

Trecho

Cada grande passo gerava falhas nos testes de unidade, quedemoravam bastante para serem corrigidas, sem contar que algumas das correções precisavam ser desfeitas em etapas posteriores.

Muitos de nós já tivemos experiências semelhantes - damos passos muito grandes e depois lutamos por minutos, horas ou até dias para voltar a uma barra verde. Quanto melhor eu fico na refatoração, mais prossigo dando passos muito pequenos e seguros. Na verdade, a barra verde tornou-se um giroscópio, um dispositivo que me ajuda a manter o rumo. Se a barra ficar vermelha por muito tempo - mais do que alguns minutos - sei que não estou dando passos pequenos o suficiente. Então eu volto atrás e começo de novo. Quase sempre encontro passos menores e mais simples que posso dar e que me levarão ao meu objetivo mais rapidamente do que se eu tivesse dado passos maiores.

Design Debt

Se você pedir ao seu gerente para permitir que você gaste tempo refatorando continuamente seu código para “melhorar seu design”, qual você acha que será a resposta? Provavelmente “Não” ou uma gargalhada prolongada ou um olhar severo. Acompanhar um fluxo interminável de solicitações de recursos e relatórios de defeitos já é bastante difícil! Quem tem tempo para melhorias de design? Em que planeta você vive?

TRECHO MUITO BOM APRA FALAR COM A GERENCIA SOBRE A REFATORAÇÕ

A linguagem técnica da refatoração não se comunica efetivamente com a grande maioria da administração. Em vez disso, a metáfora financeira da dívida de design de Ward Cunningham [F , 66] funciona infinitamente melhor. A dívida de design ocorre quando você NÃO faz três coisas consistentemente.

1.Remova a duplicação. 2.Simplifique seu código. 3.Esclareça a intenção do seu código.

Poucos sistemas permanecem completamente livres de dívidas de projeto. Conectados como somos, os humanos simplesmente não escrevem um código perfeito na primeira vez. Nós naturalmente acumulamos dívidas de design. Então a pergunta se torna: “Quando você paga?”

Devido à ignorância ou ao compromisso de “não consertar o que não está quebrado”, muitos programadores e equipes gastam pouco tempo pagando dívidas de design.Como resultado, eles criam uma grande bola de lama [Foote e Yoder ]. Em termos financeiros, se você não pagar uma dívida, incorrerá em multas por atraso. Se você não pagar suas multas por atraso, incorrerá em multas por atraso mais altas. Quanto mais você não paga, piores se tornam suas taxas e pagamentos. Os juros compostos entram em ação e, à medida que o tempo passa, sair das dívidas torna-se um sonho impossível. Assim é com a dívida de design.

Discutir problemas técnicos usando a metáfora financeira da dívida de design é uma maneira comprovada de chegar à gerência. Costumo pegar um cartão de crédito e mostrá-lo aos gerentes quando falo sobre dívidas de design. Pergunto-lhes: “Quantos meses seguidos vocês não pagam suas dívidas?” Embora alguns nem sempre paguem suas dívidas integralmente todos os meses, quase todos não permitem que as dívidas se acumulem por muito tempo. Discussões como essa ajudam os gerentes a reconhecer a sabedoria de pagar continuamente a dívida de design.

Uma vez que o gerenciamento aceita a importância da refatoração contínua, toda a maneira de construir software da organização pode mudar. De repente, todos, de executivos a gerentes e programadores, concordam que ir rápido demais prejudica a todos. Os programadores agora têm a bênção da administração para refatorar. Com o tempo, os pequenos e higiênicos atos de refatoração se acumulam para tornar os sistemas cada vez mais fáceis de estender e manter. Quando isso acontece, todos se beneficiam, incluindo criadores, gerentes e usuários do software.

Evolving a New Architecture

JUMP

Composite and Test-Driven Refactorings

JUMP

The Benefits of Composite Refactorings

As refatorações compostas neste livro, cada uma das quais tem como alvo um padrão específico, têm alguns dos seguintes benefícios.

  • Eles descrevem um plano geral para uma sequência de refatoração.
    • A mecânica de uma refatoração composta descreve a sequência de refatorações de baixo nível que você pode aplicar para melhorar um projeto de uma maneira específica. Você precisa dessa sequência? Se você já conhece as refatorações de baixo nível, certamente pode aplicá-las na ordem que achar melhor.
    • No entanto, as sequências de refatoração neste catálogo podem ser mais seguras, eficazes ou eficientes para melhorar seu projeto do que suas próprias sequências de refatoração. Certa vez, segui certas refatorações de baixo nível para refatorar para o estado [DP ] padrão. Então aprendi uma sequência melhor e mais segura. Então alguém sugeriu melhorias para essa sequência. Quando cheguei à quinta versão da sequência, sabia que tinha uma maneira muito melhor de refatorar o padrão State, e era muito diferente da minha abordagem inicial.
  • Eles sugerem direções de design não óbvias.
    • As refatorações compostas começam em uma origem e levam você a um destino. O destino pode ou não ser óbvio, dada a sua fonte. Muito depende de sua familiaridade com os padrões, cada um dos quais define um destino, bem como as forças que sugerem a necessidade de ir em direção a esse destino. As refatorações compostas neste livro tornam essas direções de projeto não óbvias mais claras, descrevendo casos do mundo real em que fazia sentido mover-se na direção de um padrão.
  • Eles fornecem insights sobre a implementação de padrões.
    • Como não existe uma maneira correta de implementar um padrão (consulte Existem muitas maneiras de implementar um padrão , 26), é útil considerar implementações de padrão alternativas. Isso é particularmente verdadeiro para padrões que resolvem diferentes tipos de problemas de design. Por exemplo, este livro contém três refatorações diferentes para Composite [DP ] e três maneiras diferentes de refatorar para Visitor [DP ]. Como você refatora esses padrões e outros irá variar dependendo do problema inicial que você enfrentar. Em reconhecimento a isso, as sequências de refatoração neste livro variam em como elas finalmente implementam um padrão.

Refactoring Tools

As principais lições que podem ser tiradas sobre ferramentas de refatoração com base no trecho são:

  • Ferramentas de refatoração automatizadas revolucionaram o desenvolvimento de software, permitindo que os programadores executem refatorações com facilidade e agilidade.

  • O desafio inicial era criar ferramentas de refatoração para linguagens convencionais, como Java, e muitos fornecedores responderam a essa demanda.

  • Com o tempo, os fornecedores de ferramentas automatizaram refatorações de baixo nível, como “Extrair Método” e “Extrair Classe”, o que facilitou a realização de transformações maiores nos projetos.

  • As refatorações automatizadas podem ser usadas para se aproximar, afastar ou seguir padrões de projeto, oferecendo uma alternativa aos geradores de código de padrão.

  • Mesmo com ferramentas automatizadas, é importante executar os testes após a aplicação de uma refatoração para garantir que o comportamento do código seja preservado.

  • A confiabilidade das ferramentas de refatoração depende da cobertura de testes existente. Sem testes adequados, a refatoração pode ser menos estável ou confiável.

  • Os avanços nas ferramentas de refatoração automatizada estão tornando a mecânica das refatorações mais inteligente e automatizada, mudando a forma como as etapas são abordadas.

  • O futuro das ferramentas de refatoração pode incluir mais suporte automatizado para refatorações de baixo nível, sugestões de refatorações específicas para melhorar partes do código e a capacidade de explorar como o design seria com a aplicação de várias refatorações juntas.

Em resumo, as ferramentas de refatoração automatizadas trouxeram melhorias significativas para o processo de desenvolvimento de software, facilitando a aplicação de refatorações e promovendo um melhor design de código. A cobertura de testes adequada e os avanços contínuos na automação das refatorações são aspectos-chave para o sucesso e a confiabilidade dessas ferramentas.