A vida é muito curta pra fazer software ruim

<rant mode="on">

Um dos lemas de uma das empresas que trabalhei era algo parecido com isso. Vinha estampado em um mug e em uma camisa que a empresa distribuía para novos funcionários.

É um mote interessante e faz bastante sentido.

Como desenvolvedores passamos a maior parte do nosso tempo acordado escrevendo código. E, a não ser que seja uma apenas uma questão de receber um salário no final do mês ou incompetência — não no sentido pejorativo, mas no sentido literal da palavra, ou seja, falta de conhecimento ou competência — , é bastante normal que queiramos escrever o melhor código possível.

O problema surge quando, contra a nossa vontade, "precisamos" escrever código ruim. Explico:

Essa semana o cliente decidiu que precisava entregar uma nova tela de uma funcionalidade já existente no sistema legado. Esse sistema está prestes a entrar em freeze mode pois será substituído em um futuro muito próximo (bom, essa é a promessa e expectativa). A "nova funcionalidade" vai para o Kanban Board e é priorizada para a próxima entrega.

Como não conhecia a fundo essa parte do sistema resolvi dar uma navegada inocente por ele e entender um pouco melhor do que se tratava a dita: uma tela com 5 ou 6 campos e um """componente""" (veja bem…) daqueles de transferência de itens de uma lista para outra.

Dada a lógica necessária para fazer o que a funcionalidade se prestava, parecia bastante simples. EU SEI que o sistema tem regras muito, muito, muito (é um pouco mais do que isso, mas vou economizar na digitação) específicas. Afinal, além de ser um monolito-que-atende-tudo-e-a-todos, precisa atender alguns requisitos regulatórios. Contudo, enganado estava eu.

Não, a regras não são o problema. Não o tempo para o desenvolvimento não é o problema. O problema é o código. Sim, ele. Olhando bem de perto, o desânimo bate com força. Respiro fundo e vou tomar um café já começando a pensar em como substituir aquilo que vi. O café está com um gosto amargo mas não é a falta de açúcar. É a falta de alternativas pra resolver o problema em questão.

30–40min e nada. A luz que aparece no final do túnel vem na minha direção rapidamente: é um trem em alta velocidade.

Estratégia na cabeça e vamos para o divide-and-conquer. Vamos "fatiar" o problema e tentar fazer a coisa acontecer. Primeira alteração, primeiro build, primeiro redeploy e… Até que não foi tão doloroso. Pego a segunda fatia e vamos pra cima. Outro build, outro deploy e… e… Mas peraí… Porque aquele campo agora gera um alert()? Dou uma olhada no código. Nada alí na chamada da função. Opa, tem uma chamada pra um outro método aqui… Busco visualmente no código e não encontro a declaração. Deve estar em outro arquivo .js. Procuro na árvore da IDE um arquivo com o nome que vislumbre algo correlacionado. Nada. E, já que estamos numa IDE, vamos usá-la. Find in Files tá aí pra isso…

4h depois estou "reescrevendo" toda a funcionalidade usando o pouco do que é aproveitável do código original. Mas, como estou preso ao que é o padrão do sistema, não é nada do que eu possa me orgulhar. Nada mesmo. Orgulho zero. Uma sensação de tempo jogado fora. Tempo que não terei de volta.

Aí lembro que, quando foi solicitada essa alteração, argumentei se não seria o caso de implementar um botão, no máximo um checkbox, na tela de coleta de dados para gerar a informação necessária. A mesma informação que a funcionalidade que estamos substituindo gera a posteriori. Ela poderia deixar de existir. Pior. Poderia nunca ter existido.

</rant>