Esse é o segundo artigo de uma série falando de ambiente mínimo, o primeiro foi sobre o uso do terminal e navegador. Nesse eu quero comentar sobre como que podemos lidar com nossos repositórios de código, também levando em conta a questão de um ambiente mínimo e enxuto.

Algum tempo atrás eu estava tarde da noite em um posto de rodovia e decidi pedir um lanche, se não me engano, um bauru, enquanto esperava o ônibus retornar a viagem. Havia acabado de acordar e enquanto o chapeiro fazia o lanche, fiquei observando como ele executava todos os procedimentos necessários. O rapaz era de uma eficiência tremenda, pegava os pedidos no balcão, via quais eram os grelhados necessários, e enquanto lidava com os que já estavam na chapa, tomando cuidado para não passarem do ponto, colocava os novos e ia montando os lanches com os que já estavam prontos. Naquela hora da madrugada, devia ser lá pelas 2 ou 3 da manhã, havia um movimento até considerável, era um posto ótimo, e eu que havia acordado faziam poucos minutos ficava vendo esse procedimento todo de forma quase hipnótica. No final, após todos os lanches prontos, o rapaz, mantendo a velocidade e eficiência, pega a espátula, raspa e limpa toda a chapa, jogando algumas poucas sobras no local reservado para isso. Nessa hora, me bateu a idéia de uma analogia com o desenvolvimento de software.

Com a facilidade e praticidade da utilização de repositórios de código, seja em um computador próprio, seja na nuvem com serviços como o Github, Bitbucket ou Gitlab, algumas vezes nós temos o hábito de clonar o repositório e trabalhar nele em nossos computadores pessoais por meses, ou até anos, somente fazendo nossos commits e pushes para o repositório remoto. Isso funciona sem problemas, mas não exercitamos algo que na minha opinião é primordial para ter um repositório enxuto e um projeto que não apresenta surpresas: apagar o repositório remoto após fazer o seu trabalho, enviando seus commits para o repositório remoto.

Já faz anos que eu sigo essa prática. No meu computador, não tem absolutamente nada de código de qualquer projeto que eu trabalhe, seja nos da minha empresa, a Bluefish, seja nos dos clientes à que nós prestamos serviço. Minha rotina é chegar no trabalho, clonar o projeto, trabalhar nele e no final do período enviar os commmits para o repositório remoto e fazer igual o rapaz da chapa: apagar o código e limpar o ambiente, deixando pronto para a próxima rodada. Isso nos dá alguns benefícios:

• Você não fica com código no computador. Se aparecer algum maluco querendo te roubar ele (eu lembro de um conhecido contando que em plena Avenida Paulista apareceu um desses apontando uma arma e pedindo o "liplop" - o sujeito entregou tudo que tinha até se tocar que era o laptop) o sujeito vai ter uma "casquinha" sem dados. Como você particionou o seu disco e separou a /home, criptografando ela (ah vá, você fez isso, correto?) se o código estivesse lá na partição criptografada ele seria difícil de recuperar. Se ele não estiver lá então, melhor ainda.

• Você descobre que tem alguma coisa muito errada com o seu repositório quando ele começa a demorar para clonar do repositório remoto. Se você deixa ele por meses e anos no seu computador, não faz idéia disso. Aí você descobre que existem arquivos que não deveriam estar ali e que alguém inadvertidamente incluiu para controle no VCS. Dá-lhe filter-branch para consertar isso. E quanto mais você demora para perceber isso, com certeza mais demora para se tocar que esses arquivos estão lá e que talvez alguns outros estejam sendo adicionados. É o tipo de situação que tem que ser conversada o quanto antes com a equipe.

• Você descobre que para rodar o projeto eram necessárias trocentas configurações, entre variáveis de ambiente, arquivos, serviços disparados etc, que são muito fáceis de esquecer se você não automatiza e/ou deixa as configurações prontas quando pega o código em um ambiente "limpo". E acreditem, após meses ou mesmo anos com o repositório "grudado" no computador pessoal, você vai esquecer de uma coisa ou outra naquele esquema "ah, eu vou configurar aqui e depois eu arrumo". Não se enganem em pensar que na correria do dia a dia esse tipo de coisa que você arruma em 1 minuto não vai ser esquecida e ter reflexos mais tarde.

• Você está utilizando uma ferramenta como o Rails e descobre que na hora de rodar todas as migrations, alguém que se achou muito esperto foi lá em uma migration do passado e alterou uma determinada tabela para preencher uma coluna que só existirá em uma migration do futuro. Aí você pega 2 erros: migration não é lugar de preencher dados, lugar disso é no arquivo de seeds, e alterar uma migration do passado não é uma boa prática, o correto é fazer uma nova.

• Você descobre que algumas das configurações do seu projeto só estão funcionando porque são configurações de outro projeto que está no mesmo computador. Por exemplo, em algum outro projeto está sendo declarada uma variável de ambiente que ambos projetos compartilham, mas quando um sumir, o outro para de funcionar.

• Você descobre que a equipe está fazendo essas configurações cada um de um jeito, que no final atendem o que o projeto precisa, mas que não criam um padrão para rodar o projeto de forma eficiente.

• Você descobre que a sua suíte de testes está "contaminada": ela foi configurada com algumas "gambiarras" locais que quando você pega o código do zero, vai fazer com que ela quebre e você fique procurando porque diabos ela não roda mais sendo que "pô, ontem estava tudo certinho".

Deixar o código muito tempo parado no mesmo lugar, sem exercitar ele dessa forma, acaba fazendo com que ele crie "vícios" e raízes com o ambiente onde ele está sendo desenvolvido. Existe o termo code smell, que se refere à alguns sintomas no código fonte que podem indicar um problema mais profundo, se referindo à como o código é desenvolvido, as métricas envolvidas, etc.

Nesse caso, tomo a liberdade de chamar esse tipo de reflexo de código que fica muito tempo em um ambiente sem se exercitar em um ambiente limpo de code taste, ou seja, código que fica tanto tempo em um mesmo lugar que começa a criar um determinado "sabor", um "gosto", pois está ficando "defumado", "marinado", impregnado com todo o ambiente em que ele se encontra, ambiente esse que não foi devidamente sanitizado entre todos os projetos que ele contém e acaba "contaminando" um projeto seja com o ambiente já "azeitado" seja contaminando com outro.

O esquema é fazer parecido com o rapaz da chapa: assim que termina uma determinada "leva" de grelhados, na qual ele não grelha mais que 2 ou 3, ele limpa o ambiente, o deixando pronto para a próxima rodada, sem deixar resquícios que possam interferir nos outros. Pedir um bauru e vir um pedaço de hambúrguer seria estranho, assim como um filé de frango com gosto de costela. Cuidar e limpar o ambiente de trabalho é uma necessidade para a produção de melhores resultados.

Experimentem, não deixem o seu código criar um gosto estranho.

Comentários

Comentários fechados.

Sem nenhum comentário.