mfbmina.dev

Uma das minhas funcionalidades favoritas em Go é a possibilidade de se escrever testes de benchmark. Agora na versão 1.24, essa funcionalidade ganhou uma cara nova, se tornando ainda mais fácil de ser utilizada.

Para demonstrar estas mudanças, suponha uma função que calcule o fatorial de forma recursiva e uma atráves de laços.

func FatorialRecursive(n int) int {
	if n == 0 {
		return 1
	}

	return n * FatorialRecursive(n-1)
}

func FatorialLoop(n int) int {
	aux := 1
	for i := 1; i <= n; i++ {
		aux *= i
	}

	return aux
}

Anteriormente, para escrever um teste de benchmark, precisávamos informar o laço de execução do teste. Com o teste escrito, era só rodar o comando $ go test -bench .

Após ler o livro The Goal fui atrás de uma próxima leitura e me recomendaram o The Mythical Man-Month, do Fred Brooks. Esse livro é um clássico da literatura da computação, desconhecido por mim até agora, mas que descreve o ciclo de desenvolvimento de softwares na década de 70.

O tema central do livro já é descrito no título: o mítico homem-mês. Homem-mês é uma métrica de produtividade assim como as que são utilizadas hoje, por exemplo, pontos, tamanho de camisetas ou qualquer coisa que as equipes utilizam. O argumento é de que a métrica é falha e o número de tarefas, linhas de código ou funcionalidades que uma pessoa entrega não é constante entre projetos.

Atualmente, grande parte do trabalho de um desenvolvedor WEB consiste em chamar APIs, seja para realizar uma integração com um sistema de uma equipe parceira ou para integrar com algum fornecedor.

Outra grande frente do dia-a-dia é a escrita de testes. Testes garantem (ou deveriam garantir :D) que o código escrito por nós funciona da maneira esperada e que surpresas não vão acontecer quando a funcionalidade estiver em ambiente produtivo.

No mundo do desenvolvimento, é necessário saber como a aplicação que estamos trabalhando está se comportando e a maneira mais conhecida de realizarmos isso é por meio de métricas. Elas podem ser de diversos tipos, como, por exemplo, de desempenho, de produto ou de saúde. Atualmente, o Prometheus é amplamente utilizado pelo mercado a fim de coletar essas métricas.

Ele é um serviço open-source mantido pela CNCF , a Cloud Native Computing Foundation. Ele funciona da seguinte maneira: um endpoint é exposto na aplicação. Esse endpoint retorna um texto no formato esperado, e o Prometheus acessa esse endpoint de tempos em tempos coletando as informações dali.

No fim do ano passado, minha equipe começou o seu projeto mais importante até então e acabei assumindo a liderança na organização do projeto. Fui responsável por coordenar as reuniões, o processo de entrega, etc. Durante os primeiros meses, o projeto foi andando bem, tomamos algumas decisões difíceis, provamos alguns conceitos e iniciamos o rollout da primeira fase.

Contudo, eu sentia que estava atrasando o time em alguns aspectos e que estava sendo um gargalo no processo todo. Em um 1x1 com o head da área, contei a ele sobre essa frustração e a resposta que recebi foi essa:

A primeira vez que ouvi falar sobre RPC foi em uma aula de sistema distribuídos, ainda quando estava cursando a graduação em Ciência da Computação. Achei legal, mas na época lembro de não compreender exatamente o porque eu usaria RPC ao invés de usar o padrão REST, por exemplo. Passa o tempo, e vou trabalhar em uma empresa em que parte do sistema legado era utilizando SOAP. Lembro de pensar: “hmm, interessante! Parece com RPC, mas traféga XML”. Anos depois, ouço pela primeira vez falar sobre gRPC, mas nunca entendi complementamente o que era, o que comia e pra que servia.

Quando optei pela carreira em computação, aos 15 anos, foi uma decisão baseada em gostar bastante de matemática e física. Queria me ver longe de escrever textos, redações e etc. Com o passar do tempo, essa visão foi mudando e agora uma das coisas na qual mais valorizo em uma equipe/empresa madura é a existência de documentação técnica.

Documentações nos ajudam a ter conhecimento histórico de decisões na empresa, nos ajudam a revisitar pontos e a entender melhor os pontos fortes e fracos dessas decisões. Além disso, elas são extremamente valiosas para novos membros da equipe, pois contam uma história de como vocês chegaram lá. Quanto mais detalhada, mais rica a história é.

Nos dias de hoje, é bem comum que nossa aplicação dependa de outras, principalmente se estamos trabalhando em um ambiente de microsserviços. É bem comum que nossa aplicação comece a reportar erros, que ao se investigar, notamos que alguma API de uma equipe parceira ou fornecedor está fora do ar.

Uma boa prática para aumentar a resiliência da nossa aplicação, é cortar a comunicação com essas aplicações que estão em estado depreciados. Observando outras áreas, absorvermos da Engenharia Elétrica o conceito de Circuit Breaker. Nele é colocado um equipamento, ou disjuntor, que se desliga automaticamente caso alguma falha aconteça. Isso é muito comum em nossas casas, que possuem disjuntores que se desligam sozinhos caso a rede elétrica comece a ficar instável.

Escrever um jogo é uma ótima maneira de se começar a programar, principalmente pois diversas pessoas começaram a programar por que queriam criar jogos para computadores ou até mesmo video game. Inclusive, um dos meus primeiros “projetos” foi um joguinho, ainda quando cursava o curso técnico em Informática Industrial, em 2010.

No curso, utilizávamos Python e implementamos um slide puzzle. Foi bem desafiador na época, pois tive que entender da mecânica do jogo, de como criar uma GUI, mas entreguei o projeto. Quando comecei a trabalhar com Ruby, também fiz uma implementação para comparar com o que já tinha feito em Python.

Linter é uma ferramenta de análise estática de código que é usada para encontrar erros de programação, bugs, falta de padronização de código e até mesmo falhas de segurança. Essas ferramentas ajudam os desenvolvedores pois permitem que bastante tempo seja salvo, já que identificam problemas antes mesmo de chegarem em produção. Além disso, são extremamente utéis no processo de code review, já que salvam os desenvolvedores de desnecessáriamente avaliar se o colega utilizou os padrões da equipe ou não.