Sobre grandes alterações pequenas

Qual é a granularidade das modificações que você envia ao seu sistema de controle de versão? Você se limita a modificações pequenas (que mudam o nome de uma varíavel ou outra, por exemplo) ou gosta das mas volumosas (como as que mudam o nome de uma rotina, introduzem um parâmetro novo e ainda corrigem um defeito em um pedaço do código que a chamava)?

Não é uma pergunta retórica. Pode responder. O espaço para comentários ali embaixo serve exatamente para isso.

Quando envio patches para algum projeto, tento torná-los tão pequenos e localizados quanto possível. Eu sei que não é uma experiência muito agradável revisar modificações monstruosas que afetam toda a base de código e tento poupar disso os mantenedores dos projetos para os quais colaboro. Eles são programadores, mas também são gente.

Não é tão raro que uma parte das modificações em um patch sejam aceitas e outras não. Caso o patch enviado seja muito extenso, o mantenedor vai ter um bocado de trabalho para separar as partes boas das ruins. Se ele tiver muitas outras preocupações no dia (o que não é nada incomum), pode ser que ele simplesmente recuse todo o patch, apesar de haver mudanças úteis, só para poupar o trabalho de filtragem. Para quem está contribuindo, certamente é melhor que as modificações sejam aceitas e um conjunto de patches pequenos torna as chances disso acontecer muito maiores do que um único patch grande. Nem todo patch que enviamos é aceito e precisamos conviver com isso. Modificações pequenas e localizadas ajudam muito quando algumas delas precisa ser rejeitadas.

Patches pequenos costumam ser mais ortogonais e fazem muito sentido no contexto colaborativo de um projeto de código aberto, principalmente com sistemas de controle de versão distribuídos. Mas ainda existem sistemas centralizados e — pior — cuja única solução para edição concorrente é usar travas para tentar tornar o desenvolvimento serializado e impedir toda e qualquer tentativa de paralelismo. Como se este cenário não fosse suficientemente ruim, alguns sistemas não suportam commits com múltiplas modificações e obrigam todo mundo a registrar alterações arquivo por arquivo, mesmo que toquem em muitos pontos. Para terminar imagine que a única forma de interação da equipe com a ferramenta de controle de versão seja um cliente gráfico com interface do século passado e dificilmente automatizável.

É serio mesmo, essas coisas ainda existem.

E tem gente que precisa usá-las.

Quando o mundo conspira contra você com tanta intensidade, fica mais difícil resistir à tentação de fazer uma modificação monstruosa com um comentário altamente descritivo como “Modificações do código”. Porém, mesmo quando estou em algum ambiente parecido com este, ainda tento fazer modificações pequenas. Não faço alterações tão pequenas como quando estou usando Darcs e vez ou outra combino duas ou três modificações em uma, mas sempre evito registrar uma alteração que resolva mais de um defeito ou melhoria.

Parece haver um certo conflito entre commits localizados e implementação de recursos. A renomeação de uma rotina, por exemplo, pode ser um dos passos que leva à inclusão de uma nova funcionalidade, mas com certeza não vai resolver a bronca sozinha. As funcionalidades precisam de modificações maiores, mas modificações menores são mais fáceis de entender, revisar e reverter. Será que este conflito real ou apenas um produto da nossa imaginação?

4 Responses to “Sobre grandes alterações pequenas”


  1. 1 Raony Araújo 29/ago/2007 às 19\0722

    ideal: commit em cada teste verde e o código que o faz passar (devidamente refatorado);

    de fato: ultimamente só tenho conseguido de grandes pedaços, que englobam estórias inteiras.

  2. 2 Marcos Tapajós 30/ago/2007 às 00\1211

    Eu faço vários commits com pequenas partes de código pelos mesmos motivos que você citou e por usar integração continua com processo completamente automatizado. Fica tão fácil integrar que não tem motivo para demorar muito tempo.

    Um abraço

  3. 3 Alessandro 30/ago/2007 às 16\0457

    Se a alteração estiver fundamentada em testes, não tem problema dela ser realiza em “grande” ou “pequena” escala. Mas senão, até mesmo as pequenas alterações irá prejudicar o trabalho do mantenedor do projeto.

    “É serio mesmo, essas coisas ainda existem.”

    Esse tipo de comentário, não ajuda, pelo contrário, ele faz com que haja fuga do tema. E foi isso que reparei neste post.

  4. 4 thiagoarrais 31/ago/2007 às 12\1222

    Alessandro, testes costumam realmente facilitar muito a vida dos mantenedores. Eu particularmente prefiro receber patches com testes do que sem, e incentivo qualquer um interessado em colaborar com código para minhas aplicações a escrever testes.

    Porém, assim como tudo que consigo pensar, testes não são uma solução mágica para todos os problemas. O esforço necessário para revisar uma alteração cresce junto com o tamanho dela. Há a possibilidade do crescimento ser maior do que linear, já que o pobre mantenedor precisa verificar se o colaborar não introduziu nenhum tipo de efeito colateral. Testes certamente ajudam, mas não eliminam o problema.

    Caso o mantenedor julgue necessário rejeitar algumas das alterações, não seria mais fácil se elas já tivessem sido recebidas separadamente?


Comments are currently closed.




%d blogueiros gostam disto: