Appuyez sur ceci : Éviter les dettes technologiques chronophages sur les versions WordPress avec Jon Martin

Bienvenue sur Press This, le podcast de la communauté WordPress de WMR. Ici, l'hôte David Vogelpohl s'assoit avec des invités de toute la communauté pour parler des plus gros problèmes auxquels sont confrontés les développeurs WordPress. Ce qui suit est une transcription de l'enregistrement original.

Propulsé par RedCircle

David Vogelpohl : Bonjour à tous et bienvenue sur Press This, les podcasts de la communauté WordPress sur WMR. Voici votre hôte, David Vogelpohl, je soutiens la communauté WordPress à travers mon rôle chez WP Engine, et j'aime apporter le meilleur de la communauté pour que vous entendiez chaque semaine sur presse ceci pour rappel, vous pouvez me trouver sur Twitter @wpdavidv , ou vous pouvez vous abonner pour appuyer dessus sur iTunes, iHeartRadio, Spotify ou télécharger les derniers épisodes sur wmr.fm. Dans cet épisode, nous allons parler de l'un de mes sujets préférés, à savoir éviter de perdre du temps dans la dette technologique sur les versions de WordPress. Et en nous rejoignant pour cette conversation, j'aimerais souhaiter la bienvenue à Jon Martin. Jon, bienvenue sur Press This.

Jon Martin : Merci beaucoup, c'est bon d'être ici.

DV : Je vous sais que je m'entraîne à prononcer Hallum avant le concert mais bien sûr j'ai tout gâché dès le début John désolé pour ça. Génial, donc pour ceux qui écoutent avec John, je vais partager ses réflexions sur l'impact de la dette technologique sur les équipes de développement WordPress, comme que signifie avoir une dette technologique et comment cela vous affecte-t-il ? Comment vous pouvez penser à réduire votre dette technologique sur chaque projet. Et puis pourquoi vous avez la responsabilité de partager les considérations de dette technologique avec vos clients

JM : si vous travaillez en tant qu'agence indépendante. J'adore tuer la dette technologique. J'adore l'éliminer, c'est l'un de mes sujets favoris.

DV : Nous allons revenir sur les réflexions de John sur le sujet, mais avant de commencer, John, je vais vous poser la même question que j'ai posée à tous les invités. Parlez-moi brièvement de votre histoire d'origine WordPress. Quand avez-vous utilisé WordPress pour la première fois

JM: donc j'aurais été au début des années 2010, je n'étais pas vraiment sûr de l'expression correcte pour cette période. Donc, je me suis lancé moi-même et j'ai été PDG de la façon dont nous avons lancé une agence en 2008. Et à l'époque, WordPress était encore une plateforme de blogs. Nous étions en train de créer des sites Web contenant beaucoup de contenu riche. C'est un peu un gros mot, mais nous utilisions Joomla à l'époque. Mais alors plutôt que

DV : Joomla est un gros mot. J'aime tous les CMS open source personnellement.

JM : Oui, nous aimerions dire que c'est un super projet. Je pense que l'essentiel pour nous est qu'au fil du temps, Joomla était vraiment très fort lorsque WordPress a mis en place un support de site de publication personnalisé. C'est à ce moment-là que les choses ont vraiment vraiment changé dans WordPress pour moi, ce qui l'a fait passer de ce qu'il était connu comme une plate-forme de blogs à un véritable CMS à part entière sur lequel vous pouvez créer toutes sortes de sites, que ce soit pour vous, vraiment petit une entreprise individuelle ou un pigiste ou autre, jusqu'à des sites Web complexes de grande taille. Et je pense vraiment, vraiment pour moi, que c'était une décision mortelle de leur part parce que c'est en partie la raison pour laquelle WordPress est si populaire maintenant. Alors oui, c'est à ce moment-là qu'elle a commencé à consommer ici. Sasha, l'histoire d'avant, c'est vraiment moi-même et maintenant PDG de la façon dont nous étions dans un groupe ensemble. Et nous avons cette brillante idée de penser, Eh bien, vous savez quoi, c'est génial d'avoir plus de temps égal sur la route et c'est vraiment difficile de me libérer de mes emplois actuels. Nous avons donc pensé, vous savez quoi, lançons une agence et devenons des développeurs Web, car cela nous aidera vraiment à récupérer tout ce temps à l'époque, c'était une excellente décision. J'en suis vraiment très content mais c'est aussi certainement une décision naïve parce que penser que travailler pour soi donne plus de temps était définitivement une erreur que je pense qu'on reconnaîtra un peu plus tard. Et avant cela, vous savez, je connaissais un peu SQL et je construis des ordinateurs depuis bien, en fait depuis que la carte graphique supporte très bien les couleurs. Donc, pour quiconque sait ce qu'est CGA, cela vous aidera à savoir quel âge j'ai. Mais oui, vraiment, c'était quand les CPT sont sortis. Cette graisse a tout changé pour nous. Et nous avons commencé à utiliser WordPress à peu près du jour au lendemain, en fait, c'est devenu notre CMS choisi et nous n'avons pas regardé en arrière depuis et, vous savez,

DV : de toutes les personnes à qui j'ai posé cette question, très peu ont réellement compris la relation entre les types de publications personnalisées matérielles et leur histoire d'origine WordPress. Et c'est drôle. J'ai une histoire similaire. J'ai fondé une agence en 2010. Donc, un peu après vous tous, mais quand la publication personnalisée est déjà arrivée. Nous avons commencé à construire avec Joomla et à passer à WordPress pour des raisons similaires, mais c'était ces types de publication personnalisés et méta personnalisée domaines que je suis d'accord et que j'ai effectivement présentés de cette façon divers format, c'est que c'était ce genre de moment où WordPress est vraiment devenu un vrai CMS. Un an après la création de WooCommerce, WP Engine a vu le jour, de nombreuses autres marques d'espace WordPress, c'est une période tellement transformatrice. C'est intéressant d'entendre votre sorte de référence qui est la racine de votre histoire d'origine. Ils me disaient cependant, comment euh, et vous savez, le moment fondateur là-bas si vous voulez, mais pourriez-vous brièvement me dire un peu comment euh, et ce que vous faites ?

JM : Oui, bien sûr. Donc, en fait, cette agence, nous avons découvert que ce n'était pas comme ça que nous roulions plus tard. OK OK. Eh bien, la principale raison à cela est en fait que, vous savez, à l'époque, il y avait une différence très nette entre, vous savez, nous construisons des sites Web par rapport à nous faisons du référencement et tout ce genre de choses. Et il n'y avait pas vraiment beaucoup d'approches intégrées dans le monde et qui pensaient réellement à des choses comme l'expérience utilisateur, et comment cela fonctionne avec le référencement et le développement, tout ce genre de choses. Donc, c'est en fait pourquoi nous avons fini par fusionner plus tard avec Allen Milan depuis environ 20 ans et notre fondateur s'est installé à peu près au début lorsque le référencement a commencé à devenir une chose. Alors oui, nous avons donc fusionné les deux agences. Il y a six, sept ans, peut-être un peu plus longtemps. Ma mémoire pour les données n'est pas grande, je dois l'admettre. Et puis Et puis vraiment, ouais, c'est devenu notre approche, est-ce cette approche entièrement intégrée qui consiste à mélanger toutes ces différentes disciplines pour aider les gens à voir la ligne ? Alors maintenant, nous faisons du PPC, du référencement, des relations publiques numériques, évidemment, de la conception Web et il y a des extensions de marque, de la stratégie numérique et tout ce genre de choses, toutes ces disciplines dont vous avez vraiment besoin pour avoir une bonne présence numérique forte de nos jours. Quel est votre rôle là-bas, l'entreprise? Donc mon, mon titre de poste était directeur technique. Donc je vais être honnête, ça ne couvre pas vraiment tout ce que je fais. J'ai dirigé l'équipe de développement pendant une longue période. Donc, tout ce que WordPress sera était sous ma direction. Je suis heureux de dire que nous avons de bien meilleurs développeurs dans l'équipe que ceux que nous avions alors Julio et moi avons jamais travaillés lorsque nous avons commencé, c'est la raison pour laquelle nous faisons beaucoup mieux ces jours-ci. Et on comprend un peu mieux les choses. J'ai donc dirigé l'équipe de développement pendant une longue période plus récemment sur une équipe de coût des données également. Cela signifie donc que je peux jouer avec l'apprentissage automatique, Python et Bartek et d'autres jouent même si je dois imaginer tout cela en train de jouer.

DV : Faire des clients séparés sympas va entraîner une certaine dette technologique en cours de route. Et donc je suis curieux de savoir comment vous pensez, quels sont les types courants de dette technologique et peut-être spécifiques à WordPress. Ceux-là pendant une minute, mais comme, comment pensez-vous à cela pendant que vous pensez, vous savez, comment et comment vous gérez votre dette technologique, comme si vous l'aviez enfermée dans des types avec WordPress construit ?

JM : Oui, nous le faisons. Je veux dire, non. Pas nécessairement. Nous utilisons une sorte de langage dans lequel nous ne catégorisons pas nécessairement les choses ou ne passons par un processus de district pour la catégorisation, mais en réalité, elles se répartissent en trois catégories différentes. L'un d'eux est lorsque vous créez un mauvais code par-dessus des codes existants, et c'est peut-être parce que vous avez peut-être fait des erreurs dans le passé qui pourraient être un problème sur les sites Web d'Heritage et quelqu'un d'autre quelle qu'en soit la raison, c'est donc le sorte de premier seau. Le second est le code de construction qui n'est pas nécessaire, et qui n'est peut-être tout simplement pas nécessaire pour le moment. Vous savez, je suis sûr que nous avons tous été à la fin des demandes de fonctionnalités des clients et des marques avec lesquelles nous travaillons où ils sont vraiment désireux de quelque chose en particulier, mais en fait ce n'est peut-être pas la bonne chose, en termes d'obtention de valeur réelle pour les clients. Et puis le troisième, qui est le plus important que nous voyons en fait, consiste à créer des fonctionnalités qui devraient en fait être sur une plate-forme différente. Donc, pour comprendre ce genre de pièce architecturale, d'accord, quels sont les différents éléments que nous branchons ici, c'est un CRM ici, c'est le site Web, qui concerne fondamentalement le marketing de l'entreprise. Voici votre plate-forme de traitement des commandes, toutes différentes.

D V : Permettez-moi de vous demander, permettez-moi de vous poser une question fondamentale ici, comme vous, vous avez en quelque sorte répertorié les trois types de sons comme ceux-ci sont les trois types de dette technologique dont vous voulez vous débarrasser, écrire du mauvais code sur du mauvais code code, ce ne sont pas des fonctionnalités nécessaires qui peuvent être réalisées sur une autre plate-forme. Comme n'y a-t-il pas un quatrième seau comme les fonctionnalités que vous voulez qui sont précieuses et donc la technologie qui est peut-être bonne dans ce cas ? Est-ce juste de dire? C'est un quatrième seau.

JM : Ouais. 100% Je veux dire, toutes les dettes techniques ne sont pas mauvaises. Vous devez accepter que pratiquement toutes les fonctionnalités que vous allez créer accumuleront un certain type de dette technique et vous devez faire un appel pour savoir si cette dette technique est bonne ou non. Certains sont bons, d'autres sont mauvais et dépendent vraiment du mot-clé que j'ai dit auparavant qui concerne la valeur. Allez-vous obtenir la valeur dont vous avez besoin pour cette chose? Plus important encore, le client, le client ultime, n'est-il pas votre client, mais ses clients ? Vont-ils en tirer profit ? C'est généralement un assez bon guide pour savoir s'il faut accepter cette dette technique.

DV : Ouais, je veux approfondir ce que vous pensez de cette citation, la formule qui en vaut la peine pour savoir quand il est acceptable d'accepter ou non, mais c'est bon d'y penser et de bien comprendre comment vous pensez à les différents seaux de types de dette technologique, et en particulier ceux que vous voudrez peut-être optimiser pour supprimer. Ce que j'aimerais faire ensuite, c'est comprendre, par exemple, est-ce qu'il y avait quelque chose qui vous a poussé à bout pour vous concentrer sur ce domaine, mais nous allons faire notre première pause et nous allons je reviens tout de suite. Il est temps de se brancher sur une pause publicitaire. Restez à l'écoute pour plus pressant ceci juste un instant. Bonjour à tous. Bienvenue à nouveau pour appuyer sur les podcasts de la communauté WordPress sur W EMR Voici votre hôte, David Vogel. Paul. J'interviewe John Martin à propos de l'annulation du temps qui tue la technologie. John, juste avant la pause, vous expliquiez que la façon dont vous concevez les trois types de dette technologique que vous pourriez vouloir éliminer est de construire du mauvais code sur du mauvais code en créant du code qui n'est pas nécessaire au succès du site sur lequel vous travaillez. Et puis peut-être créer du code pour des fonctionnalités qui peuvent être mieux servies sur une autre plate-forme. Avant d'entrer dans la formule de la citation qui en vaut la peine, cependant. Je me demandais s'il y avait une période particulière que je ne connais pas et votre voyage est un exemple particulier de dette technologique que ce genre de surface est pour vous un domaine d'intérêt principal pour savoir comment?

JM : Oui, absolument. Il y a un vrai projet historique qui a commencé à me faire réfléchir il y a environ quatre ou cinq ans maintenant. J'ai vu plein d'autres cas. Les entreprises accumulent du temps, tout le temps, pas seulement via WordPress à travers toutes sortes de choses, en fait, les entreprises en accumulent également à travers leurs processus opérationnels. Si vous devez être une chose technique où vous créez ce deck. Un, l'histoire qui m'a vraiment marqué plus que n'importe quel autre client, nous travaillons avec une entreprise relativement petite pour laquelle nous avons fait beaucoup de travail médiatique rémunéré. Vendre essentiellement des trucs en ligne. C'était une entreprise de commerce électronique. Et ils avaient un type traditionnel de vente par correspondance, mais une grande partie de leur travail et ils essayaient de générer plus de trafic en ligne afin qu'ils n'aient pas à passer par la vente par correspondance seront gérés via le site Web et ils sont venus nous voir parce qu'ils ont a fait construire un site pour eux est entièrement sur mesure. Et ils existent depuis environ 10 ans à ce moment-là. Donc, il devenait assez vieux et commençait à ramper un peu. Vous savez, les normes et passez à autre chose. La technologie a évolué, il est temps de repenser un peu. Alors le client s'est assis avec nous, ils ont commencé à débriefer toutes les différentes choses qu'ils ont faites sur le site Web. Et il est devenu très vite clair pour moi qu'il y avait toutes sortes de logique métier et de trucs opérationnels commerciaux qui avaient été intégrés au site Web. Et c'était une logique qui mène aux commandes et qui est assez spécifique à la façon dont ils travaillent avec les fournisseurs. Je n'entrerai donc pas dans les détails, mais j'ai un arrangement assez complexe entre les fournisseurs et la façon dont ils remplissent les commandes et s'ils ont été expédiés dans leur magasin avant qu'ils n'envoient tout ce genre de choses. Tout est donc assez compliqué. Maintenant, le propriétaire de l'entreprise et le précédent sur la façon dont ils fonctionnent, ont finalement construit un système qui gère à peu près tout ce qui était un très, très bon système à l'époque et a véritablement aidé cette entreprise à se développer massivement. Maintenant, ce à quoi ils n'ont pas vraiment pensé, c'est que tous les sites Web ont finalement une durée de vie qu'ils prendront vie à un moment donné, comme n'importe quel logiciel et dans le monde du marketing. Cette durée de vie est vraiment relativement courte par rapport à, vous savez, par exemple, si vous investissez dans un CRM, car une entreprise aura normalement cette durée de vie pendant un certain temps maintenant, c'est environ 10 ans, sinon plus de sites Web. D'une manière générale, entre deux et cinq ans, nous constatons que la plupart des grandes marques ont tendance à se reconstruire tous les trois ans environ. Le problème était donc qu'ils ont intégré toute cette logique compliquée dans le site Web existant et qu'ils ont dû reconstruire l'intégralité du site Web. Et tout d'un coup, vous devez également reconstruire toute cette logique métier. Maintenant, nous avons chiffré le projet et cela a fini par représenter environ la moitié du chiffre d'affaires annuel à la base juste pour reconstruire ce que nous avions déjà. Et cela a vraiment commencé à me faire réfléchir à cette chose, c'est que, d'accord, s'ils abordent le problème d'une manière différente à l'origine, par exemple, réfléchissons aux différentes choses que nous essayons de réaliser sur un site Web. Vous savez, cela vient du marketing, c'était pour vendre des produits. C'est pour l'exécution des commandes, c'est mieux pour gérer mon processus d'affaires avec des fournitures toutes ces choses, et j'ai pensé de manière un peu plus modulaire à ce sujet, alors cela aurait été une situation bien différente pour ce client, qu'elle était là . C'était un vrai problème pour eux parce qu'ils avaient un site Web qui leur permettait essentiellement de gagner de l'argent. Il grinçait beaucoup car il est assez vieux. Mais en même temps, cela allait coûter très cher pour reconstruire tout ce site Web et rendre le projet très, très compliqué. Nous avons réussi à trouver un travail assez intelligent mais aussi pas agréable jusqu'à la fin pour essayer d'utiliser ce qu'ils avaient déjà et de l'intégrer mais nous ne pouvons pas citer mais vous savez, finalement fini par être beaucoup plus douloureux beaucoup plus lent et beaucoup plus cher que nécessaire. Si cette architecture avait été pensée à l'origine.

DV : J'ai tellement de projets que je veux oublier ça. Étaient juste comme ça, et je peux l'imaginer maintenant, je me ramène dans le temps. Donc, pour moi, cela semble assez clair, c'est une leçon très, je pense, importante pour réfléchir au type de coût pour l'entreprise par rapport au refactor que vous prévoyez. Et pour moi, il semblait que la réponse claire était que vous deviez l'architecturer différemment. Et c'est peut-être un chemin plus clair si vous aimez ce que vous devriez faire. Mais je pense que, comme beaucoup d'équipes, quand elles pensent à la dette technologique, c'est comme si elles se disaient, d'accord, eh bien, ce serait cool de faire ce truc, mais est-ce que ça vaut le coup ?

JM : Est-ce que ça vaut la peine que je maintienne ce truc dans le temps ? Donc je suis juste curieux de savoir comment vous pensez de cette formule

DV : Quand, par exemple, quand est-il acceptable d'introduire la dette technologique ? Et combien juste comment pensez-vous de cette formule?

JM : Ouais, vous avez abordé un point vraiment important, c'est que, vous savez, vous pensez à la nature des développeurs, les développeurs s'y mettent parce qu'ils aiment faire des trucs sympas. Et c'est, vous savez, une grande partie de notre motivation est d'apprendre à faire de nouvelles choses, de nouvelles technologies, vous savez, de nouveaux frameworks JavaScript, quoi qu'il en soit, et cela nous donne naturellement la motivation qui devient pour construire des trucs sympas, mais nous ne pensons pas nécessairement à long terme à cela, vous savez, nous allons quand même le maintenir. Vous savez, ma femme aimerait avoir un bain à remous chez moi, mais je sais que quelqu'un va le nettoyer et je vais être honnête, je ne crois pas que quiconque le nettoie ait ce genre de pensée de toute façon. C'est donc une très, très, très bonne question à laquelle réfléchir, est-ce que cela en vaut vraiment la peine en premier lieu et si nous décomposons cela un peu, il y a quelques choses différentes auxquelles vous pourriez penser, tout d'abord, réfléchir longtemps terme, quel est le coût total de possession et de construction de cette chose pour la tester et la maintenir, puis peser cela par rapport à la valeur que nous obtenons ? Ainsi, par exemple, il peut y avoir un moyen très simple de résoudre ce problème. en utilisant des feuilles de calcul ou en utilisant des choses architecturales légèrement différentes où peut-être quelqu'un en interne à l'entreprise gère cela pendant une courte période de temps. Et ce serait moins cher et plus efficace de le faire que de construire cette fonctionnalité vraiment compliquée. Mais quand vous regardez réellement le coût total de possession, cela va coûter plus cher que pour quelqu'un qui passe quelques heures par semaine pour faire une chose particulière. Ne vous méprenez pas. Je suis un grand partisan de l'automatisation. les technologies devraient s'automatiser autant que possible pour éviter ce genre d'administration, mais

DV : vous vous inscrivez et vous utilisez des approches telles que ce manuel pour essayer quelque chose avant de le coder afin de vous assurer que la valeur sera là. Je veux dire, j'ai l'idée de simplifier ce facteur, comme, Pouvons-nous le faire manuellement à la place ? Juste curieux de savoir si vous l'avez déjà abordé dans une perspective de test pour aimer, voir si le retour ultime en vaut la peine ?

JM : Ouais. 100 %. Je suis donc un grand partisan de la méthodologie Agile. Et fondamentalement, l'un des grands principes clés d'Agile est que vous construisez la bonne chose au bon moment. Et vous vous concentrez sur la création de valeur le plus rapidement possible. Vous voulez donc construire le produit minimum viable. Maintenant, cela signifie que vous n'avez pas nécessairement quelque chose qui est entièrement riche en fonctionnalités à ce stade. Mais cela vous donne une plate-forme où vous pouvez ensuite commencer à le tester, vous savez, obtenez-vous réellement les choses que vous voulez de cela ? Vos utilisateurs y répondent-ils ? De la même manière que vous vous attendez à ce que quiconque a travaillé dans l'UX ou le développement Web sache que les clients recevront souvent des demandes parce qu'ils pensent que leurs clients, mais le veulent-ils vraiment ? C'est donc une autre très bonne question à poser, une fois que vous avez réfléchi à cette vision à long terme, est-ce que les gens qui vont utiliser le site Web savent-ils que quelqu'un l'utilise ou devons-nous tester pour voir s'ils veulent pour l'utiliser? Et puis une fois que vous avez fait ce test, nous pouvons déterminer ce que nous n'aurions pas dû demander et si nous devrions reculer et placer notre investissement ailleurs.

DV : Cela ressemble donc à une sorte de récapitulation de ces réflexions et j'ai aimé votre idée de regarder le coût total de possession à long terme, vous savez, je pense que souvent, les équipes pensent que même les personnes que vous connaissez, citent, commandent des services auprès du les équipes pensent au nombre d'heures ou de semaines ou d'écarts ou de points ou quoi que ce soit que cette chose va construire. Mais ensuite, vous savez, vous devez tenir compte du fait que vous savez, combien d'heures ou de semaines ou d'écarts ou de points faudra-t-il pour maintenir et ensuite utiliser cet équilibre par rapport à la valeur que vous retirez du maintien cette activité. C'est évidemment un bon conseil. Mais ensuite, vous pensez aussi, eh bien, y a-t-il quelque chose que je puisse faire pour tester cela pour voir si mes hypothèses sont correctes ? Cela vous semble-t-il exact ?

JM : Ouais. Absolument. Absolument. Et le seul élément que nous n'avons pas abordé est celui dont nous avons parlé un peu plus tôt, qui concerne l'architecture, y a-t-il une meilleure façon de structurer cela pour le rendre meilleur et ce temps pour la programmation d'objets et tout ça que j'aborderai probablement un peu plus tard.

DV : Ouais, les considérations architecturales aussi, comme j'ai en quelque sorte écrit comment vous étiez, y a-t-il un moyen de changer les spécifications ? Est-ce que c'est comme dans ma formation ou mes discussions avec les parties prenantes, je dis souvent, vous savez, des spécifications à déposer, n'est-ce pas ? Demandez ce dont vous avez vraiment besoin pour loger. Et donc demander ceux-ci mentira et sera vraiment nécessaire et qu'en est-il de cela? J'ai trouvé des questions très critiques. Il semble donc que ce soit un élément clé de la façon dont vous envisagez cela.

JM : Ouais, parce que chaque minute pendant laquelle ce site est en développement est une minute pendant laquelle il n'obtient pas de valeur devant les clients. Et c'est la façon facile d'y penser. Vous voulez vous lancer aussi vite que possible. Et puis testez, surveillez, itérez, apprenez, vous savez, voyez où vous allez à partir de là, mais uniquement parce que vous le faites en vous basant sur des données réelles plutôt que sur ce que vous pensez être juste. Parce que bien souvent ce ne sont pas les mêmes.

DV : Ouais, j'adore ce point. Toutes les minutes. C'est en développement, n'est-ce pas comme une minute que vous ne l'utilisez pas, et je dirai des liens vers une sorte de liens vers un autre mantra que j'ai et la gestion de projet et la gestion des parties prenantes, qui sont les deux meilleurs mots et obtenir un projet sur notre visage à écrire. Comment pouvez-vous parler ouais, j'aime ça quand je traite avec des parties prenantes, ou quand j'ai une partie prenante, c'est une partie puissante et puissante. D'accord, cool. Euh, parlons ensuite de ce que les équipes peuvent faire pour réduire la dette technologique. Mais avant cela, nous allons faire notre dernière pause. Il est temps de se brancher sur une pause publicitaire. Restez à l'écoute pour plus d'informations dans un instant. Tout le monde est de retour pour appuyer sur ce podcast de la communauté WordPress sur W EMR. Voici votre hôte David mobile Paul, je suis en train de parler d'éviter de perdre du temps avec la dette technologique avec John Martin de la façon dont John juste avant la pause, nous avons parlé un peu de votre formule qui en vaut la peine J'ai vraiment aimé vos notions sur la réduction spécifications. Et penser au coût total de possession et, en quelque sorte, adopter une approche de test itérative. Mais examinons maintenant ce que les équipes peuvent réellement faire pour réduire leur dette technologique et leurs builds WordPress. Quelles sont certaines de vos techniques préférées pour réduire la dette technologique ?

JM : Donc, il y a toutes sortes de techniques techniques que vous pouvez utiliser et vous en connaissez certaines avec lesquelles vous seriez familiarisé, donc vous ne le ferez pas, mais en fait, le point de départ pour moi est une approche beaucoup plus douce de la conversation. à vos clients. Et vous devez vous rappeler qu'en fin de compte, vos clients sont ces marques qui viennent nous voir parce que nous sommes les experts. Ils ont besoin de nos conseils et il est assez facile de tomber dans le piège où, vous savez, nous sommes là pour faire ce qu'ils veulent, ce que nous sommes là pour faire ce qu'ils veulent que nous fassions, mais en fait, nous sommes là remettre en question ce qu'ils veulent faire et essayer de l'améliorer. Donc, la première chose que vous pouvez faire est de leur en parler et de leur expliquer, si nous le faisons, cela en sera l'effet à long terme. Tu sais, ça va nous prendre une journée supplémentaire de tests. Chaque fois que nous publions une version, cela va ajouter quelques heures ou deux à chaque fois que nous devons maintenir le site Web et mettre à jour tous les plugins ou quoi que ce soit. Mais en augmentant cette prise de conscience, nous avons ces conversations avec eux. Vous pouvez amener le client à participer à cette discussion. Et puis finalement ils deviennent une partie de la résolution de problèmes avec bien, nous devons éduquer nos clients tout le temps, simplement parce qu'ils ne savent pas certaines choses que nous faisons. S'ils le faisaient, ils ne deviendraient pas des outils en premier lieu. Donc en fait, c'est le point de départ. Il pense s'en souvenir et simplifier les choses. Encore une fois, les gens ne sont pas nécessairement aussi techniques que nous. Utilisez donc des analogies pour en parler. Je trouve toujours que les maisons sont une grande énergie. Tout le monde vit dans la maison. La plupart des gens ont une certaine expérience de l'amélioration de leur maison. Il était donc assez facile d'utiliser cette énergie pour réparer les choses. C'est donc le genre de premier point qui consiste vraiment à trouver un client ou à faire défiler ces conversations. La prochaine chose que nous avons abordée auparavant était d'avoir cette vision à long terme ou le coût total de possession. Et posez-vous ces questions et questionnez chaque demande de fonctionnalité. Mais être un peu plus technique et comment vous feriez cela au travail. Des choses simples vous utilisez les standards WordPress vous savez, il y a des standards qui sont là. Ils existent pour une raison. Maintenant, ils nous aideront le développeur et peut-être que vous travaillez sur un projet que vous avez mis de côté pendant un an ou deux, puis vous y revenez. Vous devez vous rafraîchir la mémoire et revenir à l'endroit où vous étiez lorsque vous l'avez construit pour la première fois en utilisant des normes. Ils aideront également d'autres personnes. Donc, si vous n'étiez pas dans l'équipe, cela signifie que vous avez ce langage commun à partir duquel tout le monde peut fonctionner, ce qui est vraiment très utile en termes d'efficacité et d'aide à la documentation et à tout ce genre de choses. C'est donc une sorte de moyen plus doux de réduire votre dette technique en ayant des normes que tout le monde peut travailler. Cela vous aide également à savoir que le moment viendra peut-être où d'autres développeurs WordPress travailleront sur ce projet. Et cela les aide à y penser comme un moyen de rembourser la communauté et de faciliter la tâche de vos collègues développeurs. Donc c'est, c'est un, vous savez, un bon point autour de ce genre de normes et de faciliter les choses pour vous-même et pour les autres. Le prochain est plus génial. Grand code de l'industrie, affectueusement connu sous le nom d'Oncle Bob, qui a écrit un livre merveilleux intitulé The clean coder il y a de nombreuses années. Je recommanderais fortement à tout développeur de lire ce livre car il ne l'a pas lu. En fait, j'en ai rendu la lecture obligatoire pour une équipe de développement, pour quiconque a rejoint l'équipe, principalement parce qu'il a une si bonne approche à ce sujet parle de tests unitaires, tout ce genre de choses, mais fondamentalement, beaucoup de ça est de savoir comment écrire du code d'une manière qui le rend flexible, que vous pouvez très rapidement itérer, modifier et ajouter des bits supplémentaires. L'un des points importants dont il parle est de refactoriser souvent, et c'est la principale chose à en tirer, c'est que vous écrivez un morceau de code qui ne signifie pas nécessairement que ce morceau de code est terminé. Il y a des choses que vous pouvez faire pour l'optimiser pour le rendre plus portable pour le rendre plus modulaire ou pour améliorer un test, quelle que soit cette chose particulière que vous devez faire pour passer du temps à refactoriser le code. Cela peut être vraiment, vraiment difficile à faire quand vous y êtes confronté ou vous savez, c'est peut-être un délai pour un budget. Mais en fin de compte, c'est le genre de chose qui vous empêchera d'accumuler de la dette technique et en fait, c'est généralement la façon dont je vois que cela est forcé, mais comme une date limite de projet est en place, vous devez respecter cette date limite. Absolument. Vous devez le frapper, mais il vaut mieux assouplir la portée que d'écrire du mauvais code que vous allez ensuite,

DV : Je suppose qu'il faut également éduquer ces clients à ce sujet, car je n'ai jamais rencontré de développeur qui ne voulait pas refactoriser. Code. C'est toujours la chronologie. C'est contre. Euh, d'accord, alors voici le dernier petit mot, je suis juste curieux de savoir si vous nous aimez, si vous pensez à des choses comme le déchargement et l'utilisation de plugins prêts à l'emploi est une autre façon d'aider à éviter la technologie ou une autre façon d'éviter la dette technologique. Est-ce également dans votre liste?

JM : Ouais. 100% Donc c'est un bon moyen, mais c'est un bon moyen de faire les deux en fait, vous pouvez éviter la dette technique. Mais vous pouvez aussi et vous le savez, WordPress est une forme de BMC. Il est si actif, également, qu'il peut aussi être son pire ennemi. Il existe un plugin qui fait tout. Et il existe également de nombreux plugins qui ont été créés dans un but très précis, mais ils ne correspondent pas nécessairement à vos propres plugins. Donc, j'ai vu cela en particulier avec certains des développeurs qui aiment créer des sites en utilisant des plugins et une approche plus pointer-cliquer vers les choses plutôt que de les coder à partir de zéro. Les gens ont tendance à lancer des plugins sur les choses. Nous avons travaillé avec des sites Web qui avaient plus de 100 plugins et un tas d'entre eux ne sont plus maintenus. Il y a des problèmes de sécurité partout. Vous essayez de faire le taux de libération. Vous passez littéralement quatre jours à le tester alors que vous auriez pu le faire en quelques heures. Donc, les plugins peuvent être bons ou mauvais. La bonne prise au bon moment était une chose merveilleuse, merveilleuse. Les plus grandes forces de WordPress, mais le mauvais plug-in au mauvais moment peut aussi être gravement préjudiciable. Et peut en fait être l'une de ces plus grandes sources de capital qui

DV : J'ai eu un projet comme ça, c'est sûr. Eh bien, John, cela a été incroyablement perspicace. Merci beaucoup de vous joindre à nous aujourd'hui.

JM : Avec plaisir.

DV : Génial. Si vous souhaitez en savoir plus sur ce que Jon, vous pouvez visiter hallam.co.uk. Merci à tous d'avoir écouté les podcasts de cette communauté WordPress sur WMR. Encore une fois, c'était votre hôte David Vogelpohl. Je soutiens la communauté WordPress dans le cadre de mon rôle chez WP Engine et j'aime apporter le meilleur de la communauté ici sur Press This.