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.

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"

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.

Pequena correção.

Não tem regras não escritas do Go Horse. Estão todas escritas no sagrado endereço: https://gohorse.com.br/extreme-go-horse-xgh/ Disponivel a todos os que desejam beber da sabedoria do Extreme Go Horse.

Cobra quem? não está fazendo XGH direito, quando ver que o barco estiver afundando é só pular antes! XD