Qual é o termo para um commit realmente grande do código fonte? [fechadas]

37

Às vezes, quando verificamos o histórico de commits de um software, podemos ver que existem alguns commits que são realmente GRANDES - eles podem alterar 10 ou 20 arquivos com centenas de linhas de código-fonte alteradas (delta). Lembro-me de que existe um termo comumente usado para o BIG commit, mas não consigo lembrar exatamente o que é esse termo. Alguém pode me ajudar? Qual é o termo que os programadores costumam usar para se referir a tais grandes e gigantescos commits?

A BTW está cometendo muitas mudanças, uma boa prática em conjunto?

ATUALIZAÇÃO: obrigada pela discussão inspiradora! Mas eu acho que "code bomb" é o termo que estou procurando.

    
por Ida 13.06.2012 / 17:11
fonte

8 respostas

50

(1) Ben Collins-Sussman : "..." código bombas ". Isto é, o que você faz quando alguém aparece em um projeto de código aberto com um novo recurso gigantesco que levou meses para ser escrito? Quem tem tempo para revisar milhares de linhas de código? ..."

(2) Dan Fabulich : " A bomba de código, ou: O novato com grandes idéias ... Uma bomba de código é um patch que é tão grande que ninguém pode revisá-lo. "

(3) Google Summer of Code: Diretrizes : "Confirmar com antecedência, comprometer-se com frequência ... Por favor, não trabalhe o dia todo e, em seguida, empurre tudo para fora em um único code bomb . Em vez disso, todo commit deve ser auto-suficiente para uma única tarefa, que deve ser resumida na mensagem de log. "

(4) Jeff Atwood : "código-bombas ... Regra 30: Não fique escuro .

    
por 14.06.2012 / 07:30
fonte
38

Provavelmente chamamos de comprometimento ruim . :)

Má Prática

E sim, isso seria geralmente considerado uma prática ruim , pois tem os efeitos negativos de:

  • dificultando a revisão ,
  • tornando difícil de entender com facilidade e rapidez a intenção original do commit ,
  • tornando difícil ver como isso afetou o código para corrigir ou resolver explicitamente um problema ,
  • tornando difícil saber se o tamanho do commit é devido ao ruído de outras alterações possivelmente não relacionadas (por exemplo, pequenas limpezas ou outras tarefas).

Casos aceitáveis

No entanto, você pode ter casos em que grandes commits são perfeitamente aceitáveis . Por exemplo:

  • ao mesclar as agências ,
  • quando adiciona novas fontes a partir de outra base de código sem versão,
  • quando substitui um recurso grande no local (embora você prefira fazer isso em uma ramificação, com pequenas confirmações abordando diferentes partes da alteração e mesclar tudo de volta, para que você possa ter uma janela melhor sobre o desenvolvimento incremental do recurso e os problemas que podem ter sido encontrados ao longo do caminho),
  • ao refatorar uma API afetando muitas classes descendentes e consumidoras.

Assim, sempre que possível, prefira os tipos de commits "strike" cirúrgico (e vincule-os a IDs de tarefa no rastreador de problemas!). Se você tiver um motivo válido, vá em frente.

Além disso, eu realmente não sei e acho que nunca ouvi um nome especial para um commit grande. Um monstro-commit? Um fat-commit?

Atualização: Os links de resposta de David Cary a atores notáveis de TI usando o termo < strong> "code-bomb" (mais importante, Collins-Sussman, criador original do Subversion ). Assim (embora até agora eu não possa dizer que ouvi com frequência).

    
por 13.06.2012 / 17:12
fonte
12

BTW, is committing a lot of changes all together a good practice?

Bem, não é uma boa prática manter as alterações por um longo tempo e implementar uma variedade de recursos e correções de bugs, e então confirmá-los, o que é uma maneira de um grande commit acontecer.

Outra maneira de isso acontecer é se uma refatoração alterar a assinatura de uma função amplamente usada e, em seguida, todas elas precisarem ser alteradas. Isso não é necessariamente ruim, e eu não quero que os desenvolvedores evitem limpar o código por medo de cruzar algum limite.

Então, há mais do que apenas olhar o número de arquivos tocados em um commit.

    
por 13.06.2012 / 17:17
fonte
8

O termo que ouvi é "chunky check-ins" . E eu não sou fã deles. Eu gosto de commits menores que garantem que nada mais seja quebrado em um passo razoável em um projeto. O grande commit é geralmente repleto de problemas que reverberam por algum tempo quando isso acontece.

    
por 13.06.2012 / 17:24
fonte
3

Eu chamo de "commit típico do SVN" ou "amanhã é o commit do dia do lançamento"

Por mais que eu goste do SVN, só estou desanimado pelo fato de não poder fazer commits locais.

EDIT: eles geralmente têm as palavras "stuff" e "cerveja" na mensagem de commit.

EDITAR DE NOVO: Cometer muitas mudanças, embora não seja necessariamente uma má prática, deve ser o mais possível evitado. Acho mais fácil revisar uma revisão / confirmação que é curta e concisa. (emparelhado com uma mensagem de commit bem escrita, veja minha edição anterior por um mau exemplo)

    
por 14.06.2012 / 03:20
fonte
2

Um "pedaço fumegante de código". : -)

    
por 14.06.2012 / 00:35
fonte
2
  • commit inicial - o projeto que não estava sob controle de revisão foi lançado no SVN
  • refatoração - o arquiteto tem uma idéia brilhante sobre a mudança de nomes de classes de / para Convenção de nomenclatura Smurf ou alterou a raiz da hierarquia de pacotes
  • formato de código - o arquiteto decidiu alterar o recuo de código de 4 para 3 espaços ou alterar os términos de linha do Unix para o Windows (ou reverter)
  • Friday commit - Joe está sempre dedicando o seu trabalho semanal às sextas-feiras às 16:30
  • uuups commit - Ted deletou por engano o diretório raiz, confirmou isso, e agora ele volta a hierarquizar toda a hierarquia de arquivos no SVN
por 15.06.2012 / 15:43
fonte
0
Geralmente, muitas pessoas tendem a fazer grandes commits usando o VCS centralizado, especialmente o servidor que impõe uma boa política de commit. Essa é a confirmação que deve passar em todos os testes e os testes demoram mais tempo (mais do que alguns segundos). Portanto, os desenvolvedores não querem esperar tanto tempo para cometer várias vezes e dividir as alterações em vários pequenos commits.

E os desenvolvedores que são verdes para o VCS podem esquecer de dividir as alterações em vários pequenos commits. Eles só se lembram de se comprometer quando liberam o programa para a equipe de controle de qualidade. Pior ainda, para evitar que outros vejam código com bugs, eles não se comprometem antes de passar no teste de QA com sucesso. Por último, eles não perceberam que eles comprometeram binários de saída, arquivos temporários e saídas de vinculação, o que realmente produz um commit "grande".

    
por 15.06.2012 / 13:00
fonte