Acelere seu fluxo de trabalho ao criar temas WordPress

A velocidade é fundamental para praticamente qualquer projeto. Freqüentemente, os prazos são muito curtos e um bom fluxo de trabalho em equipe é a única maneira de cumpri-lo no prazo e evitar que todos se esgotem durante o processo.

Como seria esse fluxo de trabalho? E como você pode implementar algumas das melhores práticas para seu trabalho diário para agilizar suas entregas? Bem, existem algumas maneiras de analisarmos isso. O primeiro é:

Melhorias técnicas de fluxo de trabalho

Nesta parte, veremos as ferramentas que os desenvolvedores usam para acelerar seu trabalho. A maneira mais fácil de descobrir o que funcionaria melhor é apontar para os processos mais lentos - o que leva mais tempo para fazer. O próximo seria - o que requer mais energia mental para fazer. Às vezes, um processo pode ser muito rápido, mas toda vez que você realmente o faz, parece uma tarefa árdua, que você prefere deixar para depois.

Sugestão 1 - Prepare um tema inicial

Uma grande melhoria em nosso fluxo de trabalho no DevriX foi fazer todas as coisas padrão que fazemos antes de iniciar cada projeto, hospedá-los em um repositório e, em seguida, apenas cloná-lo toda vez que uma nova construção vier.

Como isso ajuda?

1. Não há necessidade de fazer uma configuração Gulp todas as vezes. Todos os pacotes estão prontos para uso, eles são executados, a configuração foi testada em mais de uma máquina.
2. Ele vem com uma pequena documentação. Se houver novos membros da equipe, eles não terão que fazer perguntas sobre as tarefas básicas de configuração, pois a maior parte já foi explicada.
3. Não há necessidade de decidir sobre a estrutura de arquivos para o front-end todas as vezes. Principalmente, nossa equipe de front-end trabalha em um novo tema a partir do dia 1, então, se eles tivessem que criar uma estrutura de pastas / arquivos para os arquivos Sass todas as vezes, perderíamos horas por projeto.
4. Mantemos tudo consistente - este é outro grande impulso. Normalmente, há mais de um projeto ativo ao mesmo tempo, portanto, saber onde encontrar o que você está procurando pela primeira vez ao abrir um projeto economiza muito tempo. Com a mesma estrutura em todos os temas, estilos, arquivos JS e arquivos PHP estão todos no mesmo lugar.

Sempre que encontramos uma abordagem melhor para um problema que talvez melhore a configuração da compilação, introduza linters, ganchos, adicione algumas ações aqui e ali ou funções auxiliares que são frequentemente usadas, atualizamos nosso tema inicial. Se as alterações na configuração da compilação forem importantes, também atualizamos a base de código dos projetos existentes para segui-la.

Sugestão 2 - Manter o mesmo estilo de codificação e abordagens

Com isso, todos os desenvolvedores entenderiam o que as pessoas antes deles faziam. No entanto, há mais do que isso - quando as mesmas abordagens para implementar layouts são aplicadas, a base de código será mais consistente. Isso é especialmente necessário para desenvolvedores front-end, pois poluir os estilos é um grande problema de regressão.

Você pode ver, por exemplo, o guia de estilo de codificação HTML / CSS do Google.

Fonte

Maneiras comuns de nomear “Entrada” ou “Comentário” ou maneiras de gerenciar “listas” como .list-<name> e similares são algumas das abordagens padrão que adotamos ao construir layouts.

Sugestão 3 - Melhore sua configuração de trabalho local

Uma maneira rápida de navegar entre projetos economiza muito tempo por si só. Apenas $cd'ing entre diretórios pode levar meia hora por dia facilmente. Isso tudo é tempo perdido. Em vez disso, você pode configurar TMUX em sua máquina, configurar uma janela separada para cada projeto e um painel separado para cada tarefa / propósito como “Running Gulp” - painel 1; “Executando comandos no tema” - painel 2; “Executando comandos em plug-ins” - painel 3.

Além disso, certifique-se de abrir seu editor de código diretamente do terminal. É uma maneira mais rápida de começar a codificar do que abrir a partir de um ícone e, em seguida, navegar até “abrir projeto” e similares. O VS Code é realmente fácil de configurar.

Utilize melhor suas ferramentas

• Código VS, texto Sublime e muitas outras ferramentas têm um pop-up “Comando” onde você pode digitar quase tudo que o editor pode fazer. Salvar todos os documentos abertos? Apenas alguns botões. Fechar eles? Tudo o mesmo.
• Navegue pela paleta de comandos - a procura de arquivos na barra lateral também leva muito tempo. Apenas vá em frente e escreva o nome do arquivo de que você precisa. Adicione algumas extensões para acelerar operações comuns como renomear, mover, duplicar e excluir arquivos.
• Linters de configuração. É desnecessário perder tempo com a formatação de arquivos quando existem ferramentas que podem fazer isso por você. Cada vez que você recua o código, adiciona espaço entre colchetes e assim por diante pode ser mais bem gasto na resolução de problemas.
• Utilize atalhos e snippets - para desenvolvedores front-end, Emmet é um salva-vidas. Uma linha simples como: nav>.site-nav>ul.list-items>li.list-item*5>a{title} expandem para mais de 15 linhas de código HTMl, todas formatadas e prontas para serem estilizadas. Digitar essa linha leva segundos.

Exemplo de paleta de comando VSCode. Você pode ler muito mais na página de visão geral.

Tomada de decisão para melhorar o fluxo de trabalho

Este pode ser um pouco mais complicado e pode exigir um pouco mais de experiência e compreensão das necessidades de negócios do cliente. É também uma das abordagens com maior responsabilidade, mas às vezes é o que pode evitar que um projeto perca um prazo.

Comece pelo mais importante e o mais rápido de implementar. Se houver uma pequena chance de uma página não ser lançada no dia 1, não há necessidade de começar com ela. Se, pelas suas estimativas, for possível que algo não esteja pronto, converse sobre isso com seu cliente. Quanto mais claramente você declarar o que fez, o que pode ser atrasado e onde os problemas podem ocorrer, mais provável é que você possa superar um problema potencial.

Delegue o trabalho logo no início, mas mantenha baixo o número total de pessoas envolvidas. Isso é algo que todos percebem em um determinado estágio. Talvez o primeiro seja na escola, quando 10 crianças começam a trabalhar em um projeto, mas apenas duas ou três fazem a maior parte do trabalho.

Isso é especialmente visível em projetos que começam com mais trabalho de front-end. Raramente, desde o primeiro dia, você pode ter mais de um desenvolvedor trabalhando, porque uma das primeiras coisas que precisam ser estabelecidas é a arquitetura do projeto. As decisões fundamentais da equipe de design devem ser a construção. Quais são os componentes, como eles se estendem, a separação de arquivos, a estrutura e regras de consulta de mídia, as convenções de nomenclatura. Tudo isso.

E quando há mais de um desenvolvedor em um estágio tão fundamental, ambos podem começar a implementar uma parte fundamental do código de que precisam para estilizar o resto do site. Quando eles empurram esse código, conflitos surgem e um dos desenvolvedores pode precisar refazer a maior parte do trabalho.

Um bom momento para adicionar mais desenvolvedores de front-end seria quando mais do trabalho fundamental estiver concluído e o trabalho puder ser delegado a componentes separados como “Cartões de conteúdo” ou “Página inicial X” ou “página 404” e outros semelhantes. Nesse momento, as fontes são aplicadas, as configurações gerais de tipografia são definidas, a maioria dos arquivos é criada e há pelo menos 1-2 páginas criadas.

E então, é ideal se o número total de pessoas focadas em um único projeto for mantido no mínimo. Em termos de gerenciamento de tempo e foco na tarefa, uma dica que os desenvolvedores que trabalham em equipe podem considerar é alternar a carga de trabalho em um determinado projeto.

Digamos que temos nosso desenvolvedor front-end John, que está trabalhando em um novo site há duas semanas em tempo integral. Naquela época, ele o olhava por mais de 80 horas por dia. Ele provavelmente parou de detectar problemas no site! Agora seria um bom momento para sua amiga Kate intervir e assumir a maior parte de seu trabalho. Kate pode começar a consertar pequenos problemas, verificando se segue o design, melhorando o desempenho aqui e ali, terminando as poucas páginas e componentes que John tem adiado simplesmente porque não tem energia mental para fazer isso.

É bem possível que a maioria dos desenvolvedores já tenha experimentado isso e é tão bom ter um colega de equipe que pode intervir e assumir as coisas por mais uma ou duas semanas, enquanto você limpa sua mente um pouco com um novo projeto novo ou algum trabalho de manutenção em sites mais antigos .

Em suma:

Existem várias maneiras técnicas óbvias de melhorar a velocidade de desenvolvimento de um site. É uma mistura de trabalho em equipe - como você define diretrizes comuns em sua equipe e como você configura seu ambiente de trabalho / automatiza seu trabalho, utilizando todas as ferramentas à sua disposição. Como você mantém sua mente fresca e afiada por longos períodos de tempo para manter a alta taxa de produtividade que você tinha no primeiro dia.

Para gerenciar tudo isso, uma equipe forte precisa de bons desenvolvedores sênior para estabelecer a arquitetura, membros dev responsáveis ​​para seguir as diretrizes e produzir um trabalho de qualidade e bons gerentes de projeto para verificar o estado mental de todos.