A Dor Real — Quando a arquitetura pesa mais que o problema
Não existe nada mais irritante do que abrir um projeto e perceber que ele tem mais camadas que funcionalidade. A tal “arquitetura corporativa avançada” vira um castelo de cartas: DIP para todo lado, interfaces vazias, camadas que só repassam chamadas, e a famigerada “flexibilidade” que nunca é usada.
O pior é que o dev das trincheiras sofre. Debug fica lento. Código vira burocracia. A entrega do negócio emperra. **Complexidade acidental vira dívida técnica disfarçada de boas práticas.**
Go foi criado justamente para evitar isso. Como já disse Rob Pike, simplicidade é difícil. Mas quando você acerta, ela vira poder.
A Solução Pragmática — Go força você a pensar no essencial
Go não incentiva abstrações desnecessárias. Não pede herança. Não empurra mágica. Não permite que você esconda sua própria bagunça em uma floresta de padrões.
O resultado? Serviços diretos, legíveis, previsíveis e fáceis de manter.
Quando o foco do projeto é entregar valor e não montar um museu de padrões, Go brilha. Especialmente em sistemas distribuídos, concorrência e serviços de backend que precisam ser rápidos, confiáveis e simples de operar.
Implementação de Senior — Como a simplicidade se traduz no código
Aqui vai um exemplo direto de como criar um serviço HTTP limpo, testável e sem “gourmetizações”:
package main
import (
"encoding/json"
"log"
"net/http"
)
type HealthResponse struct {
Status string `json:"status"`
}
func healthHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
json.NewEncoder(w).Encode(HealthResponse{Status: "ok"})
}
func main() {
http.HandleFunc("/health", healthHandler)
log.Println("Server running on :8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}
Sem framework gigantesco. Sem camadas artificiais. Só o necessário para entregar um endpoint funcional, claro e com manutenção barata.
Quer testar? É simples, porque a função é pura e direta.
func TestHealthHandler(t *testing.T) {
req := httptest.NewRequest("GET", "/health", nil)
w := httptest.NewRecorder()
healthHandler(w, req)
if w.Code != http.StatusOK {
t.Fatalf("expected 200, got %d", w.Code)
}
}
O código fala por si. Quando a linguagem já te empurra para o simples, abusar vira mais difícil.
O Custo da Escolha — Quando a simplicidade não é suficiente
Nem tudo são flores. Usar Go significa aceitar algumas trocas:
- Você não tem herança nem generics complexos (e isso é bom na maior parte do tempo).
- Frameworks “full stack” não são a vibe da linguagem — você vai precisar escrever mais código explícito.
- Se sua equipe está acostumada a padrões pesados, a transição pode gerar atrito.
Mas o ponto é simples: **o custo de adotar Go quase sempre é menor que o custo causado por arquiteturas desnecessariamente complexas.**
Direto das Trincheiras — 3 lições reais
- Se a camada existe apenas para “seguir padrões”, provavelmente ela não precisa existir.
- Em Go, teste é substituto melhor de abstração. Teste muito, abstraia pouco.
- Simplicidade não é falta de técnica — é disciplina para cortar tudo que não traz valor.
Fontes utilizadas
dotGo 2015 – Rob Pike – A simplicidade é complicada : r/golang,
Por que Go? : r/golang – Reddit,
Simplexity — A incrível missão de extrair a simplicidade da complexidade (GoCool),
Escreva um código Go melhor — ferramentas de análise estática
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descasquemos outros hypes da nossa área.
Valeu e até a próxima! 😉
