Fazer sites leva tempo. Há muitas partes em que você deve pensar se deseja criar um site bom e sólido e, às vezes, pode parecer que não há uma maneira de executar o trabalho mais rapidamente. Se você trabalha sozinho ou com uma equipe de designers e desenvolvedores de back-end, há muitas maneiras de ser mais produtivo.
Um erro que muitas pessoas e muitas empresas cometem é que elas planejam padronizar seus produtos. Eles são construídos apenas com base em um único tema do WordPress, ou todos os sites têm os mesmos recursos. Se você deseja trabalhar com clientes maiores, eles quase nunca desejam trabalho padrão. Em vez disso, eles desejam algo adaptado às suas necessidades e exigências. Esse é um trabalho mais interessante, mais desafiador e paga mais. Mas isso também significa que você não pode padronizar seu produto.
Você não pode (e não quer) padronizar seu produto , mas o que você pode fazer é padronizar seu processo . Como desenvolvedor líder de front-end, com mais de 15 anos de experiência, gastei muito tempo pensando em como configurar esse processo da melhor maneira possível. Se você for intencional, poderá obter impressionantes ganhos de produtividade em todas as áreas do processo. Aqui estão 8 maneiras de fazer isso, desde o início do projeto até o fim:
- Comece de uma base sólida
- Concordar com atalhos de design
- Use ferramentas de transferência
- Use uma estrutura CSS
- Reutilize seus componentes
- Use Emmet
- Use Polypane
- Configurar verificação de qualidade automatizada
Comece de uma base sólida
Se você começar do zero todas as vezes, pode ter certeza de que nunca será mais rápido que na última vez. Ao criar ou usar uma base sólida para o seu site, você pode economizar tempo nas coisas que está fazendo o tempo todo.
Os desenvolvedores de back-end já sabem disso. Muitos criarão seu próprio projeto inicial com base no idioma e na estrutura de sua escolha, em vez de um CMS. Onde um CMS geralmente possui um número definido de funcionalidades que você só pode usar da maneira que o CMS pretendia, uma estrutura é mais como uma grande caixa de blocos de construção que você pode combinar das maneiras que funcionam melhor para o seu projeto atual. Esse conceito também pode ser estendido ao seu front-end.
Faça os últimos projetos e veja qual HTML é semelhante. Todo site terá aproximadamente os mesmos elementos: sempre há um <head>com título, favicon, informações opengraph e links para seu CSS e JS. 99% do tempo, um site terá um cabeçalho com um logotipo e alguma forma de navegação, e um rodapé com uma regra de direitos autorais e alguns links adicionais, e a maioria das páginas terá uma área de conteúdo para o seu CMS. Tornar essa parte do HTML “inicial” ou “base” economizará muito tempo.
Além disso, embora a maioria de nós adore conferir novas estruturas JavaScript, para sua base inicial, provavelmente você pode se safar de alguns pequenos trechos de JavaScript. O JavaScript entre plataformas é muito mais fácil do que há alguns anos atrás, e a maioria das coisas pode ser resolvida com pequenos scripts “vanilla”.
Concordar com atalhos de design
As ferramentas de design oferecem aos designers acesso a todas as larguras, cores e tamanhos de fonte. Mas, na realidade, seus sites usarão apenas alguns de cada. Você pode economizar tempo durante o design e a implementação, não cortando cantos, mas estabelecendo algumas regras básicas.
Isso pode ser super expansivo, criando um sistema de design completo, por exemplo, no Modulz que será lançado em breve , onde todos os elementos e variantes de design disponíveis são pré-projetados e gerados a partir do código real. Você gasta mais tempo com antecedência, mas o resultado é algo que pode ser projetado e construído rapidamente, geralmente em conjunto.
Mas os atalhos de design também podem ser super simples: peça à sua equipe que aceite um conjunto de atalhos de design que você aplica a todas as partes do design.
Por exemplo, concorde com um conjunto de margens que você reutilize para cada elemento de design (como 8px / 16px / 32px / 64px) e um designer nunca precisará se preocupar em garantir que todas as margens sejam perfeitamente 64px em vez de 63px (ou pior , 63.47845px. Obrigado, Sketch!). Por outro lado, você como desenvolvedor web nunca terá que perder tempo perguntando aos designers se eles realmente pretendem usar 60px dessa vez, ou se devem ser apenas 64 como todo o resto. Você pode fazer o mesmo para tamanhos de fonte e cores uniformes.
Este simples low-tech pedaço de, a comunicação pode poupar horas de (re) o tempo de desenvolvimento. Se você já concordou com as margens em potencial em qualquer lugar, e qualquer elemento de design que use um ligeiramente diferente, você pode simplesmente usar o mais próximo, então você também não precisará fazer nenhuma sessão de pixel-bleeping com seu designer. Ou pelo menos muito menos.
Obviamente, isso não significa que um design nunca possa usar uma margem diferente, mas o designer indicaria claramente quaisquer exceções no seu arquivo de design.
Use ferramentas de transferência
Trabalhar diretamente de um arquivo de design é uma receita para problemas. Não apenas você pode mover acidentalmente partes da interface do usuário sem perceber, mas a interface é voltada para a criação de um design, não para dissecá-lo para reimplementar em outro local. Para isso, existem ferramentas de transferência.
Eles adotam um design e trazem uma interface exclusiva focada no que os desenvolvedores front-end fazem. Os nossos favoritos incluem Avocode , Zeplin e Marvel , mas ferramentas de design como XD, Figma e Sketch agora também incluem seus próprios modos de transferência.
Familiarize-se com essas ferramentas em conjunto com seu designer para que elas possam aprender a melhor maneira de preparar arquivos de design para essas ferramentas e você, como desenvolvedor, aprender como usar as ferramentas com mais eficiência.
Use uma estrutura CSS
Primeiro, deixe-me dizer que não sou muito fã de estruturas CSS. A maioria é grande, lenta, carrega muito legado e é excessivamente limitada, sem fornecer bons padrões, ou se eles têm bons padrões, geralmente são padrões de outras pessoas que provavelmente não funcionarão para você e sua situação (Oh, oi, Material Projeto).
Mas.
Existem novas estruturas interessantes que podem funcionar para você:
O Bulma é uma estrutura CSS de “próxima geração” criada para navegadores modernos, portanto, possui uma base de código mais simples e menor, é fácil de personalizar e possui alguns padrões de boa aparência. Vi esse trabalho em produção muito bem.
Vento de cauda – Esteja avisado, você pode odiá-lo quando o vê pela primeira vez (eu sei que sim). O truque aqui é que ele muda seu estilo de escrever CSS para escrever nomes de classes. Cada estilo (cor, margem etc.) recebe suas próprias classes. Mesmo que você esteja limitado a algumas classes fixas, seu site sempre será consistente. Você pode usar os padrões ou personalizá-los.
Se você supera o fato de precisar estilizar usando apenas classes, desenvolvê-lo se torna muito, muito rápido. O console de gerenciamento Polypane é escrito com ele, por exemplo. Se você quiser ver como seus projetos podem variar e como podem ser as implementações, recomendo Tailwind Toolbox
Reutilize seus componentes
Embora existam componentes bons, rápidos, acessíveis e responsivos por aí, é difícil encontrar componentes que se encaixem perfeitamente na maneira de trabalhar de você e de sua equipe com tanta frequência que você acabará criando o seu. No entanto, entre os projetos, geralmente há elementos e padrões de interface do usuário que você reutiliza.
Talvez você tenha o menu responsivo perfeito ou o formulário de contato perfeito com manipulação de erros acessível e animação sofisticada.
Documente-os de maneira que você possa implementá-los facilmente em cada novo projeto. Com o tempo, eles evoluirão e você adicionará novos recursos a eles. Se fizer isso, não se esqueça de atualizar também seu componente de referência. Caso contrário, você ainda estará pesquisando no projeto antigo para encontrar a versão específica de um componente.
Use Emmet
Embora qualquer editor de texto ou IDE que você use tenha suporte para snippets (use para os componentes reutilizáveis que acabamos de mencionar), o uso do Emmet pode economizar muito tempo. Está disponível para basicamente todos os editores de texto e IDE.
O conceito para o Emmet é simples: e se você criar HTML escrevendo seletores CSS? Na documentação do Emmet:
Esta abreviação:
#page>div.logo+ul#navigation>li*5>a{Item $}… pode ser transformado em
<div id="page">
<div class="logo"></div>
<ul id="navigation">
<li><a href="">Item 1</a></li>
<li><a href="">Item 2</a></li>
<li><a href="">Item 3</a></li>
<li><a href="">Item 4</a></li>
<li><a href="">Item 5</a></li>
</ul>
</div>… com um único atalho “expandir”. Você pode ver claramente qual desses dois é mais rápido de escrever e, como desenvolvedor front-end, já conhece CSS, então há muito pouco a aprender para um aumento tão grande na velocidade.
Assim como o Polypane economiza seu tempo com todo o redimensionamento e recarregamento que você não precisa, o Emmet economiza seu tempo com toda a digitação que você não precisa.
Use Polypane
Não achava que eu ia deixar isso de fora, certo? Em média, o Polypane economiza para as equipes cerca de 60% do tempo de implementação. Isso parece loucura, eu sei, mas são números observados. Muito simplesmente, se você contar o tempo todo redimensionando seu navegador durante o desenvolvimento, é muito. E isso não é algo que você faz apenas uma vez por página. No Polypane, esse redimensionamento não precisa acontecer porque você já vê todos os seus pontos de interrupção lado a lado. Se você o usar no controle de qualidade, poderá dizimar o tempo que leva, pois terá muito menos dispositivos para gerenciar. Mais sobre isso em um artigo posterior.
O Polypane não economiza tempo porque você não precisa redimensionar. Ele tem muitas outras ferramentas que tornarão você um desenvolvedor mais rápido, como recarga ao vivo integrada que tornará obsoleta a atualização da página também ou sobreposições que fazem de tudo, desde destacar problemas de contraste até executar simuladores de deficiência visual ao vivo.
Se você ainda não usa o Polypane, eu desafio você a manter um registro de quanto redimensiona seu navegador durante um único dia. Então vá usar o Polypane.
Mais importante, porém, quando você cria um site e vê todos os tamanhos de tela de uma só vez, os problemas são capturados mais rapidamente (geralmente antes que eles ocorram), para que o tempo gasto por página diminua. Você simplesmente tem menos correções a serem feitas após sua implementação inicial. Com o tempo, você levará essas correções automaticamente em consideração no seu primeiro passe, economizando ainda mais tempo.
Esse benefício leva muito longe: também significa muito menos problemas após o lançamento de um projeto. Ter que fazer correções de bugs em projetos concluídos meses atrás é o desperdício de tempo mais caro que uma equipe de desenvolvimento da web pode ter. Imagine não precisar baixar um banco de dados e arquivos estáticos e configurar um projeto antigo em sua máquina apenas para corrigir um único problema.
Configurar verificação de qualidade automatizada
Você pode verificar manualmente seu site em andamento de vez em quando, mas testadores de qualidade como Lighthouse e Webhint geralmente demoram um pouco para serem executados. Idealmente, você não deseja esperar que eles terminem. Portanto, em vez de executá-los manualmente, faça-os parte do seu progresso. Automatize a verificação de cada RP, por exemplo, usando a integração de CI do farol-ci e do webhint . Dessa forma, você mantém uma boa visão geral de como o seu projeto está indo em termos de qualidade, sem ter que perder tempo aguardando a conclusão dos testes.