Você deve melhorar a qualidade do código enquanto trabalha em uma ramificação de recursos

Eu realmente gosto deste artigo sobre deixar o código / local de acampamento em um estado melhor do que você o encontrou - parece uma abordagem prática no mundo real manter-se atualizado sobre a limpeza do código.

Também gosto muito de ramos de recursos como uma maneira de desenvolver recursos isoladamente, de modo que, se você não gostar, não poderá mesclá-lo facilmente etc.

No entanto, se eu estiver trabalhando em um ramo de recurso e detectar algum código feio, devo corrigi-lo?

Parece que existem várias desvantagens para corrigi-lo:

• Quando eu mesclar a ramificação novamente, o diff ficará confuso, cheio de renomeamentos de variáveis ​​ou extração de funções
• Se o recurso for abandonado, você deverá escolher a confirmação de limpeza (que pode ou não funcionar dependendo de como o código próximo a ele mudou, tornando uma fusão confusa), refazê-lo ou simplesmente abandoná-lo.

Por outro lado, se eu não fizer isso enquanto estou no arquivo, então claramente esquecerei de fazê-lo em alguns dias quando mesclar o ramo.

Fui avisado de que isso era baseado em opiniões (acho que apenas pelo fato do título incluir should), mas sinto que há uma resposta (certamente as pessoas usam essas duas abordagens para que tenham uma resposta). Além disso, as perguntas sobre development methodologiesestão no tópico e acho que precisam de um certo grau de opinião.

Você só deve 'consertar' o código em uma ramificação do recurso se estiver alterando esse trecho de código de qualquer maneira como parte do recurso.

Por exemplo. Estou trabalhando no recurso 'imprimir coelhos' e encontro o código da impressora

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Eu mudo para:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Por quê:

• Estou trabalhando no código
• Preciso alterá-lo para adicionar funcionalidade,
• a funcionalidade adicionada sugere uma maneira refatorada de lidar com o problema.

Eu não acerto aleatoriamente alguma outra parte da base de código e 'o torna melhor', pois isso faria:

• Entre em conflito com pessoas que trabalham em outros recursos.
• Use o tempo que deve ser alocado para o desenvolvimento do recurso.
• Adicione código arbitrário a uma ramificação que, se o recurso não estiver concluído, não poderá ser mesclada no produto principal. Da mesma forma, se eu reverter o recurso, perderei minha refatoração.

Se você deseja que suas refatorações "vivam independentemente" de sua ramificação de recursos atual, não faça as alterações lá. Em vez disso, faça a refatoração no ramo de desenvolvimento principal (ou um "ramo de refatoração", se for comum em sua equipe não aplicar alterações diretamente no ramo de desenvolvimento). Portanto, qualquer pessoa da sua equipe (incluindo você) pode mesclar as alterações nos ramos de recursos ativos nos quais eles estão trabalhando. No entanto, tome cuidado para não aplicar quaisquer refatorações globais em "metade da base de código" sem pedir permissão a seus colegas primeiro - eles podem não ficar tão felizes se suas refatorações interferirem demais no trabalho atual.

A exceção está aqui quando as melhorias que você faz são locais nas partes da base de código que você toca exatamente nessa ramificação de recursos, e não faz sentido dar a elas um ciclo de vida diferente do seu "novo recurso".

O objetivo dos branchtipos é fornecer a intenção de manipulá-los. Se você está seguindo um estilo GitFlow de ramificação, então você provavelmente tem tipos como feature, hotfix, release, etc .. No caso de um ramo de funcionalidade, a sua intenção é encapsular uma mesclagem em outro ramo (isto é develop) que mostra o desenvolvedor responsável por mesclando, qual é esse recurso. Se o código que você está limpando não faz parte desse recurso, não o altere.

Em vez disso, encontre o ramo mais baixo possível em que o código feio está (provavelmente develop) e o ramo a partir daí. Altere o código e proponha que ele seja mesclado como um recurso. Se você precisar desse código no que está trabalhando e, especialmente, deseja evitar conflitos de mesclagem, mescle esse ramo no SEU ramo.

Aqui está uma boa explicação de diferentes estratégias: https://www.atlassian.com/git/tutorials/comparing-workflows/

se estiver trabalhando em um ramo de recursos e detectar algum código feio, devo corrigi-lo?

Provavelmente é bom corrigir 'código feio' à vista, dependendo do andamento do projeto, da 'feiúra' do código etc. etc., mas tente não fazer isso no próprio ramo do recurso.

• Se sua ramificação de recursos for totalmente local, apenas oculte ou confirme alterações não salvas, confira a ramificação de desenvolvimento, faça a alteração e, em seguida, retorne à ramificação de recursos e retome o desenvolvimento.
• Se você não conseguir refazer o desenvolvimento do desenvolvimento (por exemplo, sua ramificação de recursos está em um servidor público), ainda poderá escolher qual o desenvolvimento de desenvolvimento comprometido, se você precisar ou quiser evitar conflitos mais tarde.
• Se você estiver editando um arquivo e realmente precisar confirmar a correção no código feio no momento e realmente não puder mudar para o desenvolvimento, poderá fazer a correção, usá git add -p-la, confirmar somente a alteração e antes de mesclar / push (de fato, de preferência após o seu próximo commit), use o rebase interativo para movê-lo para o primeiro ponto possível em sua ramificação, ou até mesmo escolher o desenvolvimento, dependendo do seu histórico.

Eu também faria isso com qualquer outra coisa que 'conserte' o ramo de desenvolvimento (em que 'consertos' são alterações que você ou qualquer outro desenvolvedor pode fazer à vista para garantir que o código siga os padrões). Isso ajuda...

• para manter suas correções e seu recurso confirmado em diferentes grupos, para que o log fique mais legível,
• manter o desenvolvimento o mais próximo possível de ser liberável a qualquer momento, e
• para evitar duplicação de trabalho (várias pessoas corrigindo o mesmo problema de maneiras sutilmente diferentes em diferentes ramos).