Projetos de treinamento em refatoração: como estruturar o trabalho com código legado para ensinar a mitigação da dívida técnica.

Uma equipe herda um módulo de faturamento que ninguém entende completamente. Não há testes que protejam o comportamento existente. É proposto um sprint para "limpar" o sistema, e o plano é reescrever o núcleo em uma nova estrutura. Ninguém sabe como garantir que a nova versão ainda cobrará os clientes corretamente.

Este é um cenário ilustrativo, não um incidente documentado. Ele descreve a lacuna que um projeto de treinamento em refatoração precisa preencher: engenheiros que conseguem ver que o código está desorganizado, mas ainda não conseguem planejar uma melhoria delimitada e demonstrar que o comportamento foi preservado.

Este guia destina-se a líderes de capacitação em engenharia e gerentes de engenharia. Ele aborda como descrever o problema de desempenho, diagnosticar as lacunas, planejar a preparação e a prática, analisar um caso e avaliar se a habilidade adquirida é aplicável ao trabalho real. Trata-se de planejamento de treinamento. O código, os testes e as regras do seu programa devem ser validados por engenheiros seniores da sua própria equipe.

O que é um projeto de treinamento em refatoração?

Um projeto de treinamento em refatoração é um trabalho estruturado em código legado, cujo objetivo é desenvolver habilidades e aprimorar o código. Os participantes planejam uma pequena alteração delimitada, protegem o comportamento existente com testes, melhoram o design em pequenos passos e demonstram que nada foi quebrado. O código fica melhor e, mais importante, os engenheiros praticam o discernimento necessário para lidar com dívidas técnicas reais.

Fatos rápidos

1. Descreva o problema de desempenho.

Comece com a tarefa: planejar e validar uma melhoria delimitada em um código legado. "Delimitada" é a palavra-chave. O aluno escolhe uma alteração pequena o suficiente para ser concluída e consegue definir o que está dentro e fora do escopo.

É útil ser preciso quanto aos termos. Martin Fowler descreve a refatoração como uma técnica controlada para melhorar o projeto de uma base de código existente, composta por pequenas transformações que preservam o comportamento. A expressão "preservação de comportamento" é o que diferencia a refatoração da reescrita, e é isso que o treinamento deve tornar visível. A própria metáfora da dívida técnica foi cunhado por Ward CunninghamE a discussão de Fowler é um lembrete útil de que as dívidas podem ser contraídas de forma deliberada e prudente, portanto, nem todo módulo problemático é um erro a ser corrigido.

O livro de Michael Feathers sobre código legado segue a mesma linha de raciocínio na prática. A descrição da editora afirma que ele ensina os desenvolvedores a escrever testes que garantam Eles não estão alterando o aplicativo sem intenção.e para colocar o software existente sob controle sem uma reescrita completa.

Descreva o desempenho em uma frase e peça a um gerente de engenharia para revisá-la: “Dado um módulo legado e um objetivo definido, o engenheiro propõe uma alteração delimitada, adiciona testes que comprovam o comportamento atual, implementa a alteração em pequenas etapas e demonstra que o comportamento é preservado.”

2. Diagnosticar as lacunas de aprendizagem e de contexto

Antes de construir qualquer coisa, compare a tarefa necessária com o que suas atividades atuais praticam e avaliem. Três perguntas geralmente diferenciam uma lacuna de treinamento de outros problemas:

1. A prática atual utiliza a tarefa real? Se o treinamento abordar padrões de refatoração em slides, mas ninguém jamais alterar o código não testado, ninguém terá praticado a proteção de comportamentos. Se a avaliação for um teste de múltipla escolha sobre problemas de código, ela medirá a memorização.
2. Qual é a demanda cognitiva? Na taxonomia revisada de Bloom, julgar se uma mudança é segura se enquadra nos níveis de análise e avaliação, enquanto o planejamento e os testes são realizados no nível de criação. A correspondência entre as atividades e esses níveis é abordada em nosso guia. Alinhar as atividades de aprendizagem à Taxonomia de Bloom.
3. Existe algo além da habilidade que está atrapalhando? Verifique a equipe, as ferramentas e os procedimentos. Se a compilação levar uma hora, ninguém executará testes com frequência. Se a manutenção nunca for agendada, os engenheiros só refatorarão o código em segredo. Relate as causas que não envolvem treinamento às pessoas que podem resolvê-las.

3. Planeje preparação e prática com propósito.

Depois de identificar as lacunas que o treinamento pode preencher, atribua uma função específica a cada etapa.

Preparação. Verifique os pré-requisitos com um breve diagnóstico: como funciona sua estrutura de testes, o que é um teste de caracterização e como sua equipe revisa e consolida os resultados. O estudo individualizado é adequado para esta etapa. Uma verificação de conhecimento prévio apenas confirma os pré-requisitos.

Prática. Utilize projetos de refatoração sistemática com um formato bem definido. Comece com um exemplo pequeno e seguro, depois passe para uma parte real, porém delimitada, do seu próprio código. O kata Gilded Rose é um ponto de partida conhecido para o primeiro passo. Seu README, mantido por Emily Bache, Recomenda-se escrever testes antes de alterar o código. e enquadra o exercício como uma prática de dar pequenos passos, executar os testes com frequência e aprimorar o design gradualmente. Uma sequência sensata para cada projeto é: definir o objetivo e os limites, escrever testes que capturem o que o código faz atualmente, alterar uma coisa de cada vez, executar os testes após cada etapa e anotar o que foi aprendido.

Feedback. Vincule o feedback às decisões tomadas, não à pontuação total. "Você extraiu a lógica de desconto, mas seus testes só cobriram o cenário ideal, então você não poderia ter percebido a alteração no arredondamento" é mais útil do que "3 de 5".

Interação ao vivo com o instrutor ou revisão assíncrona? O feedback em tempo real agrega mais valor quando a escolha é ambígua, por exemplo, se devem parar e adicionar um teste que falta ou continuar. A revisão assíncrona é suficiente quando os alunos comparam seu plano e testes com uma versão anotada por um especialista. Muitas equipes usam ambas as abordagens: preparação individualizada primeiro, seguida de uma sessão facilitada sobre os casos mais complexos.

4. Analise um exemplo realista.

Exemplo ilustrativo. Um gerente de engenharia deve validar o caso e os critérios de resposta antes de utilizá-los.

O caso. Uma função legada calcula o total de um pedido, incluindo desconto, impostos e regras de frete. Ela não possui testes. Uma equipe propõe reestruturar todo o módulo de faturamento para torná-lo mais "limpo".

A tarefa. O aluno explica o que faria, cita as evidências que reuniria e indica de que informações ou apoio adicional precisa.

Uma primeira tentativa. “Eu dividiria o módulo em três serviços e migraria a lógica, depois verificaria os números no ambiente de teste.” O aluno optou por uma mudança drástica e uma verificação manual tardia. Não há como saber se as versões antiga e nova concordam em casos extremos.

Feedback e tentativa novamente. O avaliador pergunta o que a função faz hoje em dia para uma cesta vazia, um desconto que torna o total negativo e um caso de arredondamento. O exercício seguinte pede ao aluno que restrinja o escopo a um comportamento específico e explique como provaria que ele não mudou.

Uma tentativa mais robusta. “Por enquanto, eu deixaria a estrutura do módulo como está. Capturaria o que a função de total do pedido retorna hoje para um conjunto de entradas, incluindo os casos extremos, como testes. Em seguida, extrairia o cálculo do desconto para sua própria função, executaria os testes após essa única etapa e pararia. Observaria que a regra de frete tem um comportamento que não entendo e consultaria um colega antes de alterá-la.” Observe que esta resposta delimita a mudança, protege o comportamento em primeiro lugar e nomeia o que é desconhecido.

Por que cada resposta é defensável ou incompleta. Avalie cada um segundo critérios aprovados, e não segundo a preferência de um avaliador. A primeira tentativa pode ser uma direção sensata a longo prazo, mas é incompleta como plano, pois não apresenta evidências de comportamento consistente. A tentativa mais robusta é pequena, verificável e honesta quanto à incerteza.

5. Avaliar a capacidade e planejar a transferência.

A demonstração de competência consiste no desempenho em um novo caso de código legado que o aluno não tenha visto antes. Avalie a análise de risco e a evidência de que o comportamento foi preservado. Uma rubrica simples utiliza uma escala de 0 a 2 para cada critério:

Critérios de avaliação: 0 significa ausente ou sem suporte, 1 significa parcial com omissões relevantes e 2 significa completo e justificado de acordo com os critérios acordados. Defina erros críticos separadamente, como mudanças de comportamento sem nenhum teste que as tivesse detectado, para que uma pontuação geral não os oculte. Esta rubrica é uma proposta, não um padrão de prontidão validado: adapte-a com um gerente de engenharia e implemente um projeto piloto. Nosso guia para Projetando práticas interativas com feedback útil Mostra como redigir feedback que esteja relacionado às decisões tomadas.

Planeje a transferência de tarefas com cuidado. Após o exercício, atribua a cada engenheiro uma pequena tarefa real para resolver com um revisor, ou realize uma breve retrospectiva sobre uma alteração recente que causou algum problema. Verifique a transferência após uma exposição adequada ao trabalho real, e não imediatamente após o workshop.

Onde a entrega interativa ajuda

Os formatos interativos são úteis quando todos devem se comprometer antes de verem o grupo. Em uma sessão ao vivo, um facilitador pode mostrar um pequeno trecho de código legado, pedir a cada engenheiro que envie a primeira alteração que faria e como comprovaria sua segurança, e então revelar o resultado antes da discussão. O mesmo exercício pode ser executado individualmente para preparação. O AhaSlides oferece suporte ao aprendizado interativo e à transição entre sessões ao vivo e individuais. É uma ferramenta de apresentação e aprendizado, não um ambiente para executar ou analisar código; portanto, execute a refatoração em seu próprio ambiente. Verifique se alguma função específica de autoria, feedback ou relatório que você planeja utilizar está de acordo com seu próprio fluxo de trabalho. Para obter orientações sobre a escolha de formatos, consulte nosso artigo sobre Quando usar o aprendizado adaptativo, interativo e ao vivo.

Meça o que mudou.

Decida antecipadamente o que demonstraria que os engenheiros são capazes de realizar a tarefa. Compare a qualidade da análise de risco e a evidência de comportamento preservado em um caso inédito, em relação a uma linha de base. Defina quem está incluído, o denominador e o período. Se os resultados melhorarem, verifique o que mais mudou no mesmo período, como novas ferramentas de teste, uma construção mais rápida ou uma mudança de responsabilidade, antes de creditar o treinamento.

Restrições que podem permanecer

• Hora de fazer a manutenção. Se o trabalho relacionado à dívida nunca for agendado, os engenheiros qualificados continuarão sem ter onde usar suas habilidades.
• Ferramentas de teste. Sem um dispositivo de teste adequado ou uma montagem rápida, pequenos passos e verificações frequentes tornam-se difíceis de manter.
• Cobertura do caso. Um caso histórico ilustra alguns tipos de risco. Uma pontuação não descreve o julgamento de um engenheiro em geral.
• Avaliar quando não refatorar. Alguns códigos são melhor deixados como estão, substituídos ou desativados, e essa decisão envolve mais do que habilidade.
• Transferência. O desempenho em um kata não é o mesmo que o desempenho em um módulo de produção sob pressão de entrega.

Informe esses problemas aos patrocinadores o quanto antes e planeje correções separadas. O treinamento aprimora o que um engenheiro pode planejar e comprovar. Ele não cria o tempo nem as ferramentas necessárias.

Perguntas frequentes

O que é um projeto de treinamento em refatoração?

Trata-se de uma prática estruturada em código legado, onde os engenheiros planejam uma pequena alteração, protegem o comportamento existente com testes, modificam o projeto em pequenos passos e demonstram que nada foi quebrado.

Reescrever o código completamente é uma boa maneira de aprender sobre dívida técnica?

Geralmente não. Uma reescrita é extensa, difícil de validar e esconde a habilidade que você deseja desenvolver. Uma mudança delimitada, com testes que capturam o comportamento atual, torna o raciocínio visível.

Como avaliar se os engenheiros podem refatorar com segurança?

Apresente um novo caso de código legado e avalie a análise de risco e as evidências de que o comportamento foi preservado, comparando-as com critérios predefinidos. Um questionário sobre padrões de refatoração apenas confirma os pré-requisitos.

Você precisa de um código-fonte de exemplo para o treinamento?

Você precisa de um local seguro para praticar. Muitas equipes começam com um kata público e depois passam para uma parte delimitada do próprio código. Seu gerente de engenharia deve confirmar se o código é adequado.

Por onde começar

Escolha uma pequena alteração recorrente em seu código legado. Elabore a declaração de desempenho, peça a um gerente de engenharia que valide o caso e os testes que demonstrariam a preservação do comportamento, e crie uma rubrica com três critérios, numa escala de 0 a 2, e uma lista de erros críticos. Teste-a com um pequeno grupo antes de implementá-la em larga escala.

Para ver como um exercício de tomada de decisão de refatoração pode ser executado ao vivo com sua própria equipe e reutilizado posteriormente em seu próprio ritmo, explore o AhaSlides.