DX ou DevEx é sobre analisar todos os componentes do ecossistema da pessoa desenvolvedora — do ambiente aos fluxos de trabalho e ferramentas — e busca entender como eles estão contribuindo para a produtividade, a satisfação e o impacto operacional dos desenvolvedores.

Com o DevEx, todos os aspectos da jornada de um desenvolvedor são questionados.

C = Colaboração, o multiplicador em todo o DevEx.

A fórmula DevEx do GitHub leva em consideração:

• Produtividade: com que rapidez e simplicidade uma alteração pode ser feita em uma base de código
• Impacto: quão fácil é passar da ideia à produção
• Satisfação: como o ambiente, os fluxos de trabalho e as ferramentas afetam a felicidade do desenvolvedor

Otimizar o DevEx significa criar um ambiente colaborativo que permita aos desenvolvedores aumentarem sua produtividade, impacto e satisfação.

Impacto na minha experiência como desenvolvedor

Há 18 anos, iniciei minha trajetória como desenvolvedor e, fazendo um recap da minha atuação hoje, tenho consciência de como DX impactou diretamente na minha produtividade:

• Eficiência, tempo de foco:

Trabalhei em empresas onde meu trabalho normal era interrompido regularmente, e me sentia muito improdutivo. Não conseguia entrar no tal do “flow” do desenvolvedor. Basicamente, o time de tech tinha muita cobrança das outras áreas (a pergunta recorrente era “quando isso vai ser entregue”), com pouco tempo de foco, porque grande parte do tempo era desperdiçada com reuniões desnecessárias ou pouco objetivas.

• Produção, monitoramento:

Em outra experiência, tínhamos um produto com muitos usuários em produção. Existia uma cobrança exagerada para ter um tempo de resposta rápido, considerando o MTTR (Mean Time To Recover) do DORA, mas, na prática, por mais que me esforçasse, não conseguia atingir as expectativas.

Quando existia um incidente, não tinha confiança de que conseguiríamos resolvê-lo rapidamente. Não tínhamos um bom sistema de logs e o que tínhamos estava espalhado em múltiplas ferramentas e não nos dizia realmente qual era a causa raiz do problema.

VEJA TAMBÉM: Checklist – sinais de uma squad de alta performance

• Implantações e versionamento:

Esse é outro problema que gerava fricção. A cobertura de testes era algo essencial, mas a eficácia dos mesmos era muito baixa. Basicamente, o time fazia os testes para passarem de qualquer forma e deixar o indicador sempre alto.

Tínhamos também um problema em fazer deploy. Era sempre uma demora excessiva para passar todas as etapas da nossa pipeline (tinha que esperar 20 minutos) em cada deploy. Imagina em um time de quase 100 desenvolvedores, o quanto isso é improdutivo.

• Colaboração e conhecimento:

Nosso time passava pouco tempo aprendendo com nossos erros e falando sobre esses problemas que geravam fricção.

Exemplos:  “Nosso processo de revisão de código nos ajuda a fazer uma release de código melhor?”
ou “Nossa documentação realmente ajuda no onboarding dos novos desenvolvedores?”

• Codebase:

Era muito difícil encontrar a causa raiz dos incidentes porque nossa codebase tinha uma baixa qualidade. Muita coisa precisava ser refatorada, mas tarefas de refatoração nunca eram consideradas prioridade.

• Planejamento do projeto, processos de equipe:

Em outra experiência, o time de tecnologia tinha a fama de “sempre atrasar” porque nunca conseguíamos dar vazão às tarefas planejadas.

O que ninguém via é que as tarefas eram mal escritas, o que nos levava a gastar muito tempo tirando dúvidas e os objetivos nunca eram realmente claros. Não era perceptível que nosso trabalho gerava valor para o negócio.

• Produtividade percebida:

Levantando todos os pontos acima, o que fica claro na minha experiência é que havia muita cobrança sobre “ser produtivo” e pouca reflexão sobre “o quão produtivo eu me sentia” e sobre “o que reduziria o atrito no meu trabalho diário”.

Isso é sobre DX. Antes de olhar apenas para métricas, pergunte para o seu time qual o ponto de vista deles sobre produtividade. Os desenvolvedores não tem motivos para mentir sobre o que vai tornar o dia a dia deles mais produtivo e você pode trabalhar em direção a isso (ao menos reservar um tempo para isso). 

Pesquisas

De acordo com um levantamento de oportunidades da Forrester , as equipes podem reduzir o tempo de lançamento no mercado e aumentar a receita criando uma maneira mais fácil para os desenvolvedores escreverem códigos, criarem software e enviarem atualizações aos clientes. Como resultado da melhoria do DevEx:

• 74% dos entrevistados disseram que podem aumentar a produtividade do desenvolvedor
• 77% podem reduzir o tempo de lançamento no mercado
• 85% podem impactar o crescimento da receita
• 75% conseguem atrair e reter mais clientes
• 82% podem aumentar a satisfação do cliente

Greg Mondello, do GitHub, diz que não é surpresa que a DevEx tenha visto um aumento significativo no investimento nos últimos cinco anos.

“Na maioria dos contextos, a capacidade de desenvolvimento de software é o fator limitante da inovação”, afirma. “Portanto, melhorias na eficácia do desenvolvimento de software são inerentemente valiosas.”

Além disso, o desenvolvimento está cada vez mais complexo. A construção de software hoje envolve muitas ferramentas, tecnologias e serviços de diferentes fornecedores, o que exige que os desenvolvedores gerenciem ambientes muito mais complexos.

Na melhor das hipóteses, um DevEx bem concebido fornece maior consistência entre ambientes, processos e fluxos de trabalho, ao mesmo tempo que automatiza os processos mais tediosos e manuais.

“Isso permite que empresas com melhor DevEx superem seus concorrentes, independentemente da vertical”, diz Mondello.

O que constitui uma boa experiência para o desenvolvedor?

Um bom DevEx é onde os desenvolvedores têm as informações de que precisam e podem alternar entre o foco e a colaboração.

Os desenvolvedores enfrentam muitos tipos de atrito durante seu fluxo de trabalho de ponta a ponta, especialmente se estiverem usando várias ferramentas. De reuniões a solicitações e muitos outros tipos de interrupções, os desenvolvedores muitas vezes precisam reunir o contexto de fontes fragmentadas e desatualizadas, o que prejudica sua capacidade de serem produtivos e escreverem códigos de alta qualidade.

Embora descrever os componentes exatos possa ser complicado, os especialistas concordam que um DevEx forte abrange o seguinte:

• Colaboração
• Velocidade
• Ciclos curtos de feedback
• Altos graus de automação e integração
• Baixos níveis de atrito ou trabalho
• Processos transparentes e bem documentados

Quais são as principais métricas de experiência do desenvolvedor?

Não existem métricas padronizadas do setor para medir o DevEx. No entanto, tem uma correlação direta com DevOps Research and Assessment (DORA), que olha as boas práticas da cultura DevOps.

Dentro do estudo de DORA metrics, você tem as boas práticas de tech capabilities que são preditivas da performance da entrega de software (Lead time for change, Deploy Frequency, Failure Rate e Time to Restore Service).

Ao enviar pesquisas com foco em DX, você vai conseguir olhar para dados subjetivos que ajudam a identificar o que vai ser priorizado de Tech Capabilities (preditivo de DORA).

Exemplos: 

“Meu MTTR (Mean Time To Recovery) está baixo. O DX pode nos ajudar com informações como “Os desenvolvedores têm dificuldade de encontrar logs das nossas aplicações. Precisamos priorizar nossa tech capabilities “Monitoring and Observability” . 

“Lead time for change está longo. O DX pode nos ajudar com informações como “A baixa qualidade da codebase aumenta o tempo de desenvolvimento.” Precisamos priorizar nossa tech capabilities “Code maintainability” . 

Conclusão

Escute seus Desenvolvedores: Antes de olhar apenas para métricas, pergunte para o seu time sobre o ponto de vista deles sobre produtividade.

Priorize: Use métricas objetivas, como DORA, para cruzar dados de pesquisa e entender o que deve ser priorizado.

Reduza o Atrito: Identifique e elimine obstáculos que diminuam a produtividade ou satisfação do time.

Quando você cruza dados qualitativos de DX, com métricas quantitativas como DORA, as chances de você identificar as falhas do seu processo são muito maiores, e uma vez identificadas, o DORA Core Model, e a própria pesquisa de DX, te darão o caminho para solucioná-las, com isso seu time estará a um passo da máxima produtividade.

The post DX (Developer Experience) – Maximizando a produtividade do desenvolvedor appeared first on BossaBox.

De fato, a comunicação desempenha um papel fundamental como ponto de partida para o estabelecimento desse alinhamento. As perguntas centrais são:

• Qual é o desenho ou fluxo de comunicação adequado para estabelecer essa sintonia?
• Será um esquema detalhado ou um plano geral (isso ajuda a definir qual é nível de detalhe que trabalhamos)?
• Os OKRs se transformarão em um documento textual e cada área se torna responsável pelas suas iniciativas?
• Será um documento elaborado colaborativamente entre as diversas áreas?

Esse primeiro passo desempenha um papel crucial ao definir as expectativas em relação à qualidade do alinhamento. Afinal, em teoria, todos têm acesso ao documento de alinhamento mais macro/global.

A partir desse ponto, com a efetiva gestão da comunicação, podemos abordar o segundo desafio: como a área de produtos (ou requisitos) irá externalizar os desejos funcionais e não funcionais dos stakeholders? Isso será subentendido ou explicitamente delineado em uma seção dedicada?

A partir dessa clareza, a equipe de arquitetura pode compreender o panorama e elaborar uma arquitetura que atenda às necessidades, sem ser excessivamente simplista ou superdimensionada.

LEIA TAMBÉM: Tamanho do time X desempenho: Como o número de membros da equipe pode afetar as entregas?

Com esses elementos devidamente alinhados, a equipe de arquitetura pode, com base na stack de tecnologia disponível, determinar a melhor tecnologia a ser empregada na solução do problema em questão. É imperativo compreender o papel da arquitetura neste ciclo. A arquitetura não é responsável pela implementação direta, mas sim por definir o que/como será utilizado.

Nesse sentido, a integração eficaz da arquitetura no processo de desenvolvimento aumenta significativamente a produtividade. Isso evita que problemas ou não conformidades com os requisitos sejam identificados tardiamente, durante os testes de qualidade (QA), quando poderiam ter sido abordados no início do ciclo de planejamento.

Após mais de uma década e meia de experiência no contexto ágil, percebo que ainda são cometidos erros básicos, como atropelar a sequência de ações. Lembro-me de uma frase que certa vez ouvi, que dizia algo como “o ágil permitiu que as empresas oficializassem a desorganização“. Apesar de ter testemunhado essa realidade, é lamentável, pois nada poderia estar mais distante do verdadeiro conceito ágil do que a desorganização.

Isso ressalta a importância de enfocar a comunicação e os processos como elementos cruciais para encurtar o caminho em direção ao sucesso. Caso contrário, estaríamos apenas improvisando. Portanto, é fundamental ter consciência e planejamento para integrar esses componentes no processo, garantindo uma abordagem mais eficiente e eficaz.

Em resumo, o alinhamento eficaz, ancorado na comunicação sólida e na compreensão precisa dos requisitos, é a bússola que guia as organizações em direção ao sucesso. Não há lugar para improvisos, apenas para estratégia e planejamento.

The post Construindo pontes entre visão estratégica e arquitetura: minimizando equívocos no ciclo de desenvolvimento appeared first on BossaBox.

Não é novidade que empresas enfrentam dificuldades em encontrar e manter profissionais altamente qualificados em seus times de tecnologia. Neste artigo, abordaremos o porquê desse cenário difícil de contratar profissionais de tecnologia certos para seu desafio e como medir e potencializar o desempenho da sua equipe de Produto e Tecnologia.

Por que é tão difícil contratar profissionais de tecnologia de alta performance?

Há várias razões pelas quais é difícil contratar profissionais de tecnologia de alta performance. Uma delas é a falta de profissionais qualificados no mercado. Segundo dados da Associação das Empresas de Tecnologia da Informação e Comunicação e de Tecnologias Digitais, a projeção é, até 2025, um déficit de mão de obra no mercado de tecnologia que pode chegar a 797 mil.

Além disso, as habilidades específicas necessárias para trabalhar com tecnologia estão em constante evolução, o que significa que muitos profissionais podem não ter a experiência necessária com o seu segmento de mercado. A senioridade é um fator importante para alguns desafios específicos.

Outro desafio é o alto turnover em tecnologia. Profissionais de tecnologia buscam novos desafios e oportunidades com frequência, estão sempre em movimento, querem acelerar seu desenvolvimento e acompanhar as novidades do setor. A TI Inside divulgou uma pesquisa mostrando que 55% dos profissionais de tecnologia trabalhariam no exterior.

O mercado de tecnologia é super competitivo. Por conta desse fator, muitas empresas oferecem salários altos e benefícios para atrair os melhores talentos, o que aumenta a competição.

Você deve saber como é difícil encontrar a pessoa certa, com as habilidades necessárias, e garantir que ela esteja com todo o contexto necessário e performando em seu potencial máximo, certo?

E como saber se minha equipe de tecnologia é de alta performance?

As equipes de engenharia buscam incessantemente formas de aumentar a eficiência na entrega de produtos digitais de qualidade e úteis para os usuários. Entretanto, como determinar se uma equipe de engenharia é verdadeiramente produtiva e eficiente?

A pesquisa DevOps Research and Assessment (DORA) analisa o desempenho da equipe em quatro áreas: entrega, tempo de espera, frequência de implantação e tempo de recuperação. Essas métricas são usadas para avaliar a eficiência da equipe de tecnologia e melhorar a entrega de software.

Aqui está uma explicação detalhada das DORA Metrics:

1. Deploy Frequency: frequência com que um time realiza implantações de código em produção. O objetivo desta métrica é medir a agilidade e capacidade da equipe em entregar valor aos usuários através de atualizações e melhorias no software. Uma maior frequência de implantação geralmente indica que a equipe é capaz de iterar e evoluir o software rapidamente, enquanto uma frequência menor pode indicar problemas no processo de entrega.
2. Lead Time for Changes: tempo que leva desde o momento em que uma mudança no código é feita (por exemplo, um commit) até sua implantação bem-sucedida em produção. O objetivo dessa métrica é avaliar a velocidade com que uma equipe consegue entregar valor aos usuários, incorporando novas funcionalidades ou corrigindo problemas. Um menor lead time geralmente indica um processo de entrega mais eficiente e ágil.
3. Change Failure Rate: proporção de implantações que resultam em falhas, como incidentes em produção ou a necessidade de reversão das mudanças. O objetivo dessa métrica é entender como as equipes de DevOps gerenciam riscos e mantêm a estabilidade e a qualidade do software durante a implantação de novas funcionalidades e correções. Uma taxa de falha menor indica um processo de entrega mais confiável e eficiente.
4. Mean Time to Restore: tempo médio que leva para restaurar o serviço após uma falha, como incidentes em produção ou interrupções do sistema. O objetivo dessa métrica é entender como as equipes de DevOps lidam com problemas e incidentes no ambiente de produção e o quão eficientes são em restaurar o serviço normal. Um MTTR menor indica que a equipe é capaz de identificar, diagnosticar e solucionar problemas mais rapidamente, minimizando o impacto sobre os usuários.

Ao medir essas métricas regularmente, você pode entender como a equipe de tecnologia está funcionando e onde há oportunidades para melhorias. As DORA Metrics podem ser usadas para identificar gargalos no processo de desenvolvimento e melhorar a eficiência da equipe. Temos um artigo bem detalhado sobre a aplicação das métricas DORA no dia a dia de times de Engenharia que pode te ajudar com mais contexto.

A performance da equipe de Engenharia e o sucesso do Produto

A abordagem da DORA (dados objetivos), juntamente com a experiência da pessoa desenvolvedora (dados subjetivos) oferecem uma visão mais holística e equilibrada da produtividade e eficiência das equipes de engenharia. Ou seja, a conclusão é de que a eficiência e produtividade no desenvolvimento de software não podem ser medidas apenas por métricas isoladas, como quantidade de linhas de código, horas-homem ou story points.

Se quiser receber mais conteúdos sobre contratação de profissionais de tecnologia e gestão de times de alta performance, inscreva-se na nossa newsletter ou acesse nosso site.

The post Como saber se minha equipe de tecnologia é de alta performance? appeared first on BossaBox.

A squad de foundation ganhou esse nome pois é através dela que o time da BossaBox criou uma base de referência, ou seja uma fundação, para promover melhorias contínuas nos códigos. A criação dessa fundação também possibilitou que as squads de produto, em especial as(os) desenvolvedoras(es), trabalhassem com mais qualidade e eficiência.

Como ficam as métricas das squad?

Com o crescimento, tanto do time interno da BossaBox quanto do número de squads formadas por prolancers, detectou-se o surgimento de um gap na qualidade das métricas utilizadas. 

Sabendo que essa avaliação da qualidade não deveria ser feita por linha de código, ou por tempo de desenvolvimento, usou-se um estudo sobre DORA Metrics como fonte para essa transformação. Assim o time pode identificar exatamente qual era o problema e qual o caminho para corrigi-lo. 

Primeiramente foi considerado o impacto cognitivo no código desenvolvido, em comparação com o tamanho do código versus a quantidade de locais que foram alterados, ou tecnicamente falando, o tempo do primeiro Commit até o Deploy.

Além dessa métrica principal, outras são adicionadas para que a análise possa ser mais completa, levando em consideração as diferentes variáveis existentes na produção de um código. Isso garante que a probabilidade de se entregar valor para o cliente aumente.

Quais foram os benefícios na prática?

Além de aumentar o valor e qualidade final da entrega, essa alternância para uma validação data driven garantiu melhorias no dia a dia de trabalho do time. Não há mais necessidade de reuniões diárias, ou de se passar horas seguidas “codando”. 

Isso aconteceu pois, além de melhorias na fundação do código, houveram alterações na maneira como se é feito o refinamento técnico no time. A principal delas foi pensar que para cada entrega desenvolvida, precisa ter um entregável, por menor que seja.    

Com isso garantiu-se que as squads tenham um maior impacto cognitivo, em um menor tempo, aumentando a eficiência. Toda essa melhoria estruturada é compartilhada com os times para que a base de código esteja sempre sendo atualizada, sendo melhorada, e validada através das métricas. 

Foram essas métricas e melhorias contínuas que geraram um crescimento de valor da entrega de mais de 200%, isso equivale a mais de três meses de trabalho. É agilidade, eficiência e qualidade trabalhando juntas para se obter os melhores códigos. 

Quer saber mais como a Squad Foundation funciona e como aplicamos métricas no dia-a-dia, assista esse vídeo!

The post Métricas e melhoria contínua, conheça as estratégias das squads da BossaBox appeared first on BossaBox.

Introdução

O Express.js é um ótimo framework para criar APIs REST com node.js, mas não nos dá nenhuma pista sobre como organizar nossa Arquitetura de projeto.

Embora possa parecer simples, este é um problema real.

Organizar a estrutura de um projeto em node.js irá evitar a duplicação de código, irá melhorar a estabilidade e, potencialmente, ajudará você a dimensionar seus serviços se for feito da forma certa.

LEIA TAMBÉM: Impacto da IA: como os desenvolvedores estão utilizando e enxergando essa tecnologia?

Este artigo é uma extensa pesquisa dos meus anos de experiência lidando com projetos node.js mal estruturados, padrões ruins e incontáveis horas reescrevendo códigos e ajustando coisas.

A Estrutura de Pastas 🏢

Aqui está a arquitetura do projeto node.js da qual estou falando.

Eu uso isso em todos os serviços de node.js REST API que crio, vamos ver em detalhes o que cada componente faz.
src
│ app.js # App entry point
└───api # Express route controllers for all the endpoints of the app
└───config # Environment variables and configuration related stuff
└───jobs # Jobs definitions for agenda.js
└───loaders # Split the startup process into modules
└───models # Database models
└───services # All the business logic is here
└───subscribers # Event handlers for async task
└───types # Type declaration files (d.ts) for Typescript

É mais do que apenas uma maneira de ordenar arquivos javascript…

Arquitetura de 3 camadas 🥪

A ideia é usar o princípio da separação de interesses para afastar a lógica de negócios das rotas da API.

Porque algum dia, você vai querer usar sua lógica de negócios em uma ferramenta CLI, ou até mesmo algo mais próximo, como uma tarefa recorrente.

E fazer uma conexão da API do servidor node.js para ela mesmo, não é uma boa ideia…

☠️ Não coloque sua lógica de negócios dentro dos controllers!!☠️

Você pode ficar tentado usar os controllers para armazenar a lógica de negócios do seu aplicativo, mas isso rapidamente se torna um código sem estrutura e difícil de compreender, no momento em que precisar fazer testes de unidade, você acabará lidando com simulações complexas para objetos express.js como req ou res.

É complicado distinguir quando uma resposta deve ser enviada e quando continuar o processamento em ‘background’, digamos depois que a resposta é enviada ao cliente.

Aqui está um exemplo do que não fazer.

route.post('/', async (req, res, next) => {


// This should be a middleware or should be handled by a library like Joi.
const userDTO = req.body;
const isUserValid = validators.user(userDTO)
if(!isUserValid) {
return res.status(400).end();
}


// Lot of business logic here...
const userRecord = await UserModel.create(userDTO);
delete userRecord.password;
delete userRecord.salt;
const companyRecord = await CompanyModel.create(userRecord);
const companyDashboard = await CompanyDashboard.create(userRecord, companyRecord);


...whatever...


// And here is the 'optimization' that mess up everything.
// The response is sent to client...
res.json({ user: userRecord, company: companyRecord });

// But code execution continues :(
const salaryRecord = await SalaryModel.create(userRecord, companyRecord);
eventTracker.track('user_signup',userRecord,companyRecord,salaryRecord);
intercom.createUser(userRecord);
gaAnalytics.event('user_signup',userRecord);
await EmailService.startSignupSequence(userRecord)
});

Use uma camada de serviço para sua lógica de negócios 💼

Essa camada é onde sua lógica de negócios deve residir.

É apenas uma coleção de classes com propósitos claros, seguindo os princípios do SOLID aplicados ao node.js.

Nesta camada não deve existir nenhuma forma de ‘SQL Querry’, use a camada de acesso a dados para isso.

• Mova seu código para longe do express.js router
• Não passe o objeto req ou res para a camada de serviço
• Não retorne nada relacionado à camada de transporte HTTP, como um status code ou headers da camada de serviço.

Exemplo:

route.post('/',
validators.userSignup, // this middleware take care of validation
async (req, res, next) => {
// The actual responsability of the route layer.
const userDTO = req.body;

// Call to service layer.
// Abstraction on how to access the data layer and the business logic.
const { user, company } = await UserService.Signup(userDTO);

// Return a response to client.
return res.json({ user, company });
});

Aqui está como seu serviço funcionará por de trás dos panos.

import UserModel from '../models/user';
import CompanyModel from '../models/company';

export default class UserService() {

async Signup(user) {
const userRecord = await UserModel.create(user);
const companyRecord = await CompanyModel.create(userRecord); // needs userRecord to have the database id
const salaryRecord = await SalaryModel.create(userRecord, companyRecord); // depends on user and company to be created

...whatever

await EmailService.startSignupSequence(userRecord)

...do more stuff

return { user: userRecord, company: companyRecord };
}
}

Visit the example repository

Use uma camada Pub/Sub também 🎙️

O padrão pub/sub vai além da arquitetura clássica de 3 camadas proposta aqui, e é extremamente útil.

O endpoint simples da API node.js, que cria um usuário instantaneamente, pode querer chamar serviços de terceiros, talvez para um serviço de análise ou então iniciar uma sequência de e-mail.

Mais cedo ou mais tarde, essa simples operação de “criar” fará várias coisas e você terminará com 1.000 linhas de código, tudo em uma única função.

Isso viola o princípio da responsabilidade única.

Portanto, é melhor separar as responsabilidades desde o início, para que seu código permaneça sustentável.

import UserModel from '../models/user';
import CompanyModel from '../models/company';
import SalaryModel from '../models/salary';

export default class UserService() {

async Signup(user) {
const userRecord = await this.userModel.create(user);
const companyRecord = await this.companyModel.create(user);
this.eventEmitter.emit('user_signup', { user: userRecord, company: companyRecord })
return userRecord
}

}

Uma chamada obrigatória para um serviço dependente não é a melhor maneira de fazer isso.

Uma abordagem melhor é emitir um evento, ou seja, ‘um usuário se inscreveu com este e-mail’.

E pronto, agora é responsabilidade dos listeners fazerem seu trabalho.

import UserModel from '../models/user';
import CompanyModel from '../models/company';
import SalaryModel from '../models/salary';

export default class UserService() {

async Signup(user) {
const userRecord = await this.userModel.create(user);
const companyRecord = await this.companyModel.create(user);
this.eventEmitter.emit('user_signup', { user: userRecord, company: companyRecord })
return userRecord
}

}

Agora você pode dividir os eventos de handlers/listeners em vários arquivos.

eventEmitter.on('user_signup', ({ user, company }) => {

eventTracker.track(
'user_signup',
user,
company,
);

intercom.createUser(
user
);

gaAnalytics.event(
'user_signup',
user
);
})

eventEmitter.on('user_signup', async ({ user, company }) => {
const salaryRecord = await SalaryModel.create(user, company);
})


eventEmitter.on('user_signup', async ({ user, company }) => {
await EmailService.startSignupSequence(user)
})

Você pode agrupar as instruções await em um bloco try-catch ou [você pode simplesmente deixá-lo falhar e lidar com o ‘unhandledPromise’ process.on(‘unhandledRejection’,cb)

Injeção de Dependência 💉

Injeção de Dependência (ID) ou inversão de controle (IoC) é um padrão comum que ajudará na organização do seu código, “injetando” ou passando pelo construtor as dependências de sua classe ou função.

Ao fazer isso, você terá a flexibilidade de injetar uma ‘dependência compatível’ quando, por exemplo, escrever os testes de unidade para o serviço ou quando o serviço for usado em outro contexto.

Código sem ID

import UserModel from '../models/user';
import CompanyModel from '../models/company';
import SalaryModel from '../models/salary';
class UserService {
constructor(){}
Sigup(){
// Calling UserModel, CompanyModel, etc
...
}
}

Código com injeção manual de dependência

export default class UserService {
constructor(userModel, companyModel, salaryModel){
this.userModel = userModel;
this.companyModel = companyModel;
this.salaryModel = salaryModel;
}
getMyUser(userId){
// models available throug 'this'
const user = this.userModel.findById(userId);
return user;
}
}

Agora você pode injetar dependências personalizadas.

import UserService from '../services/user';
import UserModel from '../models/user';
import CompanyModel from '../models/company';
const salaryModelMock = {
calculateNetSalary(){
return 42;
}
}
const userServiceInstance = new UserService(userModel, companyModel, salaryModelMock);
const user = await userServiceInstance.getMyUser('12346');

A quantidade de dependências que um serviço pode ter é infinita, e refatorar cada instanciação dele quando você adiciona um novo é uma tarefa chata e que abre espaços para erros.

É por isso que os frameworks de injeção de dependência foram criados.

A ideia é você declarar suas dependências na classe, e quando precisar de uma instância dessa classe, basta chamar o ‘Service Locator’.

Vamos ver um exemplo usando typedi uma biblioteca npm que traz ID para node.js

Você pode ler mais sobre como usar o typedi na documentação oficial

AVISO exemplo de typescript

import { Service } from 'typedi';
@Service()
export default class UserService {
constructor(
private userModel,
private companyModel,
private salaryModel
){}

getMyUser(userId){
const user = this.userModel.findById(userId);
return user;
}
}

services/user.ts

Agora, o typedi irá resolver qualquer dependência exigida pelo UserService.

import { Container } from 'typedi';
import UserService from '../services/user';
const userServiceInstance = Container.get(UserService);
const user = await userServiceInstance.getMyUser('12346');

Usando injeção de dependência com Express.js em Node.js

Usando Injeção de Dependencias. em express.js é a peça final do quebra-cabeça para esta arquitetura de projeto node.js.

Camada de roteamento

route.post('/',
async (req, res, next) => {
const userDTO = req.body;

const userServiceInstance = Container.get(UserService) // Service locator

const { user, company } = userServiceInstance.Signup(userDTO);

return res.json({ user, company });
});

Incrível, o projeto está ficando ótimo! É tão organizado que me faz querer codar agora mesmo.

Um exemplo de teste unitário 🕵🏻

Ao usar a injeção de dependência e esses padrões de organização, o teste unitário se torna realmente simples.

Você não precisa simular objetos req/res ou require(…) calls.

tests/unit/services/user.js

import UserService from '../../../src/services/user';

describe('User service unit tests', () => {
describe('Signup', () => {
test('Should create user record and emit user_signup event', async () => {
const eventEmitterService = {
emit: jest.fn(),
};

const userModel = {
create: (user) => {
return {
...user,
_id: 'mock-user-id'
}
},
};

const companyModel = {
create: (user) => {
return {
owner: user._id,
companyTaxId: '12345',
}
},
};

const userInput= {
fullname: 'User Unit Test',
email: 'test@example.com',
};

const userService = new UserService(userModel, companyModel, eventEmitterService);
const userRecord = await userService.SignUp(teamId.toHexString(), userInput);

expect(userRecord).toBeDefined();
expect(userRecord._id).toBeDefined();
expect(eventEmitterService.emit).toBeCalled();
});
})
})

Cron Jobs and recurring task ⚡

Com isso, agora que a lógica de negócios está encapsulada na camada de serviço, é mais fácil usá-la a partir de um Cron Job.

Você nunca deve confiar em node.js setTimeout ou outra forma antiga de atrasar a execução do código, mas em uma arquitetura de projeto que mantenha seus jobs e a execução deles em um banco de dados.

Dessa forma, você terá controle sobre os jobs que falharam e feedback daqueles que obtiveram sucesso. Eu já escrevi sobre boas práticas para isso, confira meu guia sobre como usar agenda.js, o melhor gerenciador de tarefas para node.js.

Configurações e segredos 🤫

Seguindo os conceitos amplamente testados do Twelve-Factor App para node.js, a melhor abordagem para armazenar chaves de API e conexões de string de banco de dados, é usar o dotenv.

Coloque um arquivo .env , que nunca deve ser commitado (mas tem que existir com valores default em seu repositório) então, o pacote npm dotenv carrega o arquivo .env e insere os vars no processo . env de node.js.

Isso pode ser suficiente, mas eu gosto de adicionar um passo extra. Ter um arquivo config/index.ts onde o pacote dotenv npm carrega o arquivo .env e então eu uso um objeto para armazenar as variáveis, assim temos uma estrutura de código que se autocomplementa.

config/index.js

const dotenv = require('dotenv');
// config() will read your .env file, parse the contents, assign it to process.env.
dotenv.config();

export default {
port: process.env.PORT,
databaseURL: process.env.DATABASE_URI,
paypal: {
publicKey: process.env.PAYPAL_PUBLIC_KEY,
secretKey: process.env.PAYPAL_SECRET_KEY,
},
paypal: {
publicKey: process.env.PAYPAL_PUBLIC_KEY,
secretKey: process.env.PAYPAL_SECRET_KEY,
},
mailchimp: {
apiKey: process.env.MAILCHIMP_API_KEY,
sender: process.env.MAILCHIMP_SENDER,
}
}

Dessa forma, você evita floodar seu código com instruções process.env.MY_RANDOM_VAR, usando o preenchimento automático, você não precisa saber como nomear o env var.

Loaders🏗️

Peguei esse padrão de W3Tech microframework mas sem depender de seu package.

A ideia é que você divida o processo de inicialização do seu serviço node.js em módulos testáveis.

Vamos ver uma inicialização clássica do aplicativo express.js

const mongoose = require('mongoose');
const express = require('express');
const bodyParser = require('body-parser');
const session = require('express-session');
const cors = require('cors');
const errorhandler = require('errorhandler');
const app = express();

app.get('/status', (req, res) => { res.status(200).end(); });
app.head('/status', (req, res) => { res.status(200).end(); });
app.use(cors());
app.use(require('morgan')('dev'));
app.use(bodyParser.urlencoded({ extended: false }));
app.use(bodyParser.json(setupForStripeWebhooks));
app.use(require('method-override')());
app.use(express.static(__dirname + '/public'));
app.use(session({ secret: process.env.SECRET, cookie: { maxAge: 60000 }, resave: false, saveUninitialized: false }));
mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });

require('./config/passport');
require('./models/user');
require('./models/company');
app.use(require('./routes'));
app.use((req, res, next) => {
var err = new Error('Not Found');
err.status = 404;
next(err);
});
app.use((err, req, res) => {
res.status(err.status || 500);
res.json({'errors': {
message: err.message,
error: {}
}});
});

... more stuff

... maybe start up Redis

... maybe add more middlewares

async function startServer() {
app.listen(process.env.PORT, err => {
if (err) {
console.log(err);
return;
}
console.log(`Your server is ready !`);
});
}

// Run the async function to start our server
startServer();

Como você pode ver, esta parte do seu aplicativo pode ser uma verdadeira bagunça.

Essa é uma forma eficiente de resolve-la

const loaders = require('./loaders');
const express = require('express');

async function startServer() {

const app = express();

await loaders.init({ expressApp: app });

app.listen(process.env.PORT, err => {
if (err) {
console.log(err);
return;
}
console.log(`Your server is ready !`);
});
}

startServer();

Agora os Loaders são apenas pequenos arquivos com um propósito conciso

loaders/index.js

import expressLoader from './express';
import mongooseLoader from './mongoose';

export default async ({ expressApp }) => {
const mongoConnection = await mongooseLoader();
console.log('MongoDB Initialized');
await expressLoader({ app: expressApp });
console.log('Express Initialized');

// ... more loaders can be here

// ... Initialize agenda
// ... or Redis, or whatever you want
}

O express loader

import * as express from 'express';
import * as bodyParser from 'body-parser';
import * as cors from 'cors';

export default async ({ app }: { app: express.Application }) => {

app.get('/status', (req, res) => { res.status(200).end(); });
app.head('/status', (req, res) => { res.status(200).end(); });
app.enable('trust proxy');

app.use(cors());
app.use(require('morgan')('dev'));
app.use(bodyParser.urlencoded({ extended: false }));

// ...More middlewares

// Return the express app
return app;
})

O mongo Loader

import * as mongoose from 'mongoose'
export default async (): Promise<any> => {
const connection = await mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });
return connection.connection.db;
}

Conclusão

Nós nos aprofundamos em uma arquitetura de projeto node.js testada em produção, aqui estão algumas dicas resumidas:

• Use uma arquitetura de 3 camadas.
• Não coloque sua lógica de negócios nos controladores express.js.
• Use o padrão PubSub e libera eventos para tarefas em background.
• Tenha injeção de dependência para acalmar sua alma.
• Nunca vaze suas senhas, segredos e chaves de API, use um gerenciador de configuração.
• Divida as configurações do seu servidor node.js em pequenos módulos que podem ser carregados independentemente.

The post Arquitetura de projeto node.js à prova de balas appeared first on BossaBox.