CSS é uma linguagem de folha de estilo simples para definir um site ou apresentação de documento. No entanto, essa simplicidade deixa a porta aberta para muitos problemas potenciais e dívidas técnicas -código inchado, inferno de especificidade, blocos de código duplicados com muito pouca ou nenhuma diferença, seletores não utilizados remanescentes, hacks desnecessários e soluções alternativas, para cite alguns.
Esse tipo de dívida técnica, se não for paga a tempo, pode se acumular e levar a problemas graves no futuro. Mais comumente, pode levar a efeitos colaterais inesperados ao adicionar novos componentes de IU e dificultar a manutenção da base de código. Você provavelmente já trabalhou em um projeto com uma base de código CSS pobre antes e pensou em como você escreveu o código de maneira diferente, dada a oportunidade de refatorar ou reescrever tudo do zero.
Refatoração grandes partes do código CSS não são uma tarefa fácil em qualquer medida. Às vezes, pode parecer que é apenas o caso de”excluir o código de baixa qualidade, escrever CSS melhor e implantar o código aprimorado brilhante”. No entanto, há muitos outros fatores a serem considerados, como a dificuldade de refatorar uma base de código ao vivo, duração esperada e utilização da equipe, estabelecer metas de refatoração, rastrear a eficácia e o progresso do refatorador, etc. Há também a questão de convencer o gerenciamento ou as partes interessadas do projeto a investir tempo e recursos no processo de refatoração.
Nesta série de três partes , vamos passar pelo processo de refatoração CSS do início ao fim, começando com o conhecimento sobre como abordá-lo e alguns prós gerais e contras da refatoração, em seguida, passando para as próprias estratégias de refatoração e terminando com algumas práticas recomendadas gerais sobre o tamanho e desempenho do arquivo CSS.
Efeitos colaterais de CSS de baixa qualidade
Para todos sua flexibilidade e simplicidade, o próprio CSS tem alguns problemas fundamentais que permitem aos desenvolvedores escrever código de baixa qualidade no primeiro lugar. Esses problemas se originam de seus mecanismos de especificidade e herança, operando em escopo global, dependência de ordem de origem, etc.
Em um nível de equipe, a maioria dos problemas de base de código CSS geralmente se originam da habilidade variável níveis e conhecimento de CSS, preferências e estilos de código diferentes, falta de compreensão da estrutura do projeto e do código e componentes existentes, ausência de padrões e diretrizes no nível do projeto ou da equipe, e assim por diante.
Como resultado, CSS de baixa qualidade pode causar problemas que vão além dos bugs visuais simples e pode produzir vários efeitos colaterais graves que podem afetar o projeto como um todo. Alguns exemplos incluem:
Diminuindo a qualidade do código à medida que mais recursos são adicionados devido aos níveis variáveis de habilidade de CSS em uma equipe de desenvolvimento e à falta de regras internas, convenções e práticas recomendadas. Adicionar novos recursos ou estender os seletores existentes causa bugs e efeitos colaterais inesperados em outras partes do código (também conhecido como regressão). Vários seletores CSS diferentes com blocos de código duplicados ou pedaços de código CSS podem ser separados em um novo seletor e estendidos por variação. Pedaços de código remanescentes e não utilizados de recursos excluídos . A equipe de desenvolvimento perdeu o controle de qual código CSS é usado e qual pode ser removido com segurança. Inconsistência na estrutura do arquivo, nomenclatura da classe CSS, qualidade geral do CSS, etc. “Inferno da especificidade” onde novos recursos são adicionados substituindo em vez de existente a base de código CSS. Desfazendo CSS onde os seletores de especificidade mais alta “redefinem” o estilo do seletor de especificidade mais baixa. Os desenvolvedores estão escrevendo mais código para ter menos estilo. Isso resulta em redundância e muito desperdício de código.
Na pior das hipóteses, todos os problemas mencionados acima combinados podem resultar em um tamanho de arquivo CSS grande , mesmo com a minificação de CSS aplicada. Este CSS geralmente bloqueia a renderização , então o navegador venceu nem mesmo renderizará o conteúdo do site até que o download e a análise do arquivo CSS sejam concluídos, resultando em uma UX e desempenho ruins em redes mais lentas ou não confiáveis.
Esses problemas não afetam apenas o usuário final, mas também o equipe de desenvolvimento e partes interessadas no projeto, tornando a manutenção e o desenvolvimento de recursos difíceis, demorados e caros. Este é um dos argumentos mais úteis para apresentar ao argumentar para refatorar ou reescrever CSS.
A equipe da Netlify observou que a razão por trás de seu projeto de refatoração CSS em grande escala era a diminuição da qualidade do código e facilidade de manutenção conforme o projeto crescia em complexidade com mais e mais componentes de IU adicionados. Eles também notaram que a falta de padrões CSS internos e documentação levou à diminuição da qualidade do código à medida que mais e mais pessoas trabalhavam na base de código CSS.
“(…) o que começou com PostCSS organizado cresceu gradualmente para se tornar uma arquitetura CSS global complexa e emaranhada com muitas especificidades e substituições. Como você pode esperar, há um ponto em que o débito adicional de tecnologia que ele introduz torna difícil manter o envio rápido sem adicionar regressões. Além disso, conforme o número de desenvolvedores de front-end que contribuem para a base de código também cresce, esse tipo de arquitetura CSS se torna ainda mais difícil de trabalhar. ”
Refatorar ou reescrever?
A refatoração permite aos desenvolvedores para melhorar gradual e estrategicamente a base de código existente, sem alterar sua apresentação ou funcionalidade principal. Essas melhorias são geralmente de escopo pequeno e limitado, e não introduzem mudanças arquitetônicas inovadoras e abrangentes, nem adicionam novos comportamentos, recursos ou funcionalidades à base de código existente.
Por exemplo, os recursos da base de código atual duas variações de um componente de cartão-a primeira foi implementada no início do desenvolvimento do projeto por um desenvolvedor experiente e a segunda foi adicionada algum tempo depois que o projeto foi lançado por um desenvolvedor menos experiente em um prazo curto, portanto, apresenta código duplicado e seletores abrangentes com alta especificidade.
Uma terceira variação de cartão precisa ser adicionada, que compartilha alguns estilos das outras duas variações de cartão. Portanto, para evitar bugs, código duplicado e classes CSS complexas e marcação HTML no futuro, a equipe decide refatorar o CSS do componente do cartão antes de implementar uma nova variação.
A reescrita permite que os desenvolvedores façam mudanças substanciais na base de código e assume que a maioria, senão todo o código da base de código atual, será alterado ou substituído. Rewrite permite que os desenvolvedores criem a nova base de código do zero, resolvam os principais problemas da base de código atual que eram impossíveis ou caros de corrigir, melhorem a pilha de tecnologia e a arquitetura e estabeleçam novas regras internas e práticas recomendadas para a nova base de código.
Por exemplo, o cliente está em processo de rebranding e o site precisa ser atualizado com um novo design e conteúdo reformulado. Uma vez que esta é uma mudança em todo o site pronta para uso, os desenvolvedores decidem começar do zero, reescrever o projeto e aproveitar esta oportunidade para abordar os principais problemas da base de código CSS atual, mas não pode ser resolvida com o código refatorar, atualizar a pilha de tecnologia CSS, usar as ferramentas e recursos mais recentes, estabelecer novas regras internas e práticas recomendadas para estilização, etc.
Vamos resumir os prós e os contras de cada abordagem.
A refatoração é uma abordagem recomendada para melhorar incrementalmente a base de código CSS enquanto mantém a aparência atual e sentir (design). Os membros da equipe podem trabalhar para resolver esses problemas de base de código quando não houver tarefas de prioridade mais alta. Ao melhorar incrementalmente a experiência do usuário da base de código atual não será afetada diretamente na maioria dos casos, no entanto, uma base de código mais limpa e mais sustentável resultará em implementação de recursos mais fácil e menos bugs inesperados e efeitos colaterais. As partes interessadas do projeto provavelmente concordarão em investir tempo e recursos limitados na refatoração, mas esperam que essas tarefas sejam feitas rapidamente e que a equipe esteja disponível para o principal tarefas. A refatoração de CSS deve ser feita em intervalos regulares quando nenhum design abrangente ou alterações de conteúdo não estiverem planejadas para um futuro próximo. As equipes devem buscar proativamente os pontos fracos mencionados anteriormente na base de código CSS atual e trabalhar para solucioná-los sempre que não houver tarefas de prioridade mais alta disponíveis. O desenvolvedor de front-end líder ou o desenvolvedor com mais experiência com CSS deve levantar emite e cria tarefas de refatoração para aplicar os padrões de qualidade do código CSS na base de código. A reescrita da base de código CSS completa deve ser feita quando a base de código CSS tem questões centrais que não podem ser tratadas com a refatoração ou quando a refatoração é uma opção mais cara. Falando por experiência própria, quando comecei a trabalhar para clientes que mudaram de outra empresa e os problemas de CSS mencionados acima e era óbvio que seria um trabalho difícil de refatorar, eu começaria recomendando uma reescrita completa e ver o que o cliente pensa. Na maioria dos casos, esses clientes ficaram insatisfeitos com o estado da base de código e ficaram felizes em continuar com a reescrita. Outro motivo para a reescrita completa do CSS é quando uma mudança substancial está planejada para o site-reformulação da marca, redesenho ou qualquer outra mudança significativa que afete a maior parte do site. É seguro presumir que as partes interessadas do projeto estão cientes de que este é um investimento significativo e que levará algum tempo para que a reescrita seja concluída. Quando o desenvolvimento a equipe concordou com o fato de que o código CSS precisa ser refatorado para otimizar o fluxo de trabalho de desenvolvimento de recursos ou eliminar efeitos colaterais e bugs inesperados do CSS, a equipe precisa levar essa sugestão às partes interessadas do projeto ou a um gerente de projeto. É uma boa ideia fornecer alguns dados concretos junto com os pensamentos subjetivos sobre a base de código e a revisão geral do código. Isso também dará à equipe uma meta mensurável da qual eles podem estar cientes enquanto trabalham no refatorador-tamanho do arquivo de destino, especificidade do seletor, complexidade do código CSS, número de consultas de mídia… Ao fazer uma auditoria CSS ou preparando-me para um refatorador CSS, conto com várias ferramentas úteis para obter uma visão geral e estatísticas úteis sobre a base de código CSS. Minha ferramenta pessoal de acesso é CSS Stats , uma ferramenta gratuita que fornece uma visão geral útil da qualidade da base de código CSS com muitas métricas úteis que podem ajudar os desenvolvedores a detectar alguns problemas difíceis de detectar. Em 2016, trivago fez uma refatoração em grande escala para sua base de código CSS e usou as métricas de CSS Stats para definir alguns objetivos concretos e mensuráveis, como reduzir a especificidade e reduzir o número de variações de cores. Em apenas três semanas, eles conseguiram melhorar a integridade geral da base de código CSS, reduzir o tamanho do arquivo CSS, melhorar o desempenho de renderização em dispositivos móveis etc. “Uma ferramenta como CSS Stats pode ajudá-lo facilmente a descobrir problemas de consistência em sua base de código. Indicando o que pode acontecer quando todos têm opiniões diferentes sobre como um tom de cinza deve ser, você acabará com 50 tons de cinza. Além disso, o Gráfico de Especificidade oferece uma boa indicação geral da integridade de sua base CSS. ” Quanto às ferramentas CLI, Wallace é uma ferramenta útil que fornece estatísticas CSS básicas, mas úteis e uma visão geral que pode ser usado para identificar problemas relacionados ao tamanho do arquivo, número de regras e seletores, tipos de seletor e complexidade, etc. Wallace também oferece um ferramenta de análise gratuita no site do Projeto Wallace, que usa uma versão aparentemente mais avançada do Wallace no backend para fornecer algumas visualizações de dados úteis e mais algumas métricas que não estão disponíveis na CLI Wallace. Projeto Wallace também oferece uma solução paga completa para análise de base de código CSS . Ele apresenta recursos e métricas ainda mais úteis que podem ajudar os desenvolvedores a detectar alguns problemas difíceis de detectar e controlar as alterações nas estatísticas de CSS por confirmação. Embora o plano pago inclua mais recursos, o plano gratuito e a ferramenta básica de análise de CSS são mais do que suficientes para auditar a qualidade do codebase CSS e obter uma visão geral para fazer planos de refatoração. Vimos como a simplicidade e flexibilidade da base de código CSS podem causar muitos problemas com a qualidade do código, desempenho e bugs visuais. Não existe uma ferramenta automática mágica que garantirá que escrevamos CSS da melhor maneira possível e evite todas as armadilhas arquitetônicas possíveis ao longo do caminho. As melhores ferramentas que garantirão a escrita de alta qualidade O código CSS é disciplina, atenção aos detalhes e conhecimento e conjunto de habilidades gerais de CSS . O desenvolvedor precisa estar constantemente ciente do quadro geral e entender qual papel seu CSS desempenha nesse quadro geral. Por exemplo, ao especificar demais os seletores, um único desenvolvedor pode limitar severamente a usabilidade, fazendo com que outros desenvolvedores tenham que duplicar o código a fim de usá-lo para outros componentes semelhantes com marcação diferente. Esses problemas geralmente ocorrem quando os desenvolvedores não entendem e não aproveitam os mecanismos subjacentes por trás do CSS (cascata, herança, desempenho do navegador e especificidade do seletor). Essas decisões iniciais podem levar a grandes repercussões no futuro , portanto, a integridade e a capacidade de manutenção da base de código CSS dependem do conhecimento, das habilidades e da compreensão dos fundamentos do CSS do desenvolvedor. Ferramentas automatizadas não estão cientes do panorama geral ou de como o seletor é usado, então eles não podem tomar essas decisões arquitetônicas cruciais, além de aplicar algumas regras básicas, previsíveis e rígidas. Falando por experiência pessoal, descobri o seguinte me ajudou a melhorar significativamente a forma como trabalhei com CSS: Aprendendo os padrões de arquitetura. Também é importante estabelecer regras e padrões CSS internos dentro de uma equipe ou mesmo para toda a empresa. Padrões, estilo de código e princípios claramente definidos em toda a empresa podem render muitos benefícios, como: Estilo e qualidade de código unificado e consistente Mais fácil de entender, base de código robusta Integração de projeto simplificada Revisões de código padronizadas que podem ser feitas por qualquer membro da equipe , não apenas o desenvolvedor líder de front-end ou os desenvolvedores mais experientes Kirby Yardley trabalhou na refatoração do Sundance Institute sistema de design e CSS e apontou a importância de estabelecer regras internas e melhores práticas. “Sem regras e estratégia adequadas, CSS é uma linguagem que se presta ao uso indevido. Freqüentemente, os desenvolvedores escreverão estilos específicos para um componente sem pensar criticamente sobre como aquele código poderia ser reutilizado em outros elementos (…) Depois de muita pesquisa e deliberação sobre como queríamos abordar a arquitetura de nosso CSS, decidimos usar uma metodologia chamada ITCSS. “ Voltando ao exemplo anterior de a equipe do trivago , estabelecendo regras e diretrizes internas, provou ser um passo importante para seu processo de refatoração. “Introduzimos um biblioteca de padrões , começou a utilizar design atômico em nosso fluxo de trabalho, criou uma nova codificação diretrizes e adaptou várias metodologias como BEM e ITCSS para apoiar para manter e desenvolver nosso CSS/UI em grande escala. ” Nem todas as regras e padrões precisam ser verificados e aplicados manualmente. Ferramentas de linting CSS como Stylelint fornecem algumas regras úteis que o ajudará a verificar se há erros e a aplicar padrões internos e práticas recomendadas comuns de CSS, como desautorizar blocos de código CSS vazios e comentários, desautorizar seletores duplicados, limitar unidades, definir a especificidade máxima do seletor e profundidade de aninhamento, estabelecer o padrão de nome do seletor, etc.. Antes de decidir propor um refatorador de base de código granular ou uma reescrita CSS completa, precisamos entender os problemas com a base de código atual para que possamos evite-os no futuro e tenha dados mensuráveis para o processo. A base de código CSS pode conter muitos seletores de alta especificidade complexos que causam efeitos colaterais inesperados e bugs ao adicionar novos recursos, talvez a base de código esteja sofrendo de muitos fragmentos de código repetidos que podem ser movidos para uma classe de utilitário separada, ou talvez a mistura de várias consultas de mídia estão causando alguns conflitos inesperados. Ferramentas úteis como CSS Stats e Wallace podem fornecer uma visão geral de alto nível da base de código CSS e dar uma visão detalhada sobre o estado e a integridade da base de código. Essas ferramentas também fornecem estatísticas mensuráveis que podem ser usadas para definir as metas do processo de refatoração e acompanhar o progresso da refatoração. Depois de determinar as metas e o escopo da refatoração, é importante definir diretrizes internas e práticas recomendadas para a base de código CSS -convenção de nomenclatura, princípios de arquitetura, arquivo e estrutura de pasta, etc. Isso garante a consistência do código, estabelece uma base central dentro do projeto que pode ser documentada e que pode ser usado para integração e revisão de código CSS. Usar ferramentas de linting como o Stylelint pode ajudar a aplicar algumas práticas recomendadas comuns de CSS para automatizar parcialmente o processo de revisão de código. No próximo artigo desta série de três partes, vamos mergulhar em um CSS à prova de balas estratégia de refatoração que garante uma transição perfeita entre a base de código atual e a base de código refatorada. “ Gerenciando projetos CSS com ITCSS ,” Harry Roberts “ Refatoração de CSS em grande escala na Trivago , ”Christoph Reinartz“ Sistema de design e refator de CSS de Sundance.org , ”Kirby Yardley“ From Semantic CSS To Tailwind: Refatorando o Netlify UI Codebase ,” Charlie Gerard & Leslie Cohn-Wein “ Ferramentas de auditoria CSS ,” Iris Lješnjanin Quando refatorar CSS?
Quando reescrever o CSS?
Auditando a saúde do codebase CSS
Escrita de alta qualidade CSS
Diretrizes CSS fornecem uma excelente base de conhecimento e práticas recomendadas para escrever CSS de alta qualidade com base em padrões gerais de programação e princípios arquitetônicos. Pratique e melhore.
Trabalhe em projetos pessoais ou enfrente um desafio do Frontend Mentor para melhorar suas habilidades. Comece com projetos simples (um único componente ou uma seção) e concentre-se em escrever o melhor CSS possível, experimente várias abordagens, aplique vários padrões de arquitetura, melhore gradualmente o código e aprenda como escrever CSS de alta qualidade com eficiência. Aprendendo com os erros.
Acredite em mim, você escreverá alguns CSS de qualidade realmente ruim quando estiver começando. Você precisará de algumas tentativas para acertar. Pare um momento e pense sobre o que deu errado, analise os pontos fracos, pense sobre o que você poderia ter feito de maneira diferente e como, e tente evitar os mesmos erros no futuro. Conclusão
Referências
