Olá, quanto tempo, não é mesmo?! Já faz tanto que não escrevo por aqui que até me senti nostálgico quando vi o editor de texto da hashnode. E ao invés de chegar retomando a série de artigos de PHP para Iniciantes, resolvi falar um pouco do que anda rolando na minha vida primeiro.

Problemas da vida

Primeiramente: não, eu não desisti do blog e tampouco vou deixar a galera do PHP com conteúdo incompleto. Eu apenas não estou conseguindo conciliar meus horários na vida, saca? A ponto de que está faltando horas no dia-a-dia pra fazer outras coisas também, que tem mais prioridades que o blog.

Quê?! Como ousa priorizar outra coisa, Kiko?!

Infelizmente, a idade chega para todos... E minhas filhas estão prestes a fazer 3 aninhos! HEHEHE Pensou que eu ia dar uma desculpa de idoso, né? Calma lá, eu ainda vou fazer 30, mas é lá pro Halloween. Porém minha saúde não anda tão bem assim. Eu precisei fazer uma super bateria de exames de cardio e... Deu tudo ok, não tenho problema algum fora obesidade e uma dor esquisita no calcanhar. Ainda preciso ir no ortopedista ver isso e só depois voltar a frequentar o oftalmologista para terminar as sessões de cirurgia a laser e concluir exames de glaucoma.

RESUMINDO: tem muita coisa de saúde pra tratar. E não é só a minha saúde! Minhas filhas estão tendo crises asmáticas desde semana passada e eu sigo torrando grana com remédios, médicos, etc. Tratamento exaustivo é outro rolê, em duas crianças então... Nem se fala.

Se você julgava a minha falta de tempo, espero que tenha um bom julgamento agora, rs.

Voltando ao blog

Mesmo faltando tempo pra tudo, eu não deixo de acompanhar a galera no Twitter. Às vezes eu solto meus recados por lá e consigo interagir com quem lê meus artigos. Uma das coisas que mais me pediram pra comentar por lá foi sobre como está sendo minha experiência na KAVAK, onde estou desenvolvendo em Golang ao invés de PHP.

As perguntas mais comuns são:

1. É muito diferente?
2. Conseguiu se adaptar rápido?
3. Está curtindo?
4. Vai fazer um "GO para iniciantes"?

Antes de sair respondendo cada uma, eu quero repassar o que aconteceu comigo desde o processo de contratação até onde cheguei, e aí voltamos a responder. Bora lá?!

Go: do nada ao pro

(copyright: Pocket-lint) (explicando a piada: go PRO)

Antes de entrar na KAVAK, eu estava trabalhando na Linx como desenvolvedor especialista. Mais especificamente falando, eu era especialista em PHP lá. Minhas ações mais relevantes foram destrinchar bugs antigaços e mapear tudo o que precisava ser corrigido para colocar o serviço onde atuei nas rédeas (leia-se atualizar a infraestrutura para acompanhar as atualizações de segurança). Não posso dar muitos detalhes, mas o bug mais antigo que ajudei a solucionar por lá tinha 3 anos e eu cheguei a mapear mais de 50 débitos técnicos.

Sinceramente, eu gosto muito de chegar investigando tudo o que já fizeram nos serviços onde atuo. É importante que você, futuro desenvolvedor de novas empresas, aprender a fazer isso por conta própria. E fazer por conta não significa fazer sozinho! Faz parte saber perguntar a outras pessoas. Descobrir quem tem mais domínio do que está precisando aprender é essencial para o trabalho funcionar. No pior caso, as pessoas que tinham domínio saíram e você vai precisar de mais tempo para investigar e entender o que tá rolando... Concorda? Enfim...

Mas Kiko, se estava tão legal, por que você saiu da Linx?!

Voltando mais um pouco, lembra que eu trabalhava na Picpay? Sem dar muitos detalhes e sendo bem curto: eu fiquei por lá por um ano e saí por questões financeiras. Eu conheci muita gente lá, sério. E essa galera que conheci é maravilhosa... Não tem ninguém que não seja incrível lá.

Porém, sou pai de gêmeas. Meu salário precisa, no mínimo, acompanhar o custo exponencial que cresce a cada ano. Falando disso agora, eu só vejo como eu fui certeiro nessa decisão... Se eu continuasse com o salário que recebia lá ou com a proposta que me deram, hoje eu teria gastado todas as minhas reservas...

De qualquer modo, eu entrei na Linx por dinheiro. Lá conheci muita gente foda, de verdade... Mas poucos meses depois que entrei lá, recebi o convite de alguns ídolos de carreira que conheci na Picpay para vir pra Kavak. Isso, por si só, já era um bom motivo para vir... O receio era o salário: se fosse menor, não daria pra ir.

Mas eles cobriram.

Então eu fui, mesmo não sendo PHP. O foco era trabalhar com quem eu sei que só gera desafio iradíssimo. Quando eu coloquei na balança as questões de cultura da empresa, outros benefícios foram aparecendo... Eu só não vou colocar essa lista aqui, pois é meio desrespeitoso comparar empresas onde trabalhei assim, em um artigo, sabe?

(não é nada errado falar disso boca a boca ou numa conversa particular, é só meio sem noção deixar isso registrado - agradeço a compreensão)

Ué, Kiko, mas você já tinha trabalhado com Golang antes, certo?

Não!

E isso que é foda. O pessoal que me chamou pra trabalhar lá sabia da minha expertise como desenvolvedor, independente da linguagem, e eles confiaram na minha capacidade de trabalhar com novas linguagens baseado no meu histórico: já fui back-end, front-end, fullstack... Por que não tentar?

Já do meu ponto de vista, eu estava muito nervoso porque já fui contratado como sênior para atuar com uma linguagem que sequer tinha visto. Minha primeira reação nesse cenário foi: eu preciso destrinchar Golang o quanto antes!

Então baixei alguns aplicativos com conteúdo sobre isso no celular e comecei a ler toda noite. Só pra dar um contexto: no dia 04/01 eu anunciei na Linx que ficaria somente até o dia 04/02 (aviso prévio). Nesse período, eu trabalhei normalmente sem deixar nada a desejar. Sempre dou o meu máximo. Mas fora do horário de trabalho, eu foquei em aprender Go só consumindo conteúdos, sem desenvolver nada ainda. Por isso que fiquei um tempão sem escrever nada naquela época. Cheguei a avisar no Twitter, hehe.

No final de semana após minha saída da Linx, eu fiz um projetinho em Go pra testar os conhecimentos. Foi aí que notei que esqueci de estudar um detalhe muito importante: padrão de desenvolvimento em Go.

Logo de cara percebi que arquitetura hexagonal não é nada parecido entre Go e PHP. É possível?? É! Mas não é do mesmo jeito. Golang traz um recurso de importação nativa de módulos armazenados em repositórios externos. O próprio script nativo de uso de banco de dados já dá uma certa noção de Adapter, pois você só precisa importar o driver que vai usar na aplicação e usar o código dele na instância do banco. O que muda além disso? Possivelmente a sintaxe usada nas queries. Aí é que entra os kits que você pode desenvolver para suas aplicações.

A ideia de Go é que você consiga quebrar sua aplicação em pequenas aplicações independentes. E quando eu digo pequenas, é pequenas mesmo. Cada uma delas seria um pacote e é importantíssimo que a conexão entre os pacotes seja de mão única. Você não pode fazer um pacote A usar o B e vice-versa ao mesmo tempo. Se isso acontecer, então está errado (inclusive nem vai compilar).

Há quem prefira colocar todos os códigos na raiz, mas aí vai totalmente contra a arquitetura hexagonal, certo? A gente tem de trabalhar pensando na manutenção constante e não somente na entrega.

Voltando ao final de semana antes de começar na Kavak: fiz um projetinho todo fora dos padrões e pesquisei para entender como a comunidade estava desenvolvendo. Deixo aqui um forte abraço ao time da Uber, que fez um trabalho excepcional de colocar o Package Oriented Design em prática... E deixou muito evidente para mim que a comunidade ainda não acolheu um padrão definitivo.

O que eu senti com isso? Euforia, empolgação, tesão (não-sexual). Um cenário onde o padrão é "terra de ninguém" é o ambiente ideal para chegar participando das tomadas de decisão. E quando eu falo em chegar, não é somente dentro da empresa: isso é na comunidade como um todo. Mas antes de me tornar um porta-voz de qualquer coisa lá, eu preciso me tornar relevante para ser um dentro da empresa.

E como fazer isso, Kiko?

Fazendo bons projetos, bem feitos e desafiando as estruturas atuais com modelos mais ricos e eficientes. Se eu te der um projeto mais organizado que o seu e com desempenho melhor, você iria assistir uma palestra minha para entender qual bruxaria eu fiz? Pois é.

Isso era meu principal objetivo antes de entrar na empresa. Agora que estou dentro, vejo que só temos desenvolvedores fodas e que todos que conheci tem o mesmo sentimento. Já aceitei que não vou ter tanto espaço quanto eu estava almejando, mas eu já tenho um pouco dessa notoriedade. Já puxei discussões relevantes, tentei juntar a galera que manja de Golang para fazer o time geral de desenvolvedores Go, que até então não existia, etc.

Um dev muito foda que tem apresentado várias coisas é o Ricardo Manuel (Massa). Não sei se ele vai ler isso aqui algum dia, mas é, Ricardo, tu é muito brabo. Ele consegue transmitir o que você levaria uma semana para aprender em uma conversa de 30 minutos, sem faltar nada. Isso se você já souber o pré-requisito para acontecer, né? Geralmente já sabemos.

Peraí, Kiko... Então sua maior dificuldade hoje é mais sobre padrões de desenvolvimento em Go e não a linguagem em si?

Exatamente. É a dor de trabalhar com uma linguagem tão recente (ainda estamos na versão 1.18, enquanto outras já estão na 11+). Aprender a linguagem em um mês foi muito fácil, pois ela é bem parecida com C. Algumas mudanças de sintaxe a gente só aprende desenvolvendo, porém minha curva foi bem rápida, pra não dizer instantânea. Outro detalhe é que meus gestores deram um projeto de onboarding para minha squad, onde pudemos discutir, refletir e analisar o padrão que usaríamos, além de refatorar várias vezes até chegar numa estrutura aceitável.

Então devo dizer: esse aprendizado não dependeu só de mim. A empresa me deu todo o necessário para me desenvolver sem exigir praticamente nada. Esperavam o projeto de onboarding em dois meses, entregamos em um. Começamos o primeiro projeto que agrega valor ao produto logo em seguida e já estamos 10 vezes mais rápidos, pois já absorvemos a forma ideal de desenvolver projetos em Go.

Ou seja: leitore, a KAVAK é perfeita. Meus gestores são perfeitos. Meu time é maravilhoso. Tudo nessa p* é empolgante e eu ainda vou crescer bastante por aqui.

Tá, Kiko, mas cadê a comparação entre PHP e Golang?

É, eu quase esqueci desse detalhe. Então vamos fazer uma lista básica:

1. É inviável ter super frameworks em Golang como temos no PHP (Laravel, Code Igniter, etc) pelo simples fato que qualquer "faz-tudo" em um pedacinho do projeto irá pesar MUITO na capacidade de processamento da aplicação. Por isso, faz-se importante definir, o quanto antes, o padrão de desenvolvimento dentro das empresas, no mínimo! Se os times não seguirem o mesmo padrão, vai ser um tiro no pé!
2. O conceito de construtor em Golang é bem diferente do PHP. Geralmente, cada pacote tem uma função New() (se há somente uma struct a ser instanciada do lado de fora do pacote), o que significa que você constrói PACOTES, não structs (que é o que confundimos com classes). Ao invés de ter entities.NewPhone() e entities.NewEmail() você pode ter um pacote phone, outro email e chamar phone.New() e email.New(). É isso.
3. Golang não tem herança como vemos no PHP. As visibilidades são privadas ou públicas, sendo que a visibilidade privada é visível para todo o pacote, não somente a struct, por exemplo. E o que define isso é se a primeira letra do que está definindo está minúscula ou maiúscula. Nada de private ou public.
4. Em Go, o conceito de ponteiros mágicos não existem dentro dos métodos. Eu falo principalmente do $this: não existe e não é recomendado criar o conceito lá.

5. Consequentemente, os métodos podem ou não ter um ponteiro da struct onde está sendo atrelado. Por exemplo, considere a seguinte struct (mesmo se não souber ler o código):

    package main
   
    import "fmt"
   
    func main() {
        // Criando a classe diretamente, sem referência
        ex2 := (Exemplo{})
        ex2.MetodoSemPonteiro(30)
        fmt.Println(ex2) // {0}
        ex2.MetodoComPonteiro(30)
        fmt.Println(ex2) // {30}
   
        // Usando construtor, retornando referência
        ex := New(10)
        ex.MetodoSemPonteiro(15)
        fmt.Println(ex) // &{10}
        ex.MetodoComPonteiro(20)
        fmt.Println(ex) // &{20}
    }
   
    type Exemplo struct {
        Valor int
    }
   
    func New(valorInicial int) *Exemplo {
        return &Exemplo{Valor: valorInicial}
    }
   
    func (ex Exemplo) MetodoSemPonteiro(novoValor int) {
        ex.Valor = novoValor
    }
   
    func (ex *Exemplo) MetodoComPonteiro(novoValor int) {
        ex.Valor = novoValor
    }
   

   Na declaração do método MetodoSemPonteiro, após o termo func temos a declaração da struct que recebe aquele método, no caso, (ex Exemplo). No MetodoComPonteiro, essa declaração tem um asterisco. Esse caractere significa referência. Isso significa apenas uma coisa importantíssima que você precisa sacar em Golang: o primeiro método (MetodoSemPonteiro) não salva o campo novoValor em lugar nenhum, pelo simples fato de que ele não tem a referência do objeto original.

   Os métodos sem referência servem apenas para retornar algo, sem persistir mudanças na estrutura. O mais próximo disso em PHP são os métodos estáticos, que não precisam instanciar a classe para existir, exceto que em Go, é preciso instanciar, de certa forma.

   Você pode rodar o código acima aqui (Go Playground).

6. O código da sua aplicação não precisa ter separação de domínio e infra. Você pode desenvolver um projeto pra infra e outro pra aplicação! Ficando somente o domínio. Irado, né? Essa é uma das minhas favoritas.

7. Consequentemente, se suas aplicações tiverem configurações de infra parecidas, você pode criar um kit para todas as aplicações, instantaneamente centralizado alguns padrões, como:

   • Servidor web (Fiber, Chi, Gin?);
   • Logs (estrutura padrão dos logs, integrações, etc);
   • Tracking de eventos (estrutura padrão dos eventos, integrações, etc);
   • Banco de dados (centralizar o padrão de instância da empresa, assim como uso das configurações corretas);
   • Mensageria (estrutura padrão das mensagens, integrações, etc);
   • Notificações (estrutura padrão das notificações, possíveis integrações, etc), sendo que essa você pode quebrar em pacotes específicos (sms, email, slack, discord, whatsapp, telegram, etc, o que você quiser fornecer de possibilidade de notificação);

   • etc!

     Sua aplicação só precisará importar os pacotes que vai utilizar e chamar. Fim! Sendo um kit da empresa, o padrão de inicialização de cada "componente" pode ficar no respectivo pacote, tendo o desenvolvedor a única obrigação de seguir a documentação dos pacotes para configurar as variáveis de ambiente corretamente.

     Enfim, isso também é possível de fazer em PHP, mas em Golang isso é praticamente obrigatório. As limitações da linguagem te induzem a fazer essa boa separação de responsabilidades, esse é o ponto.

E por enquanto eu vou parar por aqui, pois meu tempo para escrever acabou e não sei quando vou poder retornar. Dito isso, não quero deixar para continuar escrevendo depois (quando eu claramente já vou ter esquecido o que estava escrevendo).

Curtiu? Comenta e compartilha! Você já tinha visto um código em Golang antes desse post? Quer comentar suas experiências também ou o que achou do meu ponto de vista? Só descer aí e escrever, hahaha. Se não tiver uma conta e não quiser se cadastrar, aceito um tweet me marcando. O importante é se comunicar!

Inté!!