Accélérez votre flux de travail lors de la création de thèmes WordPress

Publié: 2020-12-17

La vitesse est primordiale pour à peu près n'importe quel projet. Souvent, les délais sont assez serrés et un bon flux de travail dans une équipe est le seul moyen de le respecter à temps et d'éviter que tout le monde ne s'épuise tout au long du processus.

À quoi ressemblerait un tel flux de travail? Et comment mettre en œuvre certaines bonnes pratiques dans votre travail quotidien pour accélérer vos livraisons? Eh bien, il y a plusieurs façons de l'examiner. Le premier est:

Améliorations du flux de travail technique

Dans cette partie, nous examinerons les outils utilisés par les développeurs pour accélérer leur travail. Le moyen le plus simple de déterminer ce qui fonctionnerait le mieux est de pointer vers les processus les plus lents - ce qui prend le plus de temps à faire. Ensuite serait - ce qui demande le plus d'énergie mentale à faire. Parfois, un processus peut être très rapide, mais chaque fois que vous le faites, cela ressemble à une corvée, que vous préféreriez repousser pour plus tard.

Suggestion 1 - Préparez un thème de départ

Une énorme amélioration de notre flux de travail chez DevriX a été de faire toutes les choses standard que nous faisons avant de commencer chaque projet, de les héberger dans un référentiel, puis de le cloner à chaque fois qu'une nouvelle version arrive.

Préparez un thème de démarrage

Comment ça aide?

  1. Il n'est pas nécessaire de faire une configuration de Gulp à chaque fois. Tous les packages sont prêts à l'emploi, ils fonctionnent, la configuration a été testée sur plus d'une machine.
  2. Il est livré avec une courte documentation. S'il y a de nouveaux membres de l'équipe, ils n'ont pas à poser de questions sur les tâches de configuration de base, car la plupart de cela est déjà expliqué.
  3. Inutile de décider à chaque fois de la structure des fichiers pour le front-end. La plupart du temps, notre équipe frontale travaille sur un nouveau thème à partir du premier jour, donc s'ils doivent créer une structure de dossier / fichier pour les fichiers Sass à chaque fois, nous perdrions des heures par projet.
  4. Nous gardons tout cohérent - C'est un autre énorme coup de pouce. Il y a généralement plus d'un projet actif en même temps, donc savoir où trouver ce que vous cherchez pour la première fois lorsque vous ouvrez un projet est un gain de temps énorme. Avec la même structure sur tous les thèmes, styles, fichiers JS, les fichiers PHP sont tous au même endroit.

Chaque fois que nous trouvons une meilleure approche d'un problème qui améliore peut-être la configuration de la construction, introduit des linters, des crochets, ajoute des actions ici et là ou des fonctions d'aide qui sont souvent utilisées, nous mettons à jour notre thème de démarrage. Si les modifications apportées à la configuration de la construction sont majeures, nous mettons également à jour la base de code des projets existants pour la suivre.

Suggestion 2 - Conserver le même style de codage et les mêmes approches

Avec cela, tous les développeurs comprendraient ce que les gens avant eux ont fait. Il y a plus à cela cependant - lorsque les mêmes approches de mise en œuvre des dispositions sont appliquées, la base de code sera plus cohérente. Ceci est particulièrement nécessaire pour les développeurs front-end car la pollution des styles est un problème majeur de régression.

Vous pouvez voir par exemple le guide de style de codage HTML / CSS de Google.

Guide de style de codage HTML CSS de Google

La source

Les moyens courants de nommer «Entrée» ou «Commentaire», ou les moyens de gérer les «listes» comme .list-<name> et autres sont quelques-unes des approches standard que nous adoptons lors de la création de mises en page.

Suggestion 3 - Améliorez votre configuration de travail locale

Un moyen rapide de naviguer entre les projets est un gain de temps considérable. Juste $cd'ing entre les répertoires peut prendre une demi-heure par jour facilement. C'est tout du temps perdu. Au lieu de cela, vous pouvez configurer TMUX sur votre machine, configurer une fenêtre distincte pour chaque projet et un panneau séparé pour chaque tâche / objectif comme «Running Gulp» - panneau 1; «Exécution des commandes dans le thème» - panneau 2; «Exécution de commandes dans les plugins» - panneau 3.

De plus, assurez-vous que vous pouvez ouvrir votre éditeur de code directement depuis le terminal. C'est un moyen plus rapide d'accéder au codage que d'ouvrir à partir d'une icône, puis de naviguer vers «ouvrir le projet» et autres. VS Code a cela très facile à mettre en place.

Utilisez mieux vos outils

  • Le code VS, le texte Sublime et de nombreux autres outils ont une fenêtre contextuelle «Commande» où vous pouvez taper presque tout ce que l'éditeur peut faire. Enregistrer tous les documents ouverts? Juste quelques boutons. Les fermer? Tous les mêmes.
  • Naviguez dans la palette de commandes - la recherche de fichiers dans la barre latérale prend également trop de temps. Allez-y et écrivez le nom de fichier dont vous avez besoin. Ajoutez des extensions pour accélérer les opérations courantes telles que le changement de nom, le déplacement, la duplication et la suppression de fichiers.
  • Préparez les linters. Perdre du temps dans le formatage des fichiers est inutile quand il existe des outils qui peuvent le faire pour vous. Chaque fois que vous indentez du code, ajoutez un espace entre crochets et ainsi de suite pourrait être mieux consacré à la résolution de problèmes.
  • Utilisez des raccourcis et des extraits - pour les développeurs frontaux, Emmet est une bouée de sauvetage. Les one-liners simples comme: nav>.site-nav>ul.list-items>li.list-item*5>a{title} s'étendent à plus de 15 lignes de code HTMl, toutes formatées et prêtes à être stylisées. La saisie de cette ligne prend quelques secondes.
Exemple de VSCode

Exemple de palette de commandes VSCode. Vous pouvez en lire beaucoup plus sur leur page de présentation.

Prise de décision pour améliorer le flux de travail

Celui-ci peut être un peu plus délicat et nécessiter plus d'expérience et de compréhension des besoins commerciaux du client. C'est aussi l'une des approches les plus lourdes de responsabilités, mais c'est parfois ce qui peut empêcher un projet de manquer une échéance.

Commencez par le plus important et le plus rapide à mettre en œuvre. S'il y a une légère chance qu'une page ne se lance pas le jour 1, il n'est pas nécessaire de commencer par elle. Si, d'après vos estimations, il est possible que quelque chose ne soit pas prêt, assurez-vous d'en discuter avec votre client. Plus vous indiquez clairement ce que vous avez fait, ce qui pourrait être retardé et où les problèmes pourraient survenir, plus il est probable que vous puissiez surmonter un problème potentiel.

Déléguez le travail dès le début, mais gardez le nombre total de personnes impliquées à un faible niveau. C'est quelque chose que tout le monde remarque à un certain stade. Peut-être que le plus tôt est à l'école, lorsque 10 enfants se mettent au travail sur un projet, mais seulement deux ou trois font l'essentiel du travail.

Ceci est particulièrement visible sur les projets qui commencent par un travail plus frontal. Rarement dès le premier jour, vous pouvez avoir plus d'un développeur travaillant car l'une des premières choses à définir est l'architecture du projet. Les décisions fondamentales de l'équipe de conception devraient être la construction. Quels sont les composants, comment s'étendent-ils, la séparation des fichiers, la structure et les règles de la requête multimédia, les conventions de dénomination. Tout ça.

accomplir des tâches

Et quand il y a plus d'un développeur à un stade aussi fondamental, les deux peuvent commencer à implémenter un élément fondamental du code dont ils ont besoin pour styliser le reste du site. Quand ils pousseront ce code, des conflits émergeront et l'un des développeurs devra peut-être refaire la majeure partie du travail.

Un bon moment pour ajouter plus de développeurs frontaux serait lorsque plus du travail fondamental est effectué et que le travail peut être délégué à des composants séparés tels que "Cartes de contenu", ou "Landing page X" ou "404 page" et autres. À ce moment-là, les polices sont appliquées, les paramètres de typographie généraux sont définis, la plupart des fichiers sont créés et au moins 1 à 2 pages sont créées.

Et puis, c'est idéal si le nombre total de personnes concentrées sur un seul projet est maintenu au minimum. En termes de gestion du temps et de concentration sur la tâche, une astuce que les développeurs qui travaillent en équipe pourraient vouloir considérer est de changer la charge de travail sur un projet donné.

Disons que nous avons le développeur front-end John qui travaille sur un nouveau site depuis deux semaines à plein temps. À ce moment-là, il l'examine depuis plus de 80 heures par jour. Il a très probablement arrêté de repérer des problèmes sur le site! Ce serait le bon moment pour son amie Kate d'intervenir et de reprendre l'essentiel de son travail. Kate peut commencer à résoudre des problèmes mineurs, vérifier qu'il suit le design, améliorer les performances ici et là, terminer les quelques pages et composants que John a reportés simplement parce qu'il n'a pas l'énergie mentale pour le faire.

Il est fort possible que la plupart des développeurs aient vécu cela et il est si bon d'avoir un coéquipier qui peut intervenir et prendre les choses en main pendant encore une semaine ou deux pendant que vous vous videz un peu l'esprit avec un nouveau projet ou des travaux de maintenance sur des sites Web plus anciens. .

En résumé:

Il existe plusieurs moyens techniques évidents pour améliorer la vitesse de développement d'un site. C'est un mélange entre le travail d'équipe - comment vous définissez des directives communes dans votre équipe et comment vous configurez votre environnement de travail / automatisez votre travail tout en utilisant tous les outils à votre disposition. Comment vous gardez l'esprit frais et vif pendant de plus longues périodes afin de maintenir le taux de productivité élevé que vous aviez le premier jour.

Pour gérer tout cela, une équipe solide a besoin de bons développeurs seniors pour définir l'architecture, de membres de développement responsables pour suivre les directives et produire un travail de qualité et de bons chefs de projet pour rechercher l'état mental de chacun.