Développeurs WordPress : commencez ici !

Publié: 2017-10-14

Bienvenue dans notre guide de démarrage pour les développeurs WordPress ! Que vous travailliez en freelance ou au sein d'une agence média. Dans cet article, nous couvrirons une variété de sujets liés au développement de WordPress ainsi que certaines des ressources et des outils disponibles.
Le texte est organisé autour des différentes étapes qui s'écoulent entre la génération d'idées et l'expédition. Nous parlerons de brainstorming, de prototypage, de développement et enfin de déploiement. Tout cela, dans le cadre du développement de produits. Nous pensons qu'entre les premières ébauches d'une idée et son exécution finale, il existe de nombreuses zones subtiles. Certains ne sont au mieux pas discutés et d'autres sont au pire complètement inexplorés, dans la littérature WordPress actuelle.

Si vous êtes un client Pressidium, vous pouvez immédiatement commencer à utiliser les outils que nous avons construits autour de notre plateforme, afin que vous puissiez profiter des avantages d'un haut niveau d'intégration. Nous parlerons également de ce que sont ces outils. N'oubliez pas qu'il s'agit d'un document en direct et qu'il doit être traité comme tel.

Notre objectif est d'abord et avant tout que ce document soit utile pour votre pratique en tant que développeur WordPress, et deuxièmement de vous montrer quelques choses intéressantes que nous avons conçues juste pour vous.

De l'idée au déploiement

Que vous travailliez sur un nouveau produit ou que vous travailliez chez un client, le processus de passage de l'idée au déploiement se compose de 4 étapes. Bien que ces étapes soient discrètes, elles se chevauchent considérablement et ne sont pas linéaires. Nous en parlerons plus loin dans le texte :

Brainstorming et élicitation des besoins.
Prototypage.
Développement.
Déploiement.

Le processus de brainstorming associatif libre est utilisé lorsque vous souhaitez commencer à construire un produit ou un projet et que vous avez besoin d'idées. La collecte des exigences, cependant, se produit lorsque vous êtes chargé de construire un projet pour un client ou de conclure une idée après une séance de brainstorming. Vous pouvez toujours mettre en place des sessions de brainstorming par la suite afin de résoudre des problèmes particuliers, mais ces sessions seront plus contraintes.

Les principes fondamentaux du brainstorming sont au nombre de deux. Optez pour la quantité et reportez votre jugement à plus tard. Nous avons écrit dans le passé sur la façon dont vous pouvez animer une telle session, sur la façon de développer l'état d'esprit approprié et sur certains outils géniaux pour vous aider.

Élicitation des exigences

Il existe plusieurs méthodologies utilisées pour déterminer les exigences, et traditionnellement, cela a toujours été le travail d'un analyste métier. Bien qu'il incombe au client de fournir des informations sur les exigences du projet, une compréhension commune doit être établie pour toutes les parties prenantes. L'élicitation des exigences est un processus différent de la collecte des exigences. Il s'agit plutôt de faire émerger les informations nécessaires par une participation active. Et il s'agit moins de rassembler passivement dans un document ce que le client vous dit et de le transmettre à l'équipe de développement.

Selon la portée et la nature du projet, les cas d'utilisation sont un excellent moyen de capturer les fonctionnalités. Les cas d'utilisation sont une technique utilisée dans les diagrammes UML pour décrire les interactions entre les parties prenantes d'un système et le système lui-même. Puisqu'il s'agit d'une collection de scénarios écrits dans un anglais simple mais structuré, non seulement ils sont moins compliqués, mais ils constituent un moyen rapide et efficace de commencer à discuter et à esquisser les fonctionnalités du système.

Vous devrez probablement mettre en place des entretiens structurés avec toutes les parties prenantes si vous souhaitez saisir les exigences pour des produits complexes. Pour cela, les User Stories sont une solution idéale. Ils font partie de l'état d'esprit Agile et constituent une manière informelle de commencer à parler des exigences, afin de construire une compréhension partagée. De courtes descriptions des fonctionnalités sont écrites sur des cartes papier, généralement des post-it, et sont mélangées dans un tableau blanc pour créer des narrations des parcours des utilisateurs. Les histoires d'utilisateurs sont générées sur place, en participant, en discutant et en manipulant des cartes sur le tableau blanc. Les détails sont lentement étoffés et finalement ajoutés en tant que fonctionnalités dans le backlog du produit. Jeff Patton a écrit un excellent livre sur le User Story Mapping que nous vous recommandons vivement si vous souhaitez en savoir plus sur le sujet et commencer à l'utiliser dans vos projets.

Les user stories ne sont pas une chose statique qui, une fois créée, est oubliée à jamais. Au lieu de cela, il s'agit d'une carte dynamique, sur laquelle l'équipe de développement et de produit peut revenir encore et encore, au fur et à mesure que l'étape de prototypage s'ensuit et que le produit commence à prendre forme.

L'importance d'un prototype est de répondre aux questions. Bien qu'il existe plusieurs méthodologies de prototypage, nous pensons que celle évolutive est la plus adaptée à nos objectifs et celle qui peut être adaptée aux pipelines de développement de logiciels Agile modernes. Dans la méthodologie du prototype évolutif, le processus est cyclique, où le prototype devient progressivement plus raffiné à chaque cycle.

Chaque itération de prototype passe de la phase de conception à la phase de développement et d'évaluation. Cela fait ressortir les problèmes de conception précoces et fournit quelque chose de tangible que les gens peuvent pointer et parler de ce qui peut être amélioré. Les informations recueillies lors de la phase d'évaluation sont utilisées dans la prochaine itération du prototype et le cycle se répète une fois de plus. Ainsi, le prototype évolue lentement vers le système final jusqu'à ce qu'il atteigne sa maturité en tant que produit fini.

Le prototypage se produit généralement à des rythmes de développement rapides et l'utilisation de systèmes réutilisables tels que Bedrock, Sage et Bootstrap peut réduire considérablement les temps de développement. Des systèmes comme ceux mentionnés ci-dessus fournissent un squelette d'application complet et la chaîne d'outils nécessaire pour que vous n'ayez pas à recommencer à zéro à chaque fois. Les prototypes évolutifs ne sont pas les mêmes que les prototypes jetables. Ces derniers sont des prototypes qui ne sont construits qu'une seule fois en tant que preuve de concept, puis jetés. Si vous passez beaucoup de temps à construire un prototype de commerce électronique, pourquoi ne pas abstraire les fonctionnalités communes et les réutiliser à l'avenir au lieu de tout jeter et de repartir de zéro ?

C'est là que le clonage de Pressidium est utile. Il vous permet de cloner rapidement un site Web en un seul clic et de commencer à le développer. De cette façon, vous pouvez préparer plusieurs modèles de sites Web à l'aide de passe-partout, les précharger avec les plugins, les thèmes et la configuration nécessaires, et les cloner chaque fois que vous en avez besoin dans un projet. Vous pouvez également les cloner sur un compte Pressidium différent, par exemple celui de votre client, de la même manière. Ne vous inquiétez pas si vos prototypes se trouvent sur un autre fournisseur d'hébergement WordPress géré. Utilisez simplement notre outil d'assistant de migration et importez-les sur votre compte Pressidium !

Que vous développiez des projets WordPress par vous-même ou que vous collaboriez avec d'autres développeurs et designers WordPress, les deux points les plus importants qui contribuent à la durabilité de votre métier à long terme sont les suivants :

Adopter de bonnes habitudes logicielles.
Et savoir ce que tout est, où il est et pourquoi il est là.

Les meilleures pratiques varient de suivre systématiquement un guide de style logiciel à la pratique de l'écriture de code propre au lieu d'intelligent, et jusqu'aux choix de conception de logiciel et d'interface utilisateur de haut niveau. Le deuxième point est simplement la documentation, et les nombreuses formes qu'elle peut prendre à l'intérieur d'un projet.

Suivre un guide de style logiciel est simple. Étudiez les ressources officielles de WordPress.org sur le sujet, puis décidez quelles directives vous conviennent afin de les inclure dans votre style de codage. Changer ses habitudes est un processus lent et vous devriez commencer par faire de petits changements au début. En fin de compte, avoir un ensemble de directives auxquelles votre code doit se conformer signifie introduire des révisions de code à un moment donné.

Les revues de code sont un moyen systématique de lire et d'examiner le code qui vise à éliminer les erreurs, à élucider les parties de code qui sont abstruses et à s'assurer que le code respecte les normes et les conventions. Il est également préférable que ce soit fait par quelqu'un d'autre dans votre équipe et non par vous.

Préférer le code propre au code intelligent est une « perle de sagesse » du développement logiciel qui ne peut malheureusement être appréciée qu'après être tombé dans les pièges du code intelligent. Le point à retenir est le suivant : bien que, dans certains cas, un code intelligent puisse vous rapporter des points de "hacker" et une tape dans le dos, et même un gain de performances dans certains cas, vous perdez finalement à long terme. Un code "hackish" et difficile à lire deviendra incompréhensible à l'avenir. Et cela peut vous coûter cher lorsque vous devez résoudre un bogue particulièrement insaisissable. Trouver l'équilibre entre l'écriture de code optimisé et propre est quelque chose que vous devrez découvrir par vous-même, mais il est toujours préférable de se tromper du côté propre des choses.

De plus, comme les performances des sites WordPress dépendent fortement de l'utilisation correcte du cache du navigateur, il est important de savoir comment votre fournisseur d'hébergement WordPress géré utilise la mise en cache. Votre code fonctionnera alors en synergie avec votre plateforme d'hébergement, afin d'avoir les meilleures performances possibles. Cependant, gardez à l'esprit que mesurer correctement la vitesse de votre site Web n'est pas aussi simple qu'on pourrait le penser, et qu'il contient plusieurs pièges !

Ainsi, en parlant de meilleures pratiques de haut niveau, la décision qui a conduit WordPress à découpler ses fonctionnalités de base et à fournir une API REST pourrait certainement être considérée comme un exemple de telles pratiques. Cette décision a marqué le passage à une nouvelle ère, vers des systèmes de gestion de contenu programmatiques et le développement d'applications WordPress "headless".

Nous avons rédigé une introduction succincte et un didacticiel sur l'API REST de WordPress et un moyen simple de commencer à le bricoler à l'aide de plugins de navigateur tels que Postman.

Cette décision de conception de logiciel était d'une simplicité trompeuse mais puissante. Un développeur WordPress peut désormais utiliser WordPress pour implémenter des applications et des fonctionnalités qui dépassent de loin celles des sites Web ou des blogs. Un exemple particulièrement pertinent est notre prototype Kanban.

Nous avons utilisé des entités WordPress telles que des catégories et des publications pour modéliser un tableau Kanban avec des tâches, des colonnes et un flux de valeur. Nous avons esquissé une API Kanban Columns and Cards, qui reliait tout ensemble.

Documentation

On pourrait soutenir que les meilleures pratiques logicielles sont propices à la rédaction d'une meilleure documentation, des simples commentaires de code aux livrables du projet et aboutissant à la copie du produit.

Peu importe comment vous le regardez, la documentation est un atout.

En matière de documentation technique, le langage utilisé par écrit est résolument différent de celui que vous utilisez lorsque vous communiquez quotidiennement ou de celui que vous utilisez au travail. Cette forme d'écriture s'appelle l'écriture technique et n'est pas utilisée uniquement en informatique ou en génie logiciel. En fait, il est utilisé dans toutes les professions qui ont besoin de communiquer des concepts techniques à un public spécialisé, comme le droit, la médecine, l'aéronautique, etc. C'est un sujet important, et certains collèges proposent même des certifications en rédaction technique. Sa raison d'être est de communiquer des informations techniques dans un langage clair et concis. La voix active est préférée à la voix passive, cette dernière étant utilisée dans les cas où un texte descriptif est nécessaire pour expliquer les concepts.

Un rédacteur technique doit garder à l'esprit que le lecteur est quelqu'un qui est souvent frustré lorsqu'il recherche une information particulière. En conséquence, votre écriture ne doit pas vous gêner. Son objectif est de rendre ce processus facile, direct et même agréable !

Bien que vous n'ayez pas besoin d'avoir un diplôme ou d'être un rédacteur technique professionnel, savoir comment communiquer des concepts de manière concise et simple est très important pour votre carrière de développeur WordPress. Ainsi, chaque fois que vous avez besoin d'écrire de la documentation pour un plugin, un thème ou une API que vous avez construit (et dont vous êtes fier !), vous devez avoir les bases. Pour cette raison, nous avons rédigé un guide rapide pour documenter vos plugins et thèmes WordPress, qui couvre également les 5 principes de base de la rédaction technique.

Mais la documentation ne s'arrête pas là. Dans les cas où votre thème ou plugin fait partie d'un projet plus vaste, ou lorsqu'ils sont eux-mêmes suffisamment complexes, il faut commencer à penser en termes de documentation produit. Outre le fait que la documentation est un atout, la documentation produit est à son tour un atout marketing. Ceci est bien résumé dans la citation suivante de Mike PuterBaugh, vice-président du marketing chez MindTouch, dans un article de Mashable sur l'importance de la documentation produit :

Ce n'est pas une entreprise sexy, mais cela vous fera gagner le respect de vos pairs, une gestion d'entreprise plus efficace et une équipe plus collaborative. Parce qu'il ne s'agit pas de ce trimestre ou de cette année, mais plutôt d'affecter l'avantage concurrentiel et la croissance à long terme.

En ce qui concerne le produit, outre les formes les plus courantes de documentation écrite, il en existe plusieurs autres, telles que l'aide en ligne, les guides de style, le microcontenu, etc. La documentation du produit est généralement rédigée en collaboration par de nombreuses personnes différentes, ce qui ajoute une couche supplémentaire de complexité. Nous avons rédigé un guide complet qui vous aide également à commencer à penser et à planifier de cette façon.

Enfin, alors que nous passons à la dernière étape du processus, qui est le déploiement, nous plaçons la dernière pièce du puzzle de la documentation : les diagrammes de déploiement. Ceux-ci vous aident à avoir une idée claire et sphérique de ce que tout est et où il devrait être.

Bien que la plupart des gens s'enfuiraient en hurlant d'horreur en entendant parler d'UML (et c'est tout à fait compréhensible, la spécification complète d'UML est abyssale), pour sa défense, UML contient un sous-ensemble d'outils de notation qui peuvent ajouter de la valeur à un projet. Les diagrammes de déploiement sont une notation étonnamment simple composée uniquement de nœuds et de chemins de communication qui peuvent vous montrer en un coup d'œil, les différents environnements qui existent dans votre projet et où chaque composant doit être déployé.

Nous nous plongerons davantage dans UML à l'avenir, en particulier dans une autre notation utile appelée diagrammes de séquence, ainsi que dans des exemples plus détaillés de diagrammes de scénarios de cas d'utilisation pour étoffer les exigences du projet et créer des prototypes.

La plupart, sinon tous les développements et déploiements modernes utilisent une forme de contrôle de version, comme git et SVN. Les référentiels de code source ne sont pas seulement essentiels pour les équipes seules, car leurs avantages sont étendus même si vous êtes un développeur WordPress solitaire.

Si vous êtes un client Pressidium, vous pouvez intégrer votre référentiel à votre compte via SFTP, en utilisant un service externe tel que deploybot. Vous pouvez également utiliser SFTP pour transférer vos fichiers sur votre compte, car il s'agit de la méthode la plus simple et la plus simple. Vous pouvez également créer plusieurs utilisateurs SFTP et les affecter à des sites Web et des environnements spécifiques. En parlant de cela, avoir un environnement de staging pour votre site Web garantit que votre processus de développement et de déploiement est plus rationalisé et que votre site Web de production est protégé contre les modifications indésirables. Par exemple, après avoir activé la mise en scène pour votre site Web, vous pouvez extraire une copie de la production, puis créer un compte SFTP pour votre développeur qui n'a accès qu'à l'environnement de mise en scène.

La mise en place d'un pipeline de développement rationalisé passant par plusieurs environnements est l'un des changements que le mouvement DevOps a apporté aux environnements informatiques. Adopter une discipline de livraison continue et faire en sorte que les modifications logicielles soient poussées progressivement et fréquemment, se traduit par des cycles de déploiement plus rapides et moins d'erreurs. Vous n'avez plus besoin de conserver des archives ZIP avec différentes versions de votre application. De cette façon, vous pourriez facilement perdre le fil et déployer le mauvais ensemble de modifications susceptibles de nuire à vos systèmes de production. Il y avait aussi le risque d'avoir des problèmes avec les autorisations de fichiers qui seraient mutilées, ce qui, au mieux, pourrait empêcher votre application de fonctionner correctement et, au pire, introduire des problèmes de sécurité.

Épilogue

Nous savons que votre temps libre en tant que développeur WordPress est assez limité. C'est pourquoi nous avons tout regroupé sur un seul document, car la surcharge d'informations est réelle et semble avoir un impact sur tous les travailleurs du savoir, et pas seulement sur les développeurs WordPress. Nous avons mentionné au début que notre objectif est d'une part de fournir des informations utiles, et d'autre part d'aborder des sujets qui, selon nous, sont sous-représentés dans la littérature WordPress actuelle. Devenir développeur WordPress est une chose, rester pertinent et compétitif en est une autre . Et pour ce faire, vous devez avoir une vision globale du génie logiciel en tant que discipline et acquérir de bonnes habitudes, méthodologies et techniques qui serviront votre carrière à long terme.