# Como fazer code review de CSS > Guia prático para code review de CSS profissional. 6 critérios essenciais: estilo, cross-browser, especificidade, pré-processadores e performance. Revise! URL: https://dpw.dev/css/como-fazer-code-review-css/ Publicado em: 2022-04-20 Categoria: css Tags: planejamento Autor: Tárcio Zemel Muitos projetos, das mais variadas linguagens de programação, passam por uma revisão de código (ou _code review_) em várias etapas. O interessante é que também é possível fazer **code review de CSS**. Apesar de não haver regras fixas para code reviews de CSS, é possível estabelecer alguns critérios úteis para o que poderia ser um ponto de partida para tirar o máximo proveito de uma revisão de código CSS. ## Code review de CSS? CSS não é uma linguagem de programação, mas não deixa de ser código. Portanto, merece sim passar por um processo de code review, trazendo os respectivos ônus e bônus intrínsecos. Uma revisão de código é mais um passo no processo de desenvolvimento que, consequentemente, leva tempo, custo e esforço. Ao mesmo tempo, uma revisão de código CSS permite dar "um passo atrás", fazer uma análise mais precisa, revisar e dar ao trabalho uma avaliação mais honesta -- ou entregá-lo a outra pessoa para uma nova perspectiva.
![Mulher pensativa mexendo em notebook que está em cima da mesa. Estaria ela fazendo code review de CSS?](/images/blog/como-fazer-code-review-css/portfolio-deve-estar-em-constante-evolucao.webp)
Definitivamente, não é tão comum fazer code review de CSS (principalmente no mercado de TI nacional).
[Isso é o que nos separa das máquinas](https://daverupert.com/2015/02/john-henry/) e, no final, tem o potencial de poupar a dor de cabeça de ter que lidar com correções de bugs e performance que poderiam ter sido detectadas previamente. E há muito mais benefícios do que apenas encontrar bugs preventivamente. Dividir revisões de código em áreas específicas, focadas nesses benefícios, pode ajudar a contextualizar a conversa e priorizar esses resultados positivos. Sem mais delongas, veja **6 critérios possíveis para fazer code review de código CSS**. ## Critério 0: A Coisa Funciona O Critério 0 é verificar se a coisa realmente se parecem/funcionam como deveriam. O motivo pelo que foi criado e primeiro trabalho de CSS é estilizar as coisas para que pareça que foram visualmente planejadas, certo? O resultado final bate com o planejamento visual, style guide ou o que quer que tenha sido usado no projeto? Isso acontece com conteúdo variável (títulos e conteúdo de vários comprimentos, imagens de vários tamanhos etc.)? Se isso não estiver aceitável, nem adianta passar para os próximos critérios. ## Critério 1: Estilo e Consistência Aqui, o objetivo é **garantir que o CSS esteja bem escrito, organizado e documentado**. Qualquer dev que já herdou projetos de outros desenvolvedores conhece os benefícios. O código que usa uma convenção de nomenclatura consistente e inclui documentação completa é mais fácil de se aprofundar e fornece instruções sobre como manter e aprimorar o código no futuro. Perguntas: - Existe um guia de estilo CSS (_style guide_) disponível para este projeto? Se sim, o código o está seguindo? - O código está documentado? Existem elementos, propriedades ou hacks confusos que impediriam outro desenvolvedor de saber por que algo foi escrito desse jeito? - Existem inconsistências flagrantes em como os elementos são nomeados ou como suas propriedades são organizadas? Recursos: - [CSS Lint](http://csslint.net/). Uma excelente ferramenta para encontrar erros e/ou inconsistências. Também disponível como tarefas [Gulp](https://www.npmjs.com/package/gulp-csslint) e [Grunt](https://github.com/gruntjs/grunt-contrib-csslint) que podem ser configuradas para verificar conjuntos de regras personalizados. - [CSS Style Guides](https://css-tricks.com/css-style-guides/). Um resumo de exemplos de guias de estilo que podem ser usados como inspiração para criar o seu próprio. ## Critério 2: Cross-Browser Uma vez que o CSS esteja organizado e consistente, um dos próximos passos possíveis é dar atenção a como as coisas estão em diferentes navegadores e dispositivos. Código bem escrito é uma coisa, mas não vale muito se não funcionar onde e quando deveria. Perguntas: - Quais navegadores e dispositivos este projeto precisa dar suporte? Todos os membros da equipe têm acesso a eles para fazer testes? - Este site/app tem analytics? Em caso afirmativo, ele fornece informações sobre quais navegadores são mais importantes para testar? - Existem hacks direcionados a um navegador ou dispositivo específico? Se sim, existe outra maneira de contorná-los? Estão bem documentados? Recursos: - [Can I Use](https://caniuse.com/). Um repositório central que referencia quais propriedades CSS são compatíveis com qual navegador e versão. - [Ghostlab](http://vanamco.com/ghostlab/). Um aplicativo para teste de navegador sincronizado em vários dispositivos. - Serviços de teste entre navegadores. [Cross Browser Testing](http://crossbrowsertesting.com/) ou [Browserstack](https://www.browserstack.com/). ## Critério 3: Especificidade Agora é a hora de avaliar quão específicos são os elementos no código e identificar se há oportunidades para refatorar. Isso cria uma "cascata responsável" de estilos onde os elementos são tão modulares ou tão específicos quanto preciso. Perguntas: - Os IDs são usados em qualquer lugar? Em caso afirmativo, um nome de classe funcionará? O guia de estilo tem algo a dizer sobre isso? - `!important` é usado no código? Em caso afirmativo, por que foi usado? O código pode ser refatorado para evitá-lo? - Quão modulares são os elementos? Eles se sustentam em um teste "Kitchen Sink" onde todos são usados juntos no mesmo documento HTML? Recursos: - [CSS Specificity Graph Generator](https://jonassebastianohlsson.com/specificity-graph/). Ferramenta para visualizar a especificidade em uma folha de estilo inteira. - [Specificity Calculator](http://specificity.keegan.st/). Uma boa maneira de visualizar o quão específico é um elemento (permite comparações entre vários seletores). Sobre este assunto, veja também nossa live **Ferramentas de Especificidade CSS**: [Vídeo no YouTube](https://www.youtube.com/watch?v=LCcfD11RYZA) ## Critério 4: Pré-processadores Se o projeto estiver usando algum [pré-processador CSS](/tag/sass/), certamente há algumas coisas extras para pensar. Perguntas: - As variáveis existentes estão sendo usadas onde deveriam estar? Foram introduzidas novas variáveis? - Outras abstrações (por exemplo, extensões, mixins, loops, maps etc.) foram usadas de maneira eficaz e de acordo com a forma como o restante do código está fazendo as coisas? - CSS novo está sendo colocado em partials corretas? Foram usadas novas partials? Elas fazem sentido dentro da Arquitetura CSS escolhida para o projeto? - Os estilos estão seguindo algum style guide específico do pré-processador em questão? Recursos: - [Sass Style Guide](https://css-tricks.com/sass-style-guide/). Recurso no CSS-Tricks. - [Sass Guidelines](http://sass-guidelin.es/). Por Kitty Giraudel. ## Critério 5: Performance **CSS de boa performance** geralmente é sobre refinamento e como ele é empacotado e servido, por isso, parece apropriado para encerrar o processo de revisão, mesmo que o desempenho deva estar sempre em mente enquanto trabalhamos -- pelo menos, deveria ser assim. Perguntas: - Quanto pesa o arquivo CSS final? Há planejamento para usar gzip (sim, por favor!) e qual é a diferença de peso quando ele é usado e quando não é? - Quantas folhas de estilo diferentes estão sendo carregandas? É via `@import` nativo? É possível reduzir esse número? - Existem arquivos que podem ser servidos condicionalmente? De maneira assíncrona? - CSS em ambiente de produção está sendo cacheado? Recursos: - [CSS Stats](http://cssstats.com/). Informe o URL de um site e obtenha uma série de estatísticas, incluindo um relatório de todas as fontes e cores que foram usadas. - [CSS Dig](http://cssdig.com/). Muito semelhante ao CSS Stats, mas empacotado como uma conveniente extensão do navegador Chrome. - [unCSS](https://github.com/giakki/uncss). Task-runner que remove CSS não utilizado comparando-o com a marcação HTML e JavaScript. Disponível para Grunt, Gulp e Broccoli. - [Critical CSS](https://github.com/addyosmani/critical). Outro task-runner, mas que cria arquivos CSS individuais com base na marcação HTML de uma determinada página. - [loadCSS](https://github.com/filamentgroup/loadCSS). Padrão para carregar CSS de forma assíncrona. ## Conclusão sobre code review de CSS Definitivamente, nem todas as perguntas e ferramentas mencionadas aqui são necessárias ou mesmo relevantes para todos os projetos. Na verdade, há muito mais perguntas e ferramentas a serem consideradas -- com o tempo, atualizaremos com mais perguntas, fique ligado. De qualquer maneira, estes são **6 critérios possíveis a serem considerados ao fazer code review de CSS**: 0. A Coisa Funciona 1. Estilo e Consistência 2. Cross-Browser 3. Especificidade 4. Pré-processadores 5. Performance Lembre-se de que o objetivo de se fazer code review no código CSS não é torná-lo perfeito. É possível fazer concessões em CSS por muitas razões (intencionais ou não). No final das contas, apenas tentar fazer um bom trabalho é mais do que suficiente e isso faz parte desse esforço. E você, **quais perguntas faz no seu code review de CSS?** Conta pra gente nos comentários! --- Fonte: [dpw - desenvolvimento para web](https://dpw.dev/) (pt-BR). Guia para agentes: https://dpw.dev/llms.txt Índice completo: https://dpw.dev/sitemap-index.xml Feed: https://dpw.dev/rss.xml