Héritage de projets WordPress : conseils pour le développement

Si vous dirigez une entreprise qui se concentre à la fois sur le développement de solutions à partir de zéro ou qui se concentre sur la mise en œuvre d’une solution personnalisée dans le contexte de projets préexistants (ou peut-être les deux), alors vous avez probablement – à un moment donné – été dans la situation d’hériter de projets WordPress.

S’attaquer à des projets à partir de l’une ou l’autre poignée apporte son lot de défis – la plupart d’entre eux sont les bienvenus – mais il semble être beaucoup plus courant pour les gens de se plaindre de travailler avec une base de code préexistante.

Ce n’est pas que je n’ai pas ce sentiment, mais je pense qu’il y a un niveau d’immaturité à faire cela. D’une part, oui, certaines bases de code sont carrément terribles. Mais certaines bases de code ne sont pas si mauvaises. En fait, je dirais qu’ils sont juste un peu différents de la façon dont vous le développeriez.

C’est un cas dans lequel les normes entrent en jeu, mais je m’éloigne du sujet pour l’instant.

Alors disons que vous héritez de projets WordPress et que vous n’êtes pas particulièrement satisfait de la base de code avec laquelle vous travaillez. Comment se fait-il que vous puissiez toujours apprécier le travail que vous faites sans vous sentir obligé de critiquer chaque aspect de ce dont vous avez affaire ?

Héritage de projets WordPress

Premièrement, cette notion de se plaindre du travail des autres est l’eau proverbiale dans laquelle je n’aime pas marcher.

• Je ne connais pas le contexte qui a conduit à ce que la base de code soit dans son état,
• Je ne sais pas pourquoi certaines choses ont été développées comme elles l’ont été (contraintes de temps, méconnaissance d’un projet, etc.),
• Je suis chargé de faire quelque chose dans le contexte du projet, alors pourquoi consacrer du temps à des choses qui ne font pas partie de ma responsabilité ?

Je comprends : il y a des moments où nous codons, nous écrivons pour communiquer avec du code qui existe déjà. Et cela peut être difficile. Il existe des modèles de conception qui ne sont pas spécifiquement adaptés à cette situation.

Mais plutôt que de couvrir cela, j’ai pensé partager trois choses qui, à mon avis, montrent de la maturité en matière de développement lors de l’héritage de projets WordPress qui peuvent nous irriter.

1 Ne pas tout refactoriser

Comme l’a dit Martin Fowler :

Ce refactoring opportuniste est décrit par l’oncle Bob comme suivant la règle du boy-scout – laissez toujours le code derrière vous dans un meilleur état que celui dans lequel vous l’avez trouvé.

De manière générale, j’aime cette règle, mais selon les exigences du projet, cela peut dépasser le cadre de nos responsabilités.

Ainsi, chaque fois que nous rencontrons quelque chose dont nous savons qu’il doit être refactorisé, mais que le projet se déroule sans heurts. Si vous apportez une modification à quelque chose parce que vous pensez que cela doit être fait, vous ne savez pas comment cela se répercutera tout au long du projet.

Si vous avez le temps de faire un audit complet du code, c’est une chose, mais si ce n’est pas le cas, votre tâche consiste à présenter ce que vous avez accepté de faire.

2 Concentrez-vous sur ce que vous avez accepté de faire

Et cela nous amène à ce point : lorsque vous héritez de projets WordPress, vous êtes chargé d’une certaine quantité de travail et rien de plus (c’est pourquoi nous avons un énoncé de travail, n’est-ce pas ?).

Donc, même si vous voulez changer l’environnement dans lequel vous vous trouvez, ne le faites pas. Concentrez-vous sur ce que vous pouvez faire, sur ce que vous seul pouvez faire et sur ce que vous avez accepté de faire.

Je pense que c’est bien de prendre des notes sur les problèmes, et je pense que cela peut même être bénéfique (et j’en parlerai dans un instant), mais ne perdez pas de vue ce que vous avez accepté de faire. Faire n’importe quoi mais n’est pas professionnel.

3 Ne jugez pas le développeur précédent

Une autre chose qui est courante – en particulier dans l’open source – est de juger le développeur qui a écrit l’ensemble initial de code avec lequel vous travaillez.

Qu’est-ce que c’est? Je ne l’écrirais jamais ainsi.

Je veux dire combien de fois avons-nous pensé cela à nous-mêmes? Mais nous ne connaissons pas le temps, les contraintes, l’expérience ou le contexte dans lequel le développeur travaillait.

Le code que nous publions n’est pas nécessairement représentatif de notre niveau de compétence. Elle est souvent dictée par des variables tierces qui ont une influence sur la manière dont nous mettons en œuvre une solution.

Et nous savons ce que c’est, n’est-ce pas? Combien de fois avons-nous voulu faire quelque chose d’une seule façon, mais les contraintes et le calendrier dans lesquels nous travaillons dictent ce que nous faisons ?

Alors, pourquoi s’attendrait-on à ce que ces développeurs soient différents ?

Facultatif : Offrir une assistance future

Comme mentionné précédemment, si vous rencontrez des zones de la base de code qui posent problème, cela ne signifie pas que c’est une cause perdue.

Au lieu de cela, lorsque vous rencontrez ce type de problèmes, je pense que c’est une bonne idée de :

• prendre des notes sur les choses que vous avez vues,
• annotez ce que vous feriez pour le réparer et pourquoi,
• parlez au client de ce que vous avez vu et des avantages de le mettre à jour.

Cela conduit évidemment à des travaux futurs mais, peut-être au-dessus de cela, cela vous permet de proposer des solutions pour créer de meilleurs logiciels mieux architecturés et cela vous permet de vous assurer que vous faites d’Internet un meilleur endroit pour un CMS si populaire.

Non, ce travail n’est jamais garanti, mais il est utile.

Je suis sûr qu’il y a plus

Ce ne sont que trois conseils que je propose en fonction de l’expérience que j’ai lors de l’héritage de projets WordPress. Il n’est pas censé être global.

Au lieu de cela, il est destiné à fournir quelques conseils qui vous permettent d’être plus attentif au travail des autres par rapport à votre travail, de réfléchir plus clairement à ce que vous pouvez faire face à des situations similaires et d’accumuler plus de travail en améliorant l’existant. solution potentiellement.

Mais je sais que les choses que j’ai mentionnées ne sont que quelques-unes de mes observations. Vous avez le vôtre ? Mentionnez-les dans les commentaires.