Programmation orientée objet dans WordPress : analyse, partie 2
Dans le premier article de cette série, j’ai tout expliqué sur la façon dont je voulais aborder une introduction à la programmation orientée objet dans le contexte de WordPress.
Il existe d’excellentes ressources pour la programmation orientée objet, mais elles peuvent utiliser des exemples artificiels, ou elles peuvent aller trop vite pour ceux qui cherchent juste à se lancer.
Pour éviter que cela ne se produise, je pense que parler de POO dans WordPress nous ancre sur une base solide et utiliser des exemples pratiques sera toujours mieux que d’utiliser des exemples génériques difficiles à traduire dans le domaine dans lequel nous travaillons.
Pour ceux qui n’ont pas encore rejoint ou qui n’ont pas encore rattrapé leur retard, le premier article porte sur les sujets suivants :
- Analyse orientée objet,
- Détermination des incontournables par rapport aux agréables à avoir,
- Et pourquoi est-ce difficile ?
Et c’est là que ce post va reprendre.
Programmation orientée objet : plus d’analyses
Je sais: lorsqu’il s’agit d’écrire du code, la première chose que nous voulons faire est de nous asseoir et de commencer à écrire du code. Quoi de mieux que de faire bouger quelque chose à l’écran ?
Et lorsque vous faites cela pour vous-même, ce n’est pas si grave, mais lorsque vous écrivez du code, cela va être :
- entretenu par une équipe de personnes,
- à vendre,
- ou pour tout ce qui précède
Cela fait une différence. Car une bonne analyse peut déboucher sur une bonne organisation qui peut déboucher sur une bonne maintenabilité.
Sinon, vous bricolez quelque chose pour l’expédier, et cela ne va pas bien évoluer avec les futures versions. Et c’est quelque chose dont nous parlerons en profondeur tout au long de la série.
Mais qu’est-ce qu’un bon moyen de résumer une bonne analyse en trois étapes faciles ? Ce n’est pas nécessairement une réponse à toute épreuve, mais c’est ce que nous essayons de faire chaque fois que nous travaillons sur des projets :
- Assurez-vous que le code fait ce que le client veut,
- Appliquer les bonnes pratiques orientées objet,
- Visez une conception maintenable.
Tout cela semble bien en théorie, mais sans approfondir chacun, comment savoir si nous le faisons correctement? En d’autres termes, c’est là que nous trouvons souvent des livres, des ressources et d’autres utilitaires qui rendent difficile de devenir un meilleur programmeur orienté objet.
C’est précisément ce que je veux éviter, donc je vais creuser un peu plus chaque point.
1 Ce que veut le client
Cela peut être l’un des aspects les plus difficiles de l’ensemble du projet, souvent parce que nous, en tant que développeurs, parlons une langue différente du client.
Non seulement ils utilisent souvent une terminologie que nous n’utiliserions pas, mais ils pensent souvent que ce qu’ils veulent à l’écran est la meilleure façon de s’y prendre. Cela donne l’impression qu’il est vraiment condescendant et erroné d’essayer de les corriger, n’est-ce pas ?
Je veux dire, imaginez essayer de dire à quelqu’un que vous savez ce que vous voulez, et il vous corrige. Gérer cela avec soin est quelque chose qui peut gagner une grande équité relationnelle, mais il faut un certain temps pour «fouiller» ce qu’ils veulent vraiment par rapport à ce qu’ils disent vouloir.
Et nous allons nous plonger davantage dans ce sujet dans un prochain article.
2 pratiques orientées objet
Évidemment, cela vient du fait de savoir quelles sont les bonnes pratiques orientées objet et c’est quelque chose que je prévois de couvrir.
Beaucoup de gens diront des choses en utilisant des choses telles que :
- les principes SOLID,
- héritage,
- Code SEC,
- injection de dépendance,
- etc
Sont tous importants pour suivre de bonnes pratiques orientées objet.
Et peut-être que ce n’est pas une chose populaire à dire, mais je pense qu’essayer d’utiliser toutes les choses tout le temps n’est pas toujours une bonne idée. Autrement dit, vous ne voulez certainement pas que le code soit répété dans votre base de code, mais devez-vous avoir un héritage dans votre base de code ?
Non.
Il y a des moments où les principes doivent être appliqués et où ils peuvent être ignorés. Mais les connaître, quand les utiliser au mieux et quand les utiliser sont essentiels pour utiliser correctement ces pratiques.
3 Conception maintenable
En termes simples, l’application de modèles et de principes à votre logiciel lors de son écriture est ce qui le rendra beaucoup plus facile à utiliser et à maintenir à l’avenir.
Mais, encore une fois, cela dépend de :
- bien comprendre ce que veut le client,
- savoir quelles pratiques existent, quand les appliquer et quand les éviter.
Et pour faire tout ce qui précède, nous devons examiner chaque point dans son contexte avant de prendre du recul pour regarder la situation dans son ensemble.
Que veut le client ?
De toute évidence, il y a beaucoup de terrain à couvrir en ce qui concerne les trois points ci-dessus. Mais si vous voulez écrire un bon logiciel maintenable dans l’économie WordPress, il est important de comprendre comment tout cela s’imbrique.
Ainsi, plutôt que de se lancer dans l’écriture de code ou de se lancer dans le travail sur un projet, la prochaine chose que nous allons examiner est de savoir comment prendre ce que le client veut et ensuite déchiffrer cela dans un ensemble d’exigences qui nous permettent de créer un déclaration de travail.
De cette façon, nous aurons finalement un document de travail de ce que le client veut et de ce que nous allons construire, et nous serons tous sur la même longueur d’onde.