Eustáquio Rangel

Desenvolvedor, pai, metalhead, ciclista

Ambiente mínimo - Driver Driven Development

Publicado em Developer


Foto: Pixbay

Em um post anterior dessa série, eu havia comentado o code taste, o "gosto" que o seu código pode deixar se ficar muito tempo em determinado lugar, sem que você crie o hábito de limpar o ambiente de vez em quando. Essa semana tive uma experiência onde encontrei uma situação parecida em que fiz uma analogia interessante para o cliente, levando em conta que é um projeto que utiliza Ruby on Rails.

E o carro estava na garagem ...

Imaginem que somos mecânicos de automóveis. Todos os carros tem características similares, como ter 4 rodas, 2 eixos, motor, portas, etc., com alguns com características bem peculiares, "tunados". Os carros são os projetos de software, e como bons mecânicos, sabemos como lidar com as características comuns na maioria deles em um primeiro momento e em um segundo momento, das mais específicas.

Pois bem, aí chega uma pessoa e diz que tem um carro que está estacionado faz algum tempo na garagem, e queria que você desse uma olhada nele, para que possa trocar o alternador, que está com defeito faz algum tempo. O alternador é uma feature específica do projeto. Ele precisa dessa peça trocada até um determinado dia, ok, vamos lá ver o que dá para fazer.

Você pede acesso à garagem, que é o repositório de código, para que possa dar uma olhada no carro. A pessoa abre a garagem para você e você empurra o carro, que está coberto por uma lona, para fora (clona o repositório). Até esse momento você não tem idéia de que carro que seja, até que dê uma olhada embaixo da lona (começa a dar uma navegada nos arquivos do projeto). Removo a lona, ok, confere, as coisas aparentemente estão no lugar, é um carro, afinal de contas.

Só que aí noto que estão faltando algumas coisas. Tem alguns fusíveis (o database.yml) que não estão no lugar, e sem eles, sem chance de funcionar alguma coisa no carro. Sorte que eu tenho alguns e só preciso perguntar para o cliente se ele lembra quantos ampéres que era o último (o production, que está em variáveis de ambiente, ok). Noto que tem algumas peças bem velhas e que nem precisa mais (a gem therubyracer), removo e ligo os fios direto, pois vai funcionar (tem o node disponível).

Nisso, lembro que a pessoa havia mencionado que havia uma peça faltando no carro (um repositório privado externo que não existe mais) e que ela tinha a peça em casa, vou lá e pego a peça (o código que estava no repositório) e coloco no lugar.

Aí tento abrir o carro, mas a chave (dados de login) que recebi estava quebrada (não fazia login com eles). Tento procurar a reserva, e descubro que tem três chaves reservas, cada uma abre o carro mas troca o layout do painel do carro, que apesar de velho, é digital, para layouts que nunca vi na frente, que são específicos desse carro específico (layout customizado). Mas nenhuma dessas chaves existe, eu tenho os specs delas (características de cada usuário, que encontrei no código), e já ligo o torno para começar a fazer as chaves (alimentar o arquivo seeds). Consigo abrir o carro.

Ele está com combustível mas falta óleo, fluido de freio (faltam dados nos seeds), várias coisas necessárias para que ele possa andar. Eu perco um tempo vendo as especificações no manual do carro (lendo os models e dados necessários para que possa fazer login) e consigo suprir essas necessidades. Eu havia pedido para a pessoa, que tinha todo o conhecimento disso tudo, me enviar os produtos (o dump do banco), mas ela estava sem transporte alternativo (a internet havia caído na região dele), então, tive que fazer na mão mesmo.

Abro a porta, ligo o carro, o painel da primeira chave acende, com um monte de opções customizadas que nunca vi na vida (finalmente fiz login). Ok, algumas são básicas, mas a maioria, não conheço, vou ter que dar uma olhada como funcionam. Uma coisa eu sei, o layout dá para ser melhorado.

Agora finalmente posso concentrar na tarefa mais importante que me foi pedida. Trocar o alternador por um novo. Para isso eu tenho 2 opções:

  1. Trocar a peça anterior pela nova, que é diferente, e pedir para o dono do carro sair acelerando com tudo. Pode dar algum problema, tipo, o carro desligar, pegar fogo, explodir, ou alguma calamidade do tipo, porque não fiz nenhum diagnóstico do carro após ligar a peça nova, só sei que ele começou a rodar.

  2. Ligar o meu laptop ao computador de bordo (suíte de testes) do carro (ei, ele tem um, que bom!) e verificar se está tudo funcionando de acordo com a peça nova. Só que descubro que de todos os recursos disponíveis para teste no computador, quase 50% deles estão falhando! Isso gera muito ruído mesmo que eu concentre somente no alternador. Pergunto para a pessoa se o computador já estava assim mesmo, se estava com problema, se eu posso isolar todos aqueles testes falhando para não gerar ruído no diagnóstico da peça nova, e reforço que é muito importante depois retornar para verificar porque aqueles testes estavam quebrando.

Fico esperando a resposta do dono do carro, assim como as impressões das outras coisas que tive que fazer, mas demora um pouco e o fim do dia já está chegando. Melhor colocar o carro de volta na garagem e aguardar. Aí descubro que a pessoa fechou o cadeado da garagem e levou a chave embora (você não tem direito de escrita no repositório), sorte que tem uma garagem sua perto (um fork) senão o carro iria pernoitar na rua. Para não esquecer tudo o que fiz, eu anoto tudo em um caderninho que tem no carro (o arquivo README).

Driver Driven Development

Como eu já havia comentado no post anterior, parece que peguei um exemplo de code taste, ou seja, com certeza o código rodava, mas em um ambiente onde ele já tinha tudo configurado para tal, ou seja, no computador do desenvolvedor já tinha um database.yml configurado, o banco com todos os dados necessários para fazer login, várias alterações (como comentar aquele repositório externo), etc.

Mas, como uma pessoa nova e de fora, para simplesmente rodar o servidor e fazer login, eu tive que fazer todas essas manobras descritas. assim como qualquer outra pessoa que precise trabalhar com o projeto e não tenha a pessoa que conheça bem ele do lado. Uma vez escutei um professor de faculdade dizer em um mestrado que uma boa documentação ou livro não precisa ter o autor grampeado junto com ela, devendo dar condições de quem a pegar na estante entender o seu conteúdo por si só.

O framework Ruby on Rails nos dá condições para fazer esse tipo de coisa, considerando qualquer desenvolvedor que tenha acesso ao código, permitindo rodar o projeto localmente de maneira fácil, desde que seguidas algumas convenções e práticas, como por exemplo, alimentar adequadamente o seu arquivo de seeds, criar um README com informações que possam ser específicas e principallmente deixar a sua suíte de testes em um estado bom que permita ser executada e melhor, que permita que qualquer pessoa que pegue o projeto possa ler os seus testes e entender como o projeto se comporta.

Pensem que o projeto é um carro, como na analogia. Você só tem que entregar a chave da garagem para que qualquer pessoa que você queira a abra, encontre a chave em cima do capô do carro, abra a porta, dê partida e saia dirigindo. Se precisar mais que isso, talvez seja bom gastar um tempinho dando uma organizada nas coisas. Foque no motorista que vai dirigir o carro, ou seja, o desenvolvedor que vai tocar o seu projeto. Facilite as coisas para o motorista, mesmo que ele seja você.




Comentários

Comentários fechados.

Sem nenhum comentário.

Artigos anteriores