Lições que aprendi na Stone Tech e não no bootcamp
Assim como diversos profissionais da nossa área, participei de um bootcamp no início da minha carreira, a fim de aprimorar meus conhecimentos técnicos e chegar ainda mais preparada no mercado de trabalho. Apesar de ter adquirido bastante conhecimento estudando com a Driven, foi entrando no mercado de trabalho que eu tive oportunidade e tempo de aprender Node mais a fundo.
Aqui na Stone, aprendi que não existe “receita de bolo” quando o assunto é codar e que, para oferecer as melhores soluções, é fundamental explorar diferentes caminhos e, acima de tudo, dialogar com a sua equipe e entre equipes. Temos uma cultura de compartilhamento e aprendizado constante, que é latente especialmente nos times de Tecnologia. Aqui, interagimos diretamente com profissionais de diversas áreas e níveis de conhecimento, e somos incentivados a sempre questionar, estudar e nos aprofundar em tudo o que trabalhamos.
Pensando nisso, elenquei alguns tópicos para introduzir aqui que só aprendi trabalhando na Stone, no time de Settlements. Espero que possa ajudar você que, assim como eu, trabalha com Node.js. Olha só!
1. JavaScript currying
Currying é um método que torna as funções um pouco mais flexíveis em javascript e que funciona bem para desenvolvedores back-end.
Com o currying, você pode passar todos os argumentos de uma só vez ou apenas passar um subconjunto de argumentos. Nesse último caso, ao passar o subconjunto, a função retorna outra função que está esperando pelos últimos argumentos.
Essa técnica é especialmente útil quando não temos todos os argumentos em mãos de uma vez, ou quando queremos reaproveitar a mesma função para diferentes cenários.
Vou usar o exemplo mais clássico de todos, o ‘Hello World’, para ilustrar:
2. Versões Node.js LTS
Escrever um software raramente é um trabalho pontual, com começo, meio e fim. É um trabalho constante de manutenção e melhoria do código. Devemos sempre buscar otimizar a performance do produto, estar atentos a falhas de segurança e evoluir nosso projeto. Nesse quesito, Node.js sempre trabalha para oferecer uma nova versão mais performática e segura que a anterior.
Entretanto, manter o código o mais atualizado possível não é uma tarefa fácil, especialmente em projetos complexos. Muitas vezes, ao atualizarmos a versão do Node, corremos o risco de encontrar incompatibilidade de alguma ferramenta ou biblioteca em uso pelo projeto; ou até pedaços de código que precisaremos corrigir em consequência da mudança.
Assim, é importante que se busque sempre utilizar as versões Node LTS (Long-Term Support). Essas versões são as principais do Node.js e as mais adequadas para uso em produção, uma vez que são versões com suporte de longo prazo. Isso significa que essas versões terão seus bugs críticos corrigidos, além de atualizações de segurança e melhora de performance por muito mais tempo, acredito que por um total de até 30 meses. Assim, usando versões LTS, conseguimos diminuir a frequência em que necessitamos atualizar a versão utilizada em produção.
As versões LTS são as versões de número par (10, 12 etc) e, apesar de nem sempre serem as versões mais atuais, são as mais estáveis e seguras, indicadas principalmente para grandes projetos.
3. Funções Puras x Funções Impuras
Funções puras são aquelas funções que sempre retornam a mesma saída, dada a mesma entrada, e sem causar qualquer efeito colateral. Dessa forma, funções puras são previsíveis, o que traz benefícios para o código como entender o seu funcionamento mais facilmente, evitar bugs e ter mais agilidade na depuração de erros.
E quando eu digo efeito colateral (os famosos side-effects), eu quero dizer:
- chamadas HTTP;
- manipulações de arquivo;
- modificações nos dados originais de entrada;
- e até o queridinho console.log.
Funções puras não modificam qualquer estado ou objeto externo a ela, mas pode ser que nem sempre sejam a escolha que trará mais performance para a sua aplicação. Por outro lado, pode ser interessante deixar que funções impuras imprescindíveis ao projeto, como chamadas ao banco, sejam executadas da maneira mais isolada possível do restante das funções. Então, mesmo que funções puras tragam muitos benefícios, o que deve prevalecer é o bom senso no que tange ao contexto da sua aplicação.
Existem algumas perguntas que você pode se fazer para saber se sua função é pura:
- Ela pode ser substituída pelo dado que ela retornaria sem causar nenhum prejuízo ao código?
- Ela manipulou um objeto de entrada ou um objeto global diretamente, ao invés de utilizar uma cópia dos argumentos de entrada?
- Sua função é previsível? Se eu chamar essa função mil vezes com os mesmos argumentos, ela vai me retornar mil vezes o mesmo resultado?
Se você respondeu que não a qualquer uma dessas perguntas, então sua função é impura!
4. Operações blocantes e não blocantes
Node é uma ferramenta que trabalha com single thread em event-loop. Você já ouviu falar em event-loop? Temos uma talk bem interessante no canal do Pagar.me no youtube sobre esse tema :)
Voltando ao assunto, o fato de Node ser single thread não nos permite rodar dois processos paralelamente, mas podemos ‘criar’ concorrência entre os processos fazendo o event-loop trabalhar a nosso favor, com a programação assíncrona. Nela, podemos deixar nossa aplicação mais performática deixando que operações I/O (Input/Output) sejam executadas de maneira não blocante, para conseguir servir a várias requests ao mesmo tempo.
Pra ilustrar melhor o assunto, vou te dar um exemplo mais cotidiano. Imagine que você entra em uma lanchonete em que haja uma pessoa atendendo às mesas e outra preparando os pedidos. Ao se sentar, você faz seu pedido e a atendente o leva até a cozinha para ser preparado. Enquanto ele está sendo preparado, a pessoa que te atendeu fica livre para atender outras mesas e voltar depois para buscar o pedido na cozinha e te entregar. Afinal, se não é de responsabilidade dela preparar seu pedido, não faz sentido ela ficar na porta da cozinha esperando por ele enquanto poderia estar atendendo outras mesas.
Mas o que seria uma ação blocante? De acordo com a própria organização responsável pelo Node.js, uma operação blocante é quando a execução do javascript tem que esperar uma operação não-javascript terminar para continuar seu processamento. Essa operação não-javascript poderia ser uma request externa, a manipulação de um arquivo, uma consulta no banco de dados etc.
Adicionalmente, ainda existem ações que podem ser performadas tanto de maneira blocante como não blocante, e sua escolha vai depender do que pode ser melhor para o contexto da sua aplicação. Assim, pode ser que seja melhor para o seu projeto buscar uma certa quantidade de dados do banco de dados e ordená-los via javascript, por exemplo. Por outro lado, imaginando uma aplicação que receba várias requests simultâneas e que possua diversas responsabilidades… Provavelmente será mais interessante deixar a cargo do banco de dados te devolver os dados ordenados ou filtrados da maneira desejada, enquanto sua aplicação se encarrega de outros processamentos nesse meio tempo.
Espero que essas introduções te inspirem a estudar mais esses assuntos, que possam te auxiliar no desenvolvimento de novos projetos, bem como facilitar a sua rotina de trabalho.
E se você está em busca de novas oportunidades, aqui na Stone estamos com diversas vagas abertas nos times de Tecnologia. Destaco, em especial, a oportunidade para Pessoa Desenvolvedora | Node.js. Confira essas e outras candidaturas disponíveis na nossa página de carreiras!
