Corrigindo um erro enquanto trabalhava em uma parte diferente da base de código

Isso aconteceu pelo menos uma vez comigo. Estou trabalhando em alguma parte da base de código e encontrei um pequeno bug em outra parte, e o bug me impede de concluir o que estou tentando fazer no momento. Corrigir o bug pode ser tão simples quanto alterar uma única instrução.

O que você faz nessa situação?

1. Corrija o erro e confirme junto com seu trabalho atual
2. Salve seu trabalho atual em outro lugar, corrija o erro em uma confirmação separada e continue seu trabalho [1]
3. Continue o que você deve fazer, confirme o código (mesmo que quebra a construção falha em alguns testes), corrija o erro (e a compilação fazer os testes passarem) em uma confirmação separada

[1] Na prática, isso significaria: clonar o repositório original em outro lugar, corrigir o bug, confirmar / enviar as alterações, puxar a confirmação para o repositório em que você está trabalhando, mesclar as alterações e continuar seu trabalho.

Edit: Eu mudei o número três para refletir o que eu realmente quis dizer.

Eu fiz 1 e 2 e, no final, acho que prefiro o 2. Permite mais visibilidade para a correção de bugs, o que pode ser importante para o controle de qualidade / notas de versão / outros desenvolvedores.

Eu também me deparei com uma situação em que o que eu pensava ser realmente um bug não era (sem dizer que esse é o caso aqui), e "corrigi-lo" em um commit separado permitiu que outro desenvolvedor me contatasse e explicasse o que era. em vez da "correção", perdi-me no meu check-in normal.

Eu geralmente vou para o # 2. Torna o repositório mais limpo e torna os logs mais compreensíveis. Eu odeio quando outros desenvolvedores com quem trabalho confirmar 15 correções, recursos e refatorações diferentes, todos no mesmo commit.

Além disso, dependendo de como sua equipe faz o rastreamento de defeitos, pode ser necessário pesquisar no repositório de defeitos para garantir que, se o defeito que você está corrigindo estiver lá, marque o item como completo. Ou, pode ser necessário criar um novo item e marcá-lo como completo, para que o sistema de defeitos e o repositório de códigos correspondam.

Eu faço # 2. Usar ferramentas como o git torna trivial dividi-lo em vários commits. Se você não conseguir convencer sua equipe a mudar para ferramentas mais modernas, o git-svn fornecerá uma parte decente do que você usaria para resolver esse problema. Esta postagem do blog fornece uma boa visão geral do fluxo de trabalho que você está tentando resolver: The Thing About Git

Eu escolhi a opção não escrita (4): Divida seu projeto em assembléias / bibliotecas altamente especializadas, para que erros não relacionados sempre estejam em um local diferente na árvore de controle de versão.

Peço desculpas se o texto acima soa irreverente, mas quero dizer sinceramente. Eu me arrepio sempre que vejo um projeto monolítico com cem formas e espaços para nome que não têm nada a ver um com o outro. Eu costumava enfrentar esse mesmo dilema com frequência, imaginando se e como eu deveria terminar os compromissos que estavam lidando com diferentes áreas funcionais; Só muito tempo depois percebi que ter todas essas diferentes áreas funcionais em um único projeto comprometível era, por si só, uma grande falha de design.

Ainda frequentemente encontro bugs totalmente não relacionados enquanto trabalho em um recurso específico. Talvez eu esteja trabalhando na interface do usuário e encontre um bug em alguma lógica comercial e precise corrigi-lo antes que eu possa seguir em frente. A diferença é que a lógica de negócios está sempre em um conjunto / projeto diferente da interface do usuário; portanto, tudo o que tenho a fazer é fazer uma alteração muito pequena no BL e prosseguir com uma confirmação muito menor e continuar trabalhando.

Ter uma organização de projeto realmente boa torna não apenas possível, mas também fácil lidar com esses problemas sem ocultar uma alteração, interromper a construção ou ficar atolado em uma ramificação / mesclagem irritante (mesmo se você estiver usando um DVCS, não é totalmente indolor) )

Se você não tiver essa opção - ou seja, você é um desenvolvedor júnior sem influência na organização do projeto - então eu simplesmente iria com o nº 1 e faria anotações apropriadas no log para que outras pessoas saibam por que você fez o que fez. Se você fez uma grande alteração, também registre um relatório de bug no seu sistema de rastreamento de problemas para dar visibilidade ao que foi corrigido e por quê.

Eu tento fazer o # 2. Se realmente for um problema separado, é bem provável que ele esteja em um arquivo diferente do que você está trabalhando. Você deve poder fazer o check-in do arquivo como uma confirmação separada, mesmo que ele seja feito no mesmo repositório em que você está trabalhando. Por todos os motivos já expostos, faz sentido ter confirmações o mais independente possível, para rastrear e reverter a alteração, se estiver errada.

Normalmente, apenas conserto o bug e continuo no que estava trabalhando. Quando é hora de confirmar, supondo que a correção de bug esteja em um arquivo separado, eu faço duas confirmações simultâneas - a primeira é uma confirmação parcial contendo apenas a correção de bug e a segunda é tudo o resto.

Resposta curta: # 2. Você realmente deseja que esse bugfix (com sua nota no seu rastreador!) Seja marcado no seu histórico de versões como uma entidade separada.

Resposta mais longa:

• Tropeçar no bug
• Escreva um teste ou mais demonstrando o bug
• Faça o teste passar
• Commit apenas que a mudança e seus testes ( git add --interactiveou darcs record -iou no entanto o seu VCS faz isso) (*)
• Volte para o que eu estava fazendo.

(*) No CVS (não, realmente), às vezes tenho uma árvore limpa em check-out e uma cópia na qual trabalho. Então eu uso uma mesclagem - winmerge, no meu caso - para puxar apenas o bugfix para a árvore limpa, para que eu possa cometer separadamente. (A outra opção é renomear seus arquivos alterados cvs updatee mesclar. Quando você confirmar a alteração, remova o arquivo e renomeie os arquivos movidos de volta aos nomes originais.

No entanto, algo a ser observado é que geralmente só encontro bugs relacionados ao que estou trabalhando ou que estão em estreita proximidade lexical. Eu ficaria surpreso se fosse normal que as pessoas encontrassem erros em partes não relacionadas da base de código - por que você está lendo código não relacionado ao corrigir o erro? (Sim, esse é exatamente o oposto do que Aaronnaught diz!)

Corrijo o bug e faço confirmações separadas , uma para cada correção / recurso.

Na maioria das vezes, as alterações não estão no mesmo arquivo, por isso é fácil separar as confirmações. Se as alterações estiverem no mesmo arquivo, eu uso o TortoiseHg (um front-end da GUI mecânica) para selecionar com precisão as diferenças que eu quero confirmar (acho que é possível fazer isso na linha de comando com a extensão Record , mas é menos conveniente )

Algumas pessoas usam as Filas do Mercurial para isolar as pequenas correções enquanto trabalham em um recurso. As correções secundárias são empilhadas no MQ e, quando o recurso é concluído e confirmado, o conteúdo da fila também é confirmado (um conjunto de alterações para cada entrada na fila).

Eu costumo fazer # 2. Salvando meu trabalho atual em outro lugar: isso geralmente funciona bem ao criar um patch. Além disso, alguns IDEs (IntelliJ) permitem alterações de prateleiras exatamente o seguinte: salve o trabalho atual em outro lugar.

O que eu faço depende se o bug realmente está em uma parte diferente. Se for, então o check-in é independente das minhas alterações feitas pela metade. Eu faço a alteração, construo essa parte diferente para ter certeza de que não cometi algum erro trivial, testei (talvez fazendo o que estava me impedindo de fazer) e verifiquei explicando o que estava acontecendo. Frequentemente, criarei um item de trabalho para ele e, após o check-in / resolução, atribuirei o WI a um testador. Depois volto ao que estava fazendo.

Se tudo estiver misturado com os arquivos que eu mudei pela metade, não consigo construir e testar essa parte de forma independente. Nesse caso, eu faço outro WI para ele e, quando faço check-in das minhas alterações, resolvo os dois WIs com o mesmo check-in, o que geralmente é contra meus princípios, mas se aplica bem neste caso.

Em ambas as circunstâncias, a correção de bug acaba sendo testada por mim, verificada com algum tipo de trilha, para que as pessoas entendam por que eu mudei esse código aleatoriamente naquele dia, e um WI é atribuído a outra pessoa para confirmar que está correto agora.

Nós fazemos # 1. O número 2 parece bom, mas não posso dizer que tivemos problemas com o número 1 que o número 2 seria corrigido.

Um fator adicional na minha empresa é que construímos aplicativos da Web e nossos testes são quase inteiramente por meio da interface da Web - aproximadamente, o que as pessoas chamam de teste funcional em vez de teste de unidade. Todos os testes são aprovados antes do check-in. Dividir confirmações em bits menores significaria executar os testes uma vez para cada bit e isso levaria mais tempo. Eu adoraria ter um conjunto de testes muito mais rápido, o que nos permitiria fazer commits menores, mas simplesmente não o temos.