Fluig
Development Patterns
Padrões de Nomes ✍️

Padrões de Nomes e Estruturas em Projetos Fluig 🛠️

Na jornada de desenvolvimento e manutenção de projetos Fluig, uma das etapas cruciais para o sucesso e a sustentabilidade a longo prazo é a definição e aplicação de padrões. Esses padrões não apenas facilitam a organização e a compreensão do projeto por parte de todos os envolvidos mas também otimizam o processo de desenvolvimento, manutenção e escalabilidade. Este artigo se propõe a ser um guia definitivo sobre os padrões de nomes de arquivos e funções em projetos Fluig, cobrindo desde Datasets até Formulários, passando por Diagramas e Funções JavaScript, e muito mais.

Entender e implementar padrões de nomenclatura e estruturação não é apenas uma prática recomendada; é um pilar fundamental para qualquer equipe que aspire à excelência em seus projetos Fluig. Com a vastidão de componentes como Datasets, Formulários, Diagramas, e Funções JS, uma abordagem padronizada não só simplifica a gestão dos elementos mas também garante uma melhor colaboração entre os desenvolvedores e outros stakeholders do projeto.

Neste artigo, exploraremos:

  • Datasets: Como nomeá-los de forma a refletir claramente seu propósito e fonte de dados.
  • Formulários: Estratégias para nomear formulários de maneira a facilitar sua identificação e função dentro do projeto.
  • Diagramas de Processos: Dicas para a criação de diagramas claros e bem estruturados, que facilitem a compreensão dos fluxos de trabalho.
  • Funções JavaScript: Práticas recomendadas para nomear funções de forma descritiva, tornando o código mais legível e manutenível.

Além disso, discutiremos a importância de uma documentação clara e abrangente, que acompanhe esses padrões, assegurando que a equipe e futuros desenvolvedores possam facilmente compreender e seguir as convenções estabelecidas.

Regra Geral dos Nomes

Em geral, adotamos o padrão Camel Case para a nomeação de elementos no Mundo Fluig. Essa convenção implica em iniciar a denominação com letra minúscula, seguida pela capitalização das primeiras letras de cada palavra subsequente, sem espaços entre elas. A seguir, detalhamos as diretrizes específicas para cada tópico dentro do Mundo Fluig.

Datasets

Para nomear Datasets, é recomendado utilizar o padrão Camel Case conforme descrito na regra geral, porém também é preciso considerar o processo que esse dataset está inserido:

Exemplo:

Se o Dataset a ser criado vai ser usado num formulário chamado "Cadastro de Fornecedores" e o dataset vai retornar a lista de estados para complementar o Cadastro, então nesse caso é preferível que o nome do Dataset Seja:

cadastroFornecedor_estados.js

Use sempre o contexto que o dataset vai ser usado para poder definir o prefixo e também organizar a pasta de datasets:

ℹ️

Pasta Datasets

      • cadastroFornecedor_estados.js

    • Formulários

    Quando falamos de formulários, o nosso padrão não é só usar Camel Case; a gente também separa os arquivos do projeto de acordo com as funções deles, tentando manter tudo bem conciso. Aqui vai a estrutura padrão:

    ℹ️

    Pasta Forms

        • displayFields.js
        • cadastroFornecedor.css
        • zoom.js
        • inicializacao.js
        • validacaoCampos.js
        • tabelas.js
        • regrasNegocio.js
        • cadastroFornecedor.js
        • beforeSendValidate_PE.js
        • LIBDEVEREST.js
      • cadastroFornecedor.html

    • Os detalhes sobre os motivos por trás de cada arquivo e nome serão fornecidos na seção específica dos formulários.

    Falando de formulários, temos dois pontos importantes sobre a organização dos campos:

    1. Ids: Aqui, a gente segue o padrão camel case. É uma regra geral para manter a consistência.

    2. Labels: Esses são ajustados de acordo com o que cada projeto precisa. Não tem uma regra única; depende do contexto do projeto.

    Uma observação importante sobre os ids dos campos: se esses campos forem usados para conectar sistemas diferentes, é crucial usar o mesmo nome do campo do sistema com o qual vamos integrar. Isso ajuda demais no desenvolvimento da integração, tornando o processo melhor para desenvolver.

    O Nome do Dataset do Formulário deve seguir o mesmo do formulário.

    Diagramas

    Ao trabalhar com diagramas, é importante seguir um conjunto de padrões de nomenclatura para manter a consistência em toda a documentação do projeto. Aqui estão as diretrizes gerais que usamos, seguindo o padrão Camel Case.

    Nome do Diagrama

    Para nomear um diagrama, siga o formato cadastroFornecedor. Esse padrão é essencial para identificar claramente o propósito do diagrama.

    Nome da Atividade

    As atividades dentro dos diagramas devem ser nomeadas com um verbo seguido da ação ou atividade correspondente. Aqui estão as especificações para nomear diferentes tipos de atividades:

    • Atividades de Serviço (Gerúndio): Quando as atividades integram com algum sistema, a nomenclatura deve incluir a ação seguida do nome do sistema. Por exemplo:

      • GerandoPA no Protheus para indicar a geração de um PA (Ponto de Acesso) no sistema Protheus.
      • Para uma atividade que envolve enviar um email ao solicitante, use EnviandoEmailSolicitante.

    • Atividades Exclusivas: Para atividades que representam ações exclusivas, a nomenclatura deve ser sempre uma pergunta. Exemplos incluem:

      • GeraPedido? para questionar se um pedido será gerado.
      • IncluiSolicitação? para indagar sobre a inclusão de uma solicitação.

    Seguir esses padrões ajudará a garantir que os novos desenvolvedores possam entender facilmente a estrutura e o propósito de cada diagrama e atividade.

    Serviços

    Aqui estão as diretrizes específicas para nomear serviços em nossos projetos, garantindo clareza e consistência em toda a documentação e implementação.

    Nome do Serviço

    O nome atribuído a um serviço depende do tipo de tecnologia ou protocolo utilizado. Abaixo estão os padrões para cada tipo:

    SOAP Fluig

    • Manter o nome original. Para serviços SOAP utilizados no Fluig, a regra é simples: mantenha o nome original do serviço sem alterações.

    JDBC

    • ProtheusHML
      • Descrição: Este nome é utilizado para se referir à conexão JDBC com o Protheus no ambiente de homologação. Especificamente, ele aponta para o SQL Server DataBaseName: HOMOLOGACAO.

    REST

    • api + 'Nome da API'. Para serviços REST, o padrão de nomeação incorpora a palavra api seguida do nome da API. Por exemplo, apiInfoSimples.
      • Descrição: Este exemplo, apiInfoSimples, refere-se à "Api Info Simples V2". É uma maneira direta de nomear serviços REST, indicando claramente a função da API.

    Esses padrões de nomeação foram estabelecidos para ajudar os desenvolvedores a entender rapidamente a função e o contexto de cada serviço, além de facilitar a manutenção e a escalabilidade dos nossos sistemas.

    # dev.startHere()# Do Começo