Arquitetura Front-End: Definindo padrões

Efetivamente o que acontece quando escrevemos código, navegamos pelo projeto e continuamos construindo funcionalidades e mantendo o software, é que nosso cérebro está aprendendo em algum nível, mesmo que não sejam informações completamente novas:

“Aprender é um processo ativo de filtrar, selecionar, organizar e integrar informações baseadas em um conhecimento anterior” — Aprendizado multimídia de Richard Mayer

Definir padrões de um projeto é facilitar esse processo ativo para os integrantes da equipe. Afinal de contas, você e a equipe vão passar entre 4 a 6 horas por dia, todo dia da semana, por vários meses ou anos olhando e pensando sobre esse projeto, não seria inteligente organizá-lo de forma a minimizar stress e facilitar a produtividade?

Razões para definir padrões

• Diminuir a sobrecarga cognitiva
• Diminuir a quantidade de energia gasta com tomada de decisões
• Tornar o processo de trabalho mais rápido naturalmente
• Se comunicar melhor com a equipe
• Se comunicar melhor com o seu “eu” do futuro
• Facilitar o onboarding de novos desenvolvedores
• Aumentar a meia vida do projeto
• Deixar um bom legado quando você sair do projeto.

O fator tempo

Quanto menor o tempo de vida, menos benefícios você vai extrair de decidir padrões. Entretanto, se o tempo de vida for grande mas você não tiver certeza e decidir começar sem padrões, o custo de dívida técnica vai matar o projeto lá na frente.

Photo by Alice Pasqual on Unsplash

Estritamente falando, tudo desde a definição dos objetivos de negócio do projeto, criação de user stories ou feature stories, UX e design, escolha de tecnologias, organização de pastas até o código em si e depois o processo de deploy e acompanhamento de dados é padrão de projeto, direta ou indiretamente. Num mundo ideal todos os profissionais ou áreas envolvidas entendem a igual importância do trabalho de todos e definem padrões em conjunto do início ao fim do projeto. Na maioria das vezes, porém, não é esse o caso e podemos focar no que temos controle:

Organização de pastas

Pastas são compartimentos de arquivos selecionados, filtrados e organizados. Separar arquivos em pastas possibilita que o seu cérebro diga “não” para um conjunto de arquivos que você não precisa se preocupar naquele momento.

• Encontre um equilíbrio na quantidade, se você tem arquivos demais, considere agrupá-los em pastas
• Evite pastas dentro de pastas, quanto mais subpastas você tiver, maior é a complexidade cognitiva e mais você precisa lembrar para se situar naquele contexto
• Quanto mais “flat” for sua estrutura de pastas, mais fácil será de encontrar o que precisa (menos cliques)
• Procure organizar as pastas de forma mais intuitiva possível, idealmente sem a necessidade de documentação
• Também se preocupe com a composição do caminho de um arquivo, não só ele isoladamente.

Nomenclatura

Da mesma forma que o título de um livro ou artigo deve passar rapidamente o significado da obra, nomes de pastas, arquivos, funções, variáveis e classes devem ser claros e intuitivos quanto ao contexto, tipo de uso e relevância. Existem alguns padrões definidos de nomenclatura, geralmente divididos em sintaxe e semântica.

• Quanto a sintaxe, você deve definir entre camelCase, PascalCase, snake_case, e kebab-case, e algumas regras básicas como não usar caracteres especiais ou espaços
• Devido a regras de linguagens de programação, talvez você precise usar um dos formatos acima, especificamente para variáveis ou funções
• Você pode usar um tipo de “case” diferente para pastas e arquivos, outro para funções e variáveis, outro para classes e assim por diante desde que mantenha a consistência
• Comece um arquivo com _ se ele for de uso interno ou de baixa relevância para a maioria das pessoas
• Nomeie arquivos lembrando que eles vão ser encontrados por busca também além de manualmente navegando pelas pastas e os nomes precisam ser auto-suficientes
• Quanto a semântica, escolha nomes que representem o significado em questão.

Arquivos

Quanto ao conteúdo dos arquivos em si, otimize a quantidade de informação e contextos, o tamanho das linhas e a ordem de leitura.

• Evite linhas longas de código
• Ao mesmo tempo prefira código claro e um pouco mais longo do que misterioso e curto
• Mantenha cada função com apenas uma responsabilidade
• Prefira arquivos com pouco código
• Se for possível, mantenha uma função por arquivo ou um contexto/responsabilidade por arquivo
• Organize o seu arquivo por “ordem de leitura”, as ações relevantes primeiro, e as dependências e definições em seguida
• Mantenha variáveis de configuração primeiro, depois a lógica e manipulação e por último o retorno ou apresentação
• Remova “strings” e conteúdos de arquivos de código e os coloque em um json
• Usar funções puras faz com que o significado de cada função seja óbvio e previsível
• Se seus arquivos forem bem padronizados, tenha arquivos modelo para criar novos.

Arquitetura

Além de organizar pastas, arquivos e ter uma boa nomenclatura, é muito útil ter um padrão de comunicação entre arquivos e funcionalidades. Aqui é onde entram as camadas de abstração para tornar menos caótico o processo de reutilização de código e os pontos de conexão e dependência dentro da sua aplicação. Não usar arquitetura nenhuma é possível em projetos pequenos e muito simples, mas para qualquer site de produto (não só institucional), escolher uma arquitetura é fundamental. Aqui é onde os frameworks geralmente entram. Essa parte merece um artigo a parte, mas de maneira geral:

• Uma boa arquitetura vai passar por todas as camadas da aplicação: marcação, semântica, acessibilidade e SEO; aparência e estilos; lógica (comunicação com apis, camada de dados, mutação de dados e apresentação)
• Escolha uma opção que crie um modelo mental que fique confortável para a equipe, ou você mesmo caso esteja sozinho
• A melhor arquitetura sempre será o diálogo e boa comunicação da equipe
• Lembre-se que cada dependência adiciona uma complexidade ao seu projeto.

Documentação

Faz uma diferença enorme ter documentação no seu projeto, que podem englobar:

• Uma introdução ao projeto, como instalar, rodar, contribuir e fazer deploy
• A arquitetura, as decisões tomadas e o objetivo de cada ferramenta utilizada
• Code standards, com os padrões de nomenclatura, organização e linguagem. Use referências de mercado e adapte quando necessário, existem docs para Javascript (como o do airbnb), CSS (como BEM, SMACSS, ITCSS, RSCSS) e HTML.

De acordo com o filósofo Byung-Chul Han, vivemos numa era de violência neuronal:

“A violência em nossa sociedade é neuronal. […] Agora, segundo o esquema neuronal, a positividade é a prática de violência como resultado da superprodução, do superdesempenho, da supercomunicação. […] Superaquecemos por um excesso de positividade! Não há saída para quem tem o mundo à disposição, como nós. Somos atingidos por bombas de imagens, sons, vídeos, anúncios, produtos. Temos o mundo ao alcance das mãos e nos nossos bolsos. Parece que não há mais espaço para criar mundos. Eles já estão todos aí com as devidas hashtags.” — Byung-Chul Han — Sociedade do cansaço

Photo by Mark Tegethoff on Unsplash

Portanto, devemos ter a ambição de pensar um pouco menos e ter menos sobrecarga cognitiva nos nossos projetos. Menos ferramentas, menos código, portanto menos decisões e menos reuniões. Da mesma forma que o design preconiza a organização visual, o uso de espaço, alinhamento, proporção e gestalt para tornar a “leitura” visual o mais confortável possível, nós precisamos fazer o mesmo com o código.