Práticas recomendadas para renomear, refatorar e interromper alterações com as equipes

Quais são algumas das práticas recomendadas para refatoração e renomeação em ambientes de equipe? Eu trago isso com alguns cenários em mente:

1. Se uma biblioteca comumente referenciada for refatorada para introduzir uma alteração de quebra em qualquer biblioteca ou projeto que faça referência a ela. Por exemplo, alterar arbitrariamente o nome de um método.

2. Se os projetos forem renomeados e as soluções devem ser reconstruídas com referências atualizadas a eles.

3. Se a estrutura do projeto for alterada para ser "mais organizada", introduzindo pastas e movendo projetos ou soluções existentes para novos locais.

Algumas reflexões / perguntas adicionais:

1. Mudanças como essa são importantes ou a dor resultante é uma indicação de que a estrutura deu errado?

2. Quem deve assumir a responsabilidade de corrigir os erros relacionados a uma alteração de quebra? Se um desenvolvedor fizer uma alteração inédita, ele deve ser responsável por entrar nos projetos afetados e atualizá-los ou deve alertar outros desenvolvedores e solicitar que eles mudem as coisas?

3. Isso pode ser feito de forma programada ou deve ser feito com a maior frequência possível? Se uma refatoração for adiada por muito tempo, é cada vez mais difícil reconciliar, mas ao mesmo tempo em um dia, passando incrementos de 1 hora corrigindo uma construção devido a alterações que ocorrem em outros lugares.

4. Trata-se de um processo formal de comunicação ou pode ser orgânico?

Cada um dos cenários listados se enquadra na categoria "código / API publicado". É difícil refatorar, portanto, não se deve mudar nada levemente. Em vez disso, ele deve negociar as mudanças planejadas antecipadamente com todas as partes envolvidas. É pelo menos tanto uma questão política quanto técnica.

Portanto, o conselho número um sobre isso de Martin Fowler é não publicar suas interfaces (nomes e estruturas de projetos) prematuramente .

No entanto, se já estiver pronto e precisar ser corrigido, provavelmente é melhor tentar fazer as alterações necessárias no menor número de etapas possível, para minimizar a interrupção de outras partes. O que está se afastando bastante do conceito original de refatoração, mas por um bom motivo.

Além disso, se possível, considere adicionar o novo método (ao descontinuar o existente) em vez de renomear o existente. Isso garante que o código do cliente não seja interrompido e fornece um período de transição para que eles atualizem seu código de acordo com a API mais recente. A desvantagem é que isso complica sua API. Embora o estado seja apenas temporário, no entanto, pode levar um tempo considerável antes que você possa remover com segurança os métodos API reprovados (no caso da biblioteca de classes Java, anos).

Você quase sempre pode evitar esses problemas refatorando em duas etapas. Na primeira etapa, introduza o novo código e descontinue o código antigo. Quando todas as equipes migrarem para o novo código, exclua o código antigo. Eu também uso essa técnica para refatorar gradualmente um único módulo. Dessa maneira, posso limitar a quantidade de código que deve ser alterada entre as execuções de teste.

Observe que esse é um dos principais motivos para ter um servidor de construção, que executa testes.

Se acontecer algo que interrompa um determinado programa, você será informado o mais rápido possível e poderá procurar o culpado e resolver os problemas enquanto os detalhes ainda estão atualizados.