O código e a história

Há um dilema que me atormenta: manter o histórico de um projeto para que, quando se está trabalhando sozinho? Vale a pena o esforço?

Eu tentei utilizar várias ferramentas: cvs, subversion, bazar e o git. Todas são bem interessantes no início, mas se tornam bem “chatinhas” depois de uma ou duas semanas. Parecem pedras no caminho. Temos que ficar parando e documentando, analisando código velho e ainda por cima borrando idéias novas.

Mas nunca perdi a vontade de manter o histórico evolutivo de um projeto e, mesmo sem muita habilidade, venho fazendo isto.

Recentemente recuperei e “reprisei” a evolução de um projeto do qual havia feito o “breadcrumb” por um mês. Note aqui que o meu “breadcrumb” é o de alterações no projeto, não a técnica utilizada para navegação em sites.

Foi uma experiência interessante pois retomei um projeto do zero, iniciado em nov/2008 e concluído em dez/2008. Foi como ver um filme antigo antes de tentar reescrever uma nova etapa. Mas o que me deixou chateado foi que eu já havia usado várias ferramentas antes do bazar, que estava no controle daquele final de projeto (eu ainda não havia usado o git).

Tentei por todo o jeito importar diretamente do bazar para o git mas sem sucesso. Daí parti para rever o código usando o bzr mesmo. Depois de umas três horas testando recolocando e analisando os resultados com o bzr diff, “reaprendi” como eu tinha feito o projeto que estava meio apagado da minha memória, após alguns anos. Em seguida percebi que o curto período avaliado registraram grandes modificações no meu modo de pensar – em questão de dois meses, muda-se muito de idéia. Mas restava a frustração de não ter o histórico completo.

Há pouco, baixei o repositório do kernel do linux e pensei: como era a versão 0.0.1 do sistema? Será que vou ver o “initial import” do linux? Legal!

Mandei um git log > /tmp/log e fui avaliar !

Eis a minha surpresa:

4002798 commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
4002799 Author: Linus Torvalds <torvalds@ppc970.osdl.org>
4002800 Date:   Sat Apr 16 15:20:36 2005 -0700
4002801
4002802     Linux-2.6.12-rc2
4002803
4002804     Initial git repository build. I'm not bothering with the full history,
4002805     even though we have it. We can create a separate "historical" git
4002806     archive of that later if we want to, and in the meantime it's about
4002807     3.2GB when imported into git - space that would just make the early
4002808     git days unnecessarily complicated, when we don't have a lot of good
4002809     infrastructure for it.
4002810
4002811     Let it rip!

Pelo jeito, o problema de se perder o histórico aconteceu inclusive com o autor do linux e do git.

Independente da minha frustração, fiquei satisfeito por ver que o “modo” de pensar, em termos de controle de versões, é problemático também por quem tem muita habilidade.

Repasso, então, a lição aprendida: priorize o resultado e faça a história depois. Mas faça, o código e a história!

Anúncios

2 comentários sobre “O código e a história

  1. Sou um adepto aos sistemas de controle de versão somente para projetos que são levados à cabo por equipes de desenvolvimento. Quando existe um lone programmer envolvido não acredito que o controle de versão seja assim tão útil.

    Minha experiência neste sentido é que manter archives com os respectivos ChangeLogs dão melhor resultado. Além do ChangeLog, uma lista de “coisas para fazer” também ajuda…

    Outra prática minha é comentar, à exaustão, o código-fonte, que deve ser modular o suficiente para isolar os seus pedaços sem que um interfira muito no outro.

    Outra coisa: ultimamente tenho gostado mais de trabalhar com o svn ou o git… cvs não me agrada nem um pouco. Assim como não me agrada o famigerado Visual Source Safe, da M$…

    1. A utilidade no meu caso se aplica à duas coisas:
      – acompanhamento da minha própria evolução em testes
      – branches de códigos prontos para outros projetos que acabam voltado para um só em merges

      Sim, o código deve ser exaustivamente comentado, mas no “calor da batalha”, acabo fazendo “provas de conceitos” (bad practices) e ao voltar ao código original, nem sempre é um caminho retilíneo, pois normalmente meus projetos seguem horizontalmente – gosto de explorar várias possibilidades antes de decidir por uma (verticalizar)
      Concordo que no estilo verticalizado, o controle de verão é bem improdutivo para produções “solo”. Ao desenvolver scripts isto fica bem visível.

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s