CSS escalável - Parte 1

Da filosofia à metodologia


Nos últimos 5 anos como frontender e webdesigner do JusBrasil, percebi que minha bola de cristal estava com defeito e já não me mostrava os problemas que eu iria enfrentar no futuro. Então tive que quebrar muito a cara para entender o que faz a gente ter medo de um código antigo. E no meio de tantas propostas sobre como manter seu CSS escalável, resolvi mostrar primeiro o mais importante, a filosofia por trás do um código escalável (seja em que linguagem for). Mas para não dizer que não falei de flores, na parte 2 e parte 3 falarei sobre a metodologia que utilizo.


Um problema histórico

Sabe como as páginas HTML eram exibidas nos seus primeiros anos de vida? Um amontoado de texto em Times New Roman preto e links azuis. Pensando em melhorar este cenário, Håkon Lie idealizou em 1996 o que se tornaria a linguagem de estilo oficial da web: Cascading Style Sheet (CSS). O que eu não disse é que o HTML teve sua primeira especificação em 1991, cinco anos antes do CSS.

Foram cinco anos de textos pretos e links azuis, e desde sua criação, o CSS teve apenas duas grandes atualizações. Em 2008 a W3C lançou a especificação do CSS2 e 3 anos depois, em 2011, o CSS3. Com estas atualizações, surgiram muitas novidades legais: adicionou-se novas propriedades e seletores. Muito bom! Mas espere um pouco, não tivemos nenhuma atualização estrutural. O CSS continua uma linguagem rudimentar, de simples entendimento, mas de difícil utilização e, principalmente, manutenção!

Não podemos culpar Håkon Lie por não imaginar em 1996 que em 2014 os sites teriam mais de 200kb de folha de estilo. Ele resolveu um problema na época, mas hoje precisamos resolver outro: tornar as folhas de estilo manuteníveis num cenário de sites complexos e desenvolvidos colaborativamente.

A manutenção de um código só se torna realmente um problema à medida que ele vai escalando! Mas nem sempre sabemos quando precisará escalar, então é sempre bom começar um projeto preparando-o para o futuro.

Todo CSS começa bem, pois começa pequeno, mas com o tempo vai se deteriorando, como um alimento que perde a validade e fica podre. O grande desafio do CSS é começar e continuar bem, mantendo seu código sempre organizado, legível e componentizado!

Como? Calma que eu já te explico! Mas antes de começar a dizer como, vou dizer o que e o porquê! A filosofia por trás de um CSS escalável é mais importante do que a própria metodologia.

Não Existe Bala de Prata!

Não adianta, eu também não vou trazer uma solução mágica. Nem vou explicar cada uma das dezenas de siglas que surgiram para solucionar este problema: SMACSS, BEM, OOCSS, DRYCSS, Suit CSS ou CSS Guidelines. Nem vou explicar as propostas do GitHub, CodePen, Trello, Lonely Planet, Medium, Buffer.… Mas aconselho que leia todas elas, afinal, são propostas diferentes, e cada uma com seus pontos positivos e negativos.

Não adianta querer adotar um modelo. Vou falar como eu faço, mas esta pode não ser a melhor solução pra você. Então entenda os fundamentos para tornar seu CSS escalável e aplique-os no seu contexto, pegue o melhor de cada proposta e depois tome suas próprias decisões!

Não Quebre Janelas!

Em 1982 James Q. Wilson e George L. Kelling introduziram a teoria das janelas quebradas (broken windows theory), para explicar crimes que aconteciam em Nova York. Eles dão o seguinte exemplo:

“Considere-se um edifício com algumas janelas quebradas. Se as janelas não são consertadas, a tendência é que vândalos quebrem mais janelas. Eventualmente, poderão entrar no edifício, e se este estiver desocupado, o ocupam ou o incendeiam.”

O mesmo acontece com o código. Um código que quebre uma regra, é uma janela quebrada. Podendo ser uma repetição desnecessária ou até mesmo o nome de uma variável escrita de forma errada ou uma falta de identação. Qualquer janela quebrada vai dar a impressão de um código abandonado, despertando o instinto vândalo do programador (programador é um ser capaz de coisas inimagináveis, cuidado).

Então, não quebre janelas! Ao primeiro sinal de janela quebrada, conserte-a na hora ou corra o risco do prédio desabar!

Crie Padrões

Se você olhar para um código e falar “isso aqui deve ter sido o estagiário” ou “isso aqui deve ter sido Jamile de TPM”, tem algo errado! Todos da equipe estão envolvidos em UM projeto, e da mesma forma, o código deve ter UMA personalidade.

Para evitar que cada um escreva o código como quiser, use style guides! Aqui, o mais importante é que o time concorde, entenda e adote o padrão definido. É mais fácil respeitar uma regra que você concorde do que uma que você é contra (não vamos exemplificar, né? ☺).

Mas se você não acha que um código padronizado é um código escalável, deixa eu tentar te convencer:

Um código padronizado é um código impessoal.
Um código impessoal é um código familiar para a equipe.
Um código familiar é um código entendido e escrito mais rápido.
Um código entendido e escrito mais rápido é um código legível.
Um código legível é um código escalável
Sendo assim, um código padronizado é um código escalável :P

Já existem muitos padrões bem fundamentados. Escolha o de sua preferência ou junte tudo e faça o seu como achar melhor. Eu gosto do padrão de @mdo. Mas também não deixe de ler o CSS Guidelines e o usado pelo GitHub.

Tenha Disciplina

O ser humano é intrinsecamente caótico. Assim como ele libera o instinto vândalo ao ver uma janela quebrada, ele tem dificuldade em cumprir regras. E um projeto que precise escalar, provavelmente terá mais de um ser humano envolvido (se tiver só um, não será um ser humano e sim um Super-man! #BaDumTss), logo, a chance de promoverem o caos é muito maior!

A saúde do projeto não depende só de você. Todos devem fazer um trabalho de curadoria do código desenvolvido pelo time (Oi? Ouvi falar code review?).

Regras são coisas chatas criadas para te impedir de fazer algo que você faria se não existissem as regras! Cumprir regras que você mesmo criou exige muita disciplina.

Mas veja pelo lado bom, regras também são coisas legais criadas para manter a ordem! Um código caótico não é escalável. Um código organizado sim! Pense nisso e ande na linha.


Neste artigo, você viu a filosofia por trás de um código escalável: não existe bala de prata, não quebre janelas, crie padrões e tenha disciplina! Essa filosofia se aplica a qualquer linguagem, não só ao CSS. Mas você deve estar ansioso para ver código. Não se preocupe, nos próximos artigos falarei sobre a metodologia por trás de um CSS escalável, mostrando como manter seu código organizado, legível, reaproveitável, etc.

Só não esqueça, filosofia >>> metodologia!


A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.