Conférence que j'ai donnée au WordCamp Paris 2015 le 23 janvier 2015. Sujet : le pragmatisme du développeur freelance Wordpress versus les bonnes pratiques des agences ou des développeurs de plugins et de thèmes

1. les bonnes pratiques
Sylvie Clément
alias Oelita
Le développeur pragmatique
vs

2. Le pourquoi du comment
 Ingénieure
 20 ans en DSI
 Méthodes pour 100
développeurs
§ Mère de 5 enfants
§ Créatrice et admin de
sites web depuis 15 ans
§ Freelance

3. Le pourquoi du comment
Avant, j’avais des principes.
Maintenant, j’ai des enfants.
Avant, j’avais des méthodes.
Maintenant, j’ai des clients.

4. Les bonnes pratiques
Des normes
Des conseils
Du partage
d’expérience
Des guides
Des Codex
Des tutoriels
Des livres
Des sites
Des articles

5. Les bonnes pratiques
souvent proposées par des
développeurs de plugins/thèmes,
ou par des gens qui
travaillent en équipe.
Et si on travaille en solo
pour l’unique site d’un client ?

6. Le pragmatisme
Réalité du quotidien
Recherche de l’efficacité
Adaptation à son propre contexte

7. Le pragmatisme
Chercher, écouter
Comprendre les arguments
Evaluer l’intérêt pour soi

8. Match ou équilibre ?
Concret
Coût
Court terme
Confort
Théorie
Risques
Long terme
Rigueur

9. Objectifs Qualité
Productivité
Evolutivité
Réutilisabilité
Maintenabilité
Sécurité
Future-proof ?

10. 8exemples
autour de la
Gestion du code

11. ne pas toucher au « core »
Les répertoires de WordPress
sont les suivants :
/wp-admin
/wp-includes
/wp-content
/plugins
/themes
/uploads
« ne jamais modifier
un fichier WordPress,
ce sera écrasé à la
prochaine mise à
jour »
core
1

12. ne pas toucher au « core »
Vrai aussi pour le code des plugins et celui des thèmes !
Mettre à jour les
versions de WP et des
plugins
Et utilisez hooks et actions…
1

13. faire des thèmes Enfants
Mettre à jour le thème parent
Isoler / identifier les
personnalisations apportées
« ne pas modifier un
thème existant, mais y
ajouter un thème
enfant »
2

14. faire des thèmes Enfants
Simple à faire
Mais ajoute une surcouche
A privilégier pour les
« gros » thèmes,
Ou des modifs mineures
2

15. pas de fonctionnel dans le thème
L’approche MVC…
Modèle Vue Contrôleur
Pouvoir découpler présentation
et traitements/données
Pour les Custom Post Type,
taxonomies, shortcodes
« le fonctionnel doit
aller dans un plugin,
et le design dans un
thème »
http://davidbhayes.com/talks/theme-creep/
3

16. pas de fonctionnel dans le thème
Qui s’amuse à changer de thème avec des CPT ?
Les deux sont liés
Si on n’a pas une équipe avec intégrateur
Découpler modèles et
functions.php
3

17. le copier-coller, c’est le mal
On doit faire évoluer la même
chose à plusieurs endroits.
Il peut y avoir des différences de
contexte qui vont créer des
bugs.
Copier des bouts de code
exterieurs
« tout code dupliqué
est source de
problèmes : DRY ! »
4

18. le copier-coller, c’est le mal
Factoriser : inc de templates, functions.php, mu-plugins
Ne pas multiplier les paramètres ou options…
Factoriser au maximum
à l’intérieur d’un projet
Se créer une bibliothèque
4

19. pas de requête SQL en direct
Le modèle SQL peut changer
avec les versions.
Moins sécurisé.
Maîtriser le modèle et les
impacts.
« toujours passer par
les fonctions et API
WordPress»
5

20. pas de requête SQL en direct
Les modèle ET les fonctions peuvent changer…
Souvent plus performant pour des SELECT complexes.
A réserver aux cas
difficiles
5

21. toujours faire des sauvegardes
Les fichiers ET la base de
données
Régulièrement
A plusieurs endroits
Les vérifier
« après, c’est trop
tard »
6

22. Régulièrement ET avant chaque intervention.
L’historique peut être utile.
Des outils existent pour
faciliter la tâche
toujours faire des sauvegardes
6

23. versionner son code
Permet de travailler en équipe
Produit des versions claires
Permet le retour en arrière
Sert également de sauvegarde
Synchronisation d’environnements
« la gestion des
sources via un outil
de type Git »
7

24. Beaucoup moins utile en solo qu’en équipe.
On peut s’organiser sans outil lourd.
Les retours en arrière sont rares.
Si vous en avez
l’habitude
versionner son code7

25. commenter son code
Notre mémoire a ses limites
La doc peut être semi-automatique
PHPDoc + « Make PHP code self-
explaining with PHPXref »
« la doc permet de
mieux comprendre le
code quand on s’y
remet »
8

26. Répéter le code ?
Les éditeurs de texte sont efficaces en recherches.
La doc humaine !
Documenter le comment
et le pourquoi,
En français
commenter son code
8

27. Perfectionnisme ou pragmatisme ?
Expérience des autres / Son propre contexte
S’informer, évaluer, décider
Concret
Coût
Court terme
Confort
Théorie
Risques
Long terme
Rigueur

28. @Oelita