Os desenvolvedores devem usar um conceito chamado shame.css para isolar qualquer CSS de 'hack' de correção rápida em projetos, de acordo com Harry Roberts, desenvolvedor sênior de IU da BSkyB.
Roberts explicou em um post de blog que isso poderia impedir que os desenvolvedores vissem hacks espalhados por todo o CSS e, portanto, pensar que tais coisas são aceitáveis por padrão.
Além disso, o artigo observou que tal abordagem, se devidamente documentada e acompanhada pelos meios de iteração, poderia permitir uma progressão mais rápida para um CSS mais limpo em projetos onde hacks foram usados (por qualquer motivo).
.net conversou com Roberts (HB) sobre hackear CSS e as vantagens potenciais que o shame.css poderia trazer se usado corretamente.
.net: Você acha que há uma tendência de algumas pessoas no setor de serem irrealistas sobre a necessidade de (espero) hacks de curto prazo para fazer um site funcionar?
RH: Grande momento. Se você trabalha em um site ou produto que ganha milhões de libras por ano, quaisquer bugs, quebras ou peculiaridades precisam ser consertados o mais rápido possível. O proprietário do produto não se importa se seu CSS é perfeito - eles se importam se o site está ativo e funcional e ultrapassando essa receita. Bom código é importante, e os hacks estão longe de ser o ideal, mas pensar que você sempre pode evitar hacks e soluções de curto prazo / rápidas é ingênuo.
.net: Então você diria que eles são apenas um mal necessário dentro dos negócios?
RH: Quando um cliente está respirando no seu pescoço - ou um recurso está quebrado em um site ao vivo - você precisa ter certeza de que está mantendo as partes interessadas certas felizes. Se você passar uma hora escrevendo a correção perfeita para algo que poderia ter corrigido superficialmente em dois minutos, eu diria que você está mantendo a pessoa errada feliz - ou seja, você mesmo!
Em meu próprio trabalho, descobri que a "necessidade" de hacks aumenta proporcionalmente ao tamanho do projeto, mas a boa coisa é que, mais tarde, você provavelmente terá mais tempo de projeto dedicado a consertar esses hacks.
.net: É aí que entra o shame.css. Com esse conceito, o que você considera especificamente um hack de CSS?
RH: Algo que poderia ter sido feito melhor com mais tempo. É difícil pensar em exemplos fora do contexto, mas acho que muitas vezes você saberá quando algo é um hack. Escreveu algo que teria vergonha de explicar a um colega? Provavelmente é um hack!
Portanto, shame.css é sobre fazer um arquivo de coisas que você poderia ter feito melhor, e que você pode fazer melhor quando tiver tempo para revisá-las. É uma lista de tarefas que você escreve, na verdade - um arquivo de hacks que você deixa de lado para pensar quando tiver mais tempo.
.net: Em seu artigo, você menciona a documentação de hacks, mas não há um argumento que os desenvolvedores geralmente deveriam documentar mais CSS do que apenas para hacks?
RH: Sim! Se há uma coisa que todos os desenvolvedores deveriam fazer mais, é escrever comentários. Você deve comentar qualquer coisa que não seja imediatamente óbvia apenas pelo código. Documente seu código para que, se você for atropelado por um ônibus no caminho para casa, seu colega possa assumir no dia seguinte.
.net: Em termos de integração do shame.css, o que você sugere?
RH: Se estiver usando um pré-processador, @importar a vergonha. [scss | menos | etc] arquivo bem no final, de preferência. (Isso sempre pode levar a problemas de especificidade e ordem de origem, portanto, sua milhagem pode variar.)
Se você não estiver usando um pré-processador, mas tiver um processo de construção decente, todo o CSS deve ser concatenado e reduzido antes da implantação, então, novamente, o shame.css pode ser adicionado ao final disso.
Se você não estiver usando um pré-processador e você não tem um processo de construção, então um, você provavelmente deve consertar isso, e dois, uma seção de hacks no final de sua folha de estilo é provavelmente sua melhor aposta. Shame.css não se destina à exibição pública, então nunca tenha uma folha de estilo separada chamada por um elemento de link em sua marcação. Você deve veicular apenas uma folha de estilo concatenada e minimizada.
.net: Se o conceito de shame.css realmente decolar, como você acha que ele poderia mudar o processo de design e os sites em geral?
RH: Shame.css é tão útil quanto os desenvolvedores que o implementam. É muito bom isolar e documentar hacks, mas se você nunca os conserta ou revisita, você está no mesmo barco de antes.
Para mim, shame.css sinaliza uma mudança mais ampla no desenvolvimento; não precisa se limitar a CSS. O conceito é meramente ‘perceber, documentar e enfatizar seus hacks’. Você pode aplicar esse pensamento a tudo.
O verdadeiro trabalho envolvido com o shame.css é conseguir que sua equipe imediata (desenvolvedores) a bordo e, em seguida, tornar o negócio / PMs / scrum masters / BAs / proprietários do produto (e assim por diante) cientes do fato de que um produto às vezes inclui menos -que o código ideal, mas que esse código existe para atender aos requisitos de negócios.
Diga a eles que você está isolando e documentando hacks e aloque algum tempo de desenvolvimento para organizar as coisas. É mais fácil criar um caso de negócios para organizar uma base de código se você puder quantificá-lo. Simplesmente dizer ao seu gerente de projeto: "Tenho algumas coisas para arrumar antes de passar para o Recurso X" nem sempre é suficiente! Leve uma lista de coisas para o seu PM e tente reservar meio dia de sprint para limpar.
A ideia por trás do shame.css é simplesmente tornar seus hacks mais transparentes, quantificáveis e isolados. Depende de você o que fazer com essas informações!
