Executando verificação de segurança...
6

Go Horse: A Filosofia de Programação Que Resolve Agora, Mas Cobra Depois!

Todo dev já passou por isso: cliente cobrando, prazo estourado, e você só quer que o código funcione, de qualquer jeito. É nessa hora que surge o Go Horse, a famosa filosofia não oficial da programação com um lema simples: se funcionou, tá ótimo. Vamos falar sobre essa abordagem, por que ela ainda é tão usada e onde ela pode te levar.

O Que é Go Horse?

O Go Horse é aquela abordagem de desenvolvimento rápida e improvisada, onde o objetivo é só um: entregar o que foi pedido. Boas práticas, testes e arquitetura? Não hoje. Aqui, o lema é "faz rodar agora, depois a gente vê". Se você já ignorou uma regra de código limpa ou pulou testes só pra conseguir entregar algo, bem-vindo ao Go Horse.

Na prática, significa cortar etapas importantes, como planejamento e validação, para fazer o projeto andar. Isso pode funcionar bem em curtos prazos, mas, a longo prazo, pode gerar sérios problemas.

As Leis Não Escritas do Go Horse

  • Funcionou? Tá ótimo!: Se o código rodou, é missão cumprida. A qualidade do código é secundária quando a meta é cumprir o prazo.
  • Documentação? Só se sobrar tempo: O código funciona e você tem memória boa, certo? Então pra que parar pra documentar? (Spoiler: vai fazer falta mais tarde).
  • Teste é na produção: Pra que fazer testes locais ou automatizados se você pode descobrir os bugs no ambiente real?
  • Gambiarra é solução: Se uma gambiarra resolve o problema agora, é a melhor solução. Afinal, "depois a gente refatora".
  • Refatorar é luxo: O código está rodando. Se mexer, pode parar de funcionar. Melhor deixar como está.
  • Correção ao vivo: Ajustes direto na produção, porque fazer isso em ambiente de teste não dá a mesma adrenalina.

O Preço do Go Horse

O problema do Go Horse é que ele funciona... mas só no curto prazo. A dívida técnica, ou seja, o acúmulo de problemas e gambiarras que precisam ser resolvidos, vai crescendo, e um dia alguém (provavelmente você) vai ter que encarar isso. O código vai ficando confuso, difícil de manter e cheio de armadilhas.

Além disso, a falta de testes e boas práticas aumenta o risco de bugs críticos aparecerem em momentos inconvenientes, como no meio de uma entrega importante para o cliente. E quando esses problemas surgem, o retrabalho é inevitável.

Por Que o Go Horse Sobrevive?

Apesar dos problemas, o Go Horse continua vivo em muitas equipes. Isso acontece porque ele entrega rápido. Quando o prazo já passou e o cliente está pressionando, o Go Horse dá resultados imediatos. Não é o código mais limpo, nem o mais eficiente, mas resolve na hora.

Em projetos experimentais ou protótipos, onde a velocidade é mais importante que a perfeição, ele pode ser útil. Mas se você seguir nesse ritmo por muito tempo, o resultado será um código impossível de manter.

Como Evitar o Go Horse: Alternativas Simples

Para não cair nas armadilhas do Go Horse, existem alternativas simples que podem ser aplicadas no dia a dia:

  1. Testes básicos: Não precisa de uma suíte de testes supercomplexa, mas incluir testes mínimos ajuda a evitar problemas maiores na produção.
  2. Documentação leve: Não precisa de uma documentação completa, mas anotar pontos-chave do sistema já ajuda muito a evitar dores de cabeça no futuro.
  3. Correções planejadas: Tente evitar correções direto na produção. Um ambiente de teste básico pode evitar grandes catástrofes.
  4. Refatoração contínua: Ao invés de deixar a bagunça crescer, faça melhorias pequenas e constantes no código. Isso mantém a qualidade sem exigir grandes reformulações.

Conclusão: Cavalgar Com Cautela

O Go Horse já salvou muitos devs na corrida contra o tempo, mas ele tem seu preço. Saber quando usar essa abordagem e quando parar para respirar, organizar e melhorar o código é o segredo para não transformar pequenos problemas em grandes pesadelos.

Use o Go Horse com moderação e, sempre que possível, invista em um mínimo de boas práticas. Afinal, uma hora o cavalo cansa, e ninguém quer estar na posição de consertar a bagunça depois.

Carregando publicação patrocinada...
2

boa noite, sr.

go horse é uma filosofia para situação de guerra, pelo que aprendi neste post.

aprendi também que estou em guerra constante, com o inimigo prazo e com os irmãos de pátria chamados colegas de trabalho, também, pois é muito difícil engajar as pessoas em seguirem uma metodologia.

o sr é técnico? o sr é líder?
em que o sr trabalha?
qual tua senioridade?

por que escolheu este assunto para ser teu primeiro post aqui na plataforma?

o que o sr poderia contribuir na problemática de mitigar o uso de go horse nas nossas empresas?
pensando na posição de um líder mais técnico, uma pessoa com posição de tomar decisões.
sem pensar no "eles estão sendo pagos"

1

Fala, dev!

Sei bem como é quando o prazo estoura e o código precisa rodar a qualquer custo, já usei o famoso Go Horse em vários projetos urgentes, especialmente na correria de ser Tech Leader. Às vezes, é a única saída. Mas com o tempo percebi que, apesar de funcionar no curto prazo, o custo vem depois.

O segredo é tentar equilibrar. Mesmo em situações apertadas, dá pra manter um mínimo de qualidade. Não precisa exagerar nos testes, mas garantir o básico já evita grandes dores de cabeça.

E refatorar aos poucos é essencial. Não precisa parar tudo pra fazer uma grande reformulação. Pequenas melhorias constantes já impedem que o código vire uma bola de neve.

No final das contas, é evitar que a dívida técnica cresça tanto que te sabote lá na frente.

2
1