ti-enxame.com

Corrigindo um bug ao trabalhar em uma parte diferente da base de código

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

O que você faz nessa situação?

  1. Corrija o bug e comprometa-o junto com seu trabalho atual
  2. Salve seu trabalho atual em outro lugar, corrija o bug em um commit separado e continue seu trabalho [1]
  3. Continue o que você deve fazer, confirme o código (mesmo que quebra a construção falhar em alguns testes), então conserte o bug (e a construção fazer os testes passarem) em um commit separado

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

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

22
imgx64

Eu fiz 1 e 2 e no final, acho que prefiro o # 2. Ele permite mais visibilidade para a correção do bug, o que pode ser importante para QA/notas de lançamento/outros desenvolvedores.

Também me deparei com uma situação em que o que pensei ser um bug na verdade não era (sem dizer que este é o caso aqui), e "consertar" em um commit separado permitiu que outro desenvolvedor me contatasse e explicasse o que era o que em vez de "consertar" apenas me perder no meu check-in normal.

16
Adam Lear

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

Além disso, dependendo de como sua equipe faz o rastreamento de defeitos, você pode precisar pesquisar o repositório de defeitos para ter certeza de que, se o defeito que está corrigindo estiver lá, você marque o item como concluído. Ou talvez seja necessário criar um novo item e marcá-lo como concluído para que o sistema de defeitos e o repositório de código correspondam.

12
RationalGeek

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

7
Daenyth

Eu escolho a opção não escrita (4): Divida seu projeto em assemblies/bibliotecas altamente especializadas, de modo que bugs não relacionados estarão sempre em um local diferente na árvore de controle de versão.

Peço desculpas se o acima soa sarcástico, mas falo sinceramente. Eu me encolho sempre que vejo um projeto monolítico com centenas de formas e namespaces que não têm nada a ver um com o outro. Eu costumava enfrentar esse mesmo dilema frequentemente, me perguntando se e como deveria quebrar commits que estavam lidando com áreas funcionais diferentes; só muito mais tarde percebi que ter todas essas áreas funcionais diferentes em um único projeto comprometível era, em si mesmo, uma grande falha de design.

Eu ainda encontro bugs totalmente não relacionados com frequência enquanto estou trabalhando em um recurso específico. Posso estar trabalhando na IU e encontrar um bug em alguma lógica de negócios e ter que consertá-lo antes de prosseguir. A diferença é que a lógica de negócios está sempre em uma montagem/projeto diferente da IU, então tudo o que tenho a fazer é fazer uma pequena alteração em o BL e prossiga com um commit bem menor, então continue trabalhando.

Ter uma organização de projeto realmente boa torna não apenas possível, mas bastante fácil de lidar com esses problemas sem enterrar uma mudança, interromper a compilação ou ficar atolado em um irritante branch/merge (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 voz na organização do projeto - então eu simplesmente seguiria com o nº 1 e faria as anotações apropriadas no registro para que outras pessoas soubessem por que você fez o que fez. Se você fez uma alteração importante , envie também um relatório de bug em seu sistema de rastreamento de problemas para dar visibilidade ao que você corrigiu e por quê.

4
Aaronaught

Normalmente, apenas conserto o bug e continuo o que estava trabalhando. Quando é hora de fazer o commit, assumindo que a correção do bug está em um arquivo separado, eu faço dois commits simultâneos - o primeiro é um commit parcial contendo apenas a correção do bug, e a segunda é todo o resto.

3

Eu conserto o bug e faço commits separados, um para cada correção/recurso.

Na maioria das vezes, as mudanças não estão no mesmo arquivo, então é fácil separar os commits. Se as alterações estão no mesmo arquivo, eu uso o TortoiseHg (um front-end de interface gráfica do usuário) para selecionar precisamente as diferenças que desejo enviar (acho que é possível fazer isso na linha de comando com o extensão do registro, mas é menos conveniente).

Algumas pessoas usam o Mercurial Queues para isolar as pequenas correções ao trabalhar em um recurso. As pequenas correções são empilhadas no MQ e, quando o recurso é concluído e confirmado, o conteúdo da fila também é confirmado (um changeset para cada entrada na fila).

1
barjak

Tento fazer o # 2. Se for realmente um problema separado, é provável que esteja em um arquivo diferente daquele em que você está trabalhando. Você deve ser capaz de verificar o arquivo como um commit separado, mesmo se for feito no mesmo repositório em que você está trabalhando. Por todas as razões já mencionadas, faz sentido ter commits o mais independentes possível, para rastrear e reverter a mudança se ela estiver errada.

1
KeithB

Resposta curta: # 2. Você realmente quer aquela correção de bug (com sua nota em seu tracker!) Marcada em seu histórico de versão como uma entidade separada.

Resposta mais longa:

  • Tropeçar no bug
  • Escreva um teste ou mais demonstrando o bug
  • Faça o teste passar
  • Comprometa apenas essa mudança e seus testes (git add --interactive ou darcs record -i ou como seu VCS faz) (*)
  • Volte para o que eu estava fazendo.

(*) No CVS (não, realmente), às vezes eu faço check-out de uma árvore limpa, bem como uma cópia na qual trabalho. Então eu uso um merge - winmerge, no meu caso - para puxar apenas a correção do bug para a árvore limpa para que eu possa confirmá-la separadamente. (A outra opção é renomear seus arquivos alterados, cvs update e mesclar. Depois de confirmar a alteração, remova o arquivo e renomeie os arquivos movidos de volta aos nomes originais.)

Algo a se notar, entretanto, é 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 bugs em partes não relacionadas da base de código - por que você está lendo código não relacionado ao consertar o bug? (Sim, isso é exatamente o oposto do que Aaronnaught diz!)

1
Frank Shearar

Nós fazemos # 1. # 2 soa bem, mas não posso dizer que tivemos problemas com o # 1 que o # 2 resolveria.

Um fator adicional em minha empresa é que criamos aplicativos da web, e nosso teste é 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 de fazer o check-in. Dividir os commits 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, que nos permitiria fazer commits menores, mas simplesmente não temos.

0
Tom Anderson

Eu geralmente faço o # 2. Salvar meu trabalho atual em outro lugar: geralmente funciona bem criando um patch. Além disso, alguns IDEs (IntelliJ) permitem mudanças de prateleiras que é exatamente isso: salve o trabalho atual em outro lugar.

0
michid

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

Se estiver tudo misturado com os arquivos que alterei pela metade, não posso construir e testar essa parte independentemente. Nesse caso, eu faço outro WI para ele e quando eu verifico minhas alterações eu resolvo ambos os WIs com o mesmo check-in, o que geralmente vai 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 alterei aleatoriamente aquele código naquele dia, e um WI é atribuído a outra pessoa para confirmar que está correto agora.

0
Kate Gregory