Um problema que vejo se repetir em projetos no front-end é que conforme eles crescem e mais pessoas trabalham nele, menos as decisões são reutilizadas. Por exemplo, em um projeto com poucas pessoas é muito simples manter um padrão de qualidade e uso dos recursos disponíveis; lembrar de sempre reutilizar componentes, cores, margens, normalizers, etc.
Porém, conforme mais pessoas trabalham no projeto, mais difícil é manter esse controle porque a reutilização de recursos depende da comunicação de que eles existem, do ponto de vista de quem está criando algo é mais simples e intuitivo escrever uma nova regra com o que você precisa do que procurar padrões pré estabelecidos que podem ou não existir.
Portanto, quanto mais pessoas no time e maior o sistema, menos provável que padrões e boas práticas sejam seguidas ou descobertas, e quanto mais decisões individuais são tomadas mais complexidade é adicionada ao sistema, o que dificulta ainda mais a adoção de convenções no projeto.
Este post é uma introdução a certas ferramentas que podem fazer esse trabalho de comunicação para você. Nenhuma dessas ferramentas garante que o retrabalho não vai acontecer, porém, tornam a reutilização de ferramentas já existentes um caminho mais fácil e intuitivo para quem está criando algo novo.
O problema
Fonte: elaborada pelo autor
O exemplo acima ilustra bem o problema. A cada nova demanda, um novo layout é entregue à pessoa que desenvolve, com cores levemente diferentes que são adicionadas ao leque de cores do projeto, em alguns casos até adicionadas manualmente no momento em que precisam ser usadas.
Além do custo no tempo de desenvolvimento que isso gera, também faz com que os componentes do projeto não tenham uma aparência consistente, cada um é levemente refeito e levemente diferente do anterior.
Novas demandas deveriam fazer com que as demandas seguintes tivessem um caminho das pedras já trilhado onde possível, complexidades e decisões no desenvolvimento deveriam ser fontes de aprendizado, e não de retrabalho.
Em quase todas as áreas de desenvolvimento de software tentamos sempre prestar muita atenção para evitar esse tipo de problema, mas no front-end essa prática não recebe tanta atenção assim. O que tentaremos neste post é fazer com que essa má prática seja mitigada onde possível.
As possíveis soluções
Abaixo estão algumas das tecnologias que gosto de usar para fazer com que o caminho mais simples e intuitivo seja o das convenções pré estabelecidas. Nenhuma dessas ferramentas torna o retrabalho impossível, assim como linters podem ser ignorados, todas essas ferramentas podem ser facilmente ignoradas.
A questão é que ignorar essas ferramentas exige mais tempo e esforço do que simplesmente seguir o fluxo de desenvolvimento, e isso auxilia na frequência com que boas práticas são seguidas.
Tailwind
Com o tailwind temos um local fixo e específico para registrar novas classes de CSS.
Fonte: elaborada pelo autor
Em um projeto onde um sistema de temas é usado (com ou sem o tailwind) é muito mais fácil evitar que existam diversas variações da mesma regra espalhadas por vários lugares. O mau uso ainda é possível, como na foto anterior onde havia um tema com tantas variações da mesma regra que era praticamente uma sintaxe nova de CSS.
Porém, a limitação de quais e quantas regras devem ser registradas foge do escopo do post, isso é uma convenção feita pelo time no começo do projeto, as ferramentas aqui simplesmente auxiliam na implementação destas convenções.
Outro ponto onde o tailwind torna o uso de recursos já existentes mais simples são os plugins de autocomplete (o que mais uma vez, não é exclusivo do tailwind, o mesmo pode ser alcançado com diversas bibliotecas diferentes).
Fonte: elaborada pelo autor
O autocomplete junto de um tema deixa explícito o uso da convenção estabelecida no projeto. Isso traz facilidade e velocidade ao desenvolvimento, além de tornar o projeto mais consistente visualmente.
Typescript
O typescript tem uma função de auto-documentação parecida, como os tipos são estáticos, todas as funções são mais simples de se usar, e podem ter os seus parâmetros restringidos aos valores válidos para um componente específico utilizando o enums.
Fonte: elaborada pelo autor
No exemplo acima temos um componente de imagem/logo, que recebe como parâmetro um enum responsável por inserir a classe de tamanho. Neste caso temos três opções: large, small e xs, se estivéssemos escrevendo um header, ou um item de menu onde esse componente de imagem vai entrar, poderíamos restringir o uso somente aos tipos small e xs, fazendo que fique evidente que nunca queremos o tipo large dentro desse contexto.
O poder de criar componentes intuitivos onde o caminho mais simples é fazer o projeto com decisões tomadas anteriormente é uma ferramenta poderosíssima, torna o onboarding mais simples, evita bugs e comportamentos inesperados, além de acelerar o desenvolvimento.
Sem essa auto documentação precisaríamos seguir um documento visual e ir chutando os tamanhos até ficar parecido, ou ter todo o retrabalho de conversar com o cliente e ver se o que nós vemos como ideal é o que realmente foi acordado.
Tendo isso padronizado em um só local e essa decisão sendo tomada uma só vez, evitamos o maior atraso no tempo de desenvolvimento de qualquer projeto de software: IO.
Design system
Todas as ideias expressas aqui partem dos princípios de um design system, mas este não é um post sobre isso. Apesar de todas essas ferramentas auxiliarem na implementação de um design system, este é um assunto muito mais complexo e que depende da coordenação de todos os responsáveis pelo projeto, não só o time de desenvolvimento.
No próximo post, vamos criar uma aplicação simples e ver na prática como as ferramentas acima podem auxiliar no desenvolvimento de um sistema consistente.
Leitura extra:
Sistemas de Design: a evolução do Atomic Design