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.

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 @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. 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:

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!