Como fazer code review de CSS
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.
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 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. Uma excelente ferramenta para encontrar erros e/ou inconsistências. Também disponível como tarefas Gulp e Grunt que podem ser configuradas para verificar conjuntos de regras personalizados.
- 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. Um repositório central que referencia quais propriedades CSS são compatíveis com qual navegador e versão.
- Ghostlab. Um aplicativo para teste de navegador sincronizado em vários dispositivos.
- Serviços de teste entre navegadores. Cross Browser Testing ou Browserstack.
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. Ferramenta para visualizar a especificidade em uma folha de estilo inteira.
- Specificity Calculator. 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:
Critério 4: Pré-processadores
Se o projeto estiver usando algum pré-processador CSS, 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. Recurso no CSS-Tricks.
- Sass Guidelines. 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
@importnativo? É 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. 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. Muito semelhante ao CSS Stats, mas empacotado como uma conveniente extensão do navegador Chrome.
- 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. Outro task-runner, mas que cria arquivos CSS individuais com base na marcação HTML de uma determinada página.
- 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:
- A Coisa Funciona
- Estilo e Consistência
- Cross-Browser
- Especificidade
- Pré-processadores
- 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!
