[pt-BR] Regra de negócio para desenvolvedores front-end

Você sabe o que é um roadmap? Traduzindo do inglês ao pé da letra significaria algo como "mapa de estradas", ou seja, é um roteiro ou um mapa de caminhos para se chegar a algum lugar.

Se você der um google em "roadmap developer", você encontrará muitos desses mapas, normalmente em formato de fluxograma, que exibem tecnologias e linguagens, afim de orientar os estudos na programação*.

Eu mesma utilizo o roadmap de front-end para mapear quais as tecnologias já tive contato ou algum tipo de experiência e entender o quanto eu já sei e os assuntos que ainda preciso aprender.

Entretanto, existem alguns tópicos que fazem muita diferença para evolução do profissional de desenvolvimento e que normalmente não serão encontrados nesses roadmaps que dão foco nas trilhas técnicas.

Mas tão importante quanto progredir tecnicamente, o desenvolvimento de habilidades comportamentais, como por exemplo, comunicação, proatividade e colaboração, também devem estar sempre em nosso radar quando se trata da nossa evolução profissional.

E dentre todas essas habilidades, a que mais tenho sido ensinada a procurar desenvolver é a capacidade analítica, principalmente quando falamos das famosas Regras de Negócio.

Tenho certeza que durante seus estudos você já ouviu falar delas, e agora vou mostrar o porque a capacidade de analisá-las está diretamente relacionada ao sucesso das suas entregas.

Ser ou fazer, eis a questão

Também chamado de Requisitos Funcionas, as as Regras de Negócio, hoje em dia, sempre estão atreladas ao contexto de sistemas. O software não existe e não sobrevive sem ter suas regras, requisitos ou exigências muito bem estabelecidos e entendidos.

Ao invés de perguntar COMO tal sistema deve SER, como por exemplo, em qual linguagem ele será codado ou em qual banco os dados serão armazenados, a regra de negócio está interessada em saber O QUE o sistema deve FAZER. Por exemplo:

• O Sistema deve cadastrar clientes (entrada).
• O Sistema deve emitir um relatório de clientes (saída).
• O cliente pode consultar seus dados no sistema

As regras de negócio atendem a necessidades de um usuário, exigências do negócio, desejos e solicitações da empresa e permitem que tudo isso seja materializado num sistema.

Faz parte da área de arquitetura e engenharia de software a especialização e estudo mais aprofundado de requisitos, assim como seus atributos e características.

Portanto, o programador não precisa ser um especialista na definição de regras de negócio pois não vai ser ele que vai projetá-las ou muito menos documentá-las.

Em cenários ideais, essa tarefa pertence a outros profissionais como Arquitetos e Engenheiros de Software ou Analista de Negócios. Cada macaco no seu galho (rs).

Não seja uma máquina de escrever códigos

Parafraseando meu chefe: "Linguagem de programação o Google ensina, preocupe-se em entender o porque você está codando."

Hoje em dia, existem tantas ferramentas que já programam sozinhas e um código até mais lógico e limpo que um ser humano poderia fazer (rs). A própria IDE IntelliJ é um exemplo de ferramenta que olha seu código e sugere uma refatoração melhorada.

Não significa que não devemos nos preocupar em sempre melhorar tecnicamente, pois será a sua capacidade técnica que vai permitir que você traduza as regras de negócio do português para a linguagem de programação.

Lembre-se que hoje em dia, o termo programador não é e não pode ser sinônimo de uma "máquina de codar". O profissional da programação está mais próximo ao conceito do analista de sistemas, aquele que estuda com objetivo de encontrar os melhores caminhos e soluções para necessidades reais de pessoas reais.

Portanto, desenvolver outras habilidades como essa de conhecer, compreender e analisar Regras de Negócio é o que uma das diversas habilidades pode nos diferenciar de um mediano, um bom ou um excelente programador.

E como funciona na prática?

Pensando no contexto do desenvolvimento frontend, vamos para um cenário simples para exemplificar. Supondo que a tarefa seja:

"Implementar um modal que exiba uma mensagem X quando o usuário clicar em um botão Y. Esse modal terá 2 opções de escolha, Sim e Não."

Talvez o primeiro pensamento seja: preciso estruturar e estilizar o modal (com HTML), e acioná-lo ao clique do botão (com JavaScript). É aqui que muitas dúvidas surgem e que as regras de negócio vão atuar.

Elas vão responder coisas como:

• A exibição do botão limita-se a algum acesso do usuário? Todos os usuários vão visualizar o botão, ou apenas alguns?

• Existe alguma regra que habilita meu botão? Em algum momento esse botão pode vir a ficar desabilitado?

• O que acontece se o usuário fechar o modal? O que acontece depois que o usuário clicar em Sim? O que acontece depois que o usuário clicar em Não?

Ou seja, o desenvolvedor front-end, além de ter que se preocupar que seu componente seja exibido de maneira correta, deve se preocupar se ele terá o comportamento correto e no momento correto, cumprindo regras específicas.

Concluindo

Obviamente que regra de negócio é um assunto extenso e muito mais do que descrevi neste artigo. Entretanto, meu objetivo aqui é principalmente alinhar as expectativas dos estudantes de desenvolvimento e daqueles que estão na sua primeira experiência como dev no mercado de trabalho.

Antes de começar a trabalhar, eu realmente achava que ser desenvolvedor era ser um expert em alguma linguagem de programação, ou que ser front-end se limitava a codar components e fazer estilizações. Bem inocente.

Mas conforme fui pegando experiência, percebi que grande parte do meu desenvolvimento como profissional está mais relacionado em analisar as demandas e entender os motivos para qual estou trabalhando. E isso é muito bom, pois até traz um senso se pertencimento e aumenta a motivação. Melhor do que ver uma feature funcionando na tela, é saber que ela é útil e necessária para as pessoas que utilizam o sistema.

Por fim, quero deixar uma citação parafraseada que vi em algum evento da Rocketseat:

"Para evoluir temos que evitar nos tornarmos um Charlie Chaplin do Tempos Modernos: aquele que, preso em uma mecanicidade, apenas aperta parafusos e não se lembra do porque faz as coisas."

*O site https://roadmap.sh/ disponibiliza roadmaps atualizados, tanto para frontend, backend, devops e outras tecnologias.