Wordcamp paris 2015 dev-pragmatique-bonnes-pratiques

4 455 vues

Publié le

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

Publié dans : Internet
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
4 455
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2 507
Actions
Partages
0
Téléchargements
15
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Wordcamp paris 2015 dev-pragmatique-bonnes-pratiques

  1. 1. les bonnes pratiques Sylvie Clément alias Oelita Le développeur pragmatique vs
  2. 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. 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. 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. 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. 6. Le pragmatisme Réalité du quotidien Recherche de l’efficacité Adaptation à son propre contexte
  7. 7. Le pragmatisme Chercher, écouter Comprendre les arguments Evaluer l’intérêt pour soi
  8. 8. Match ou équilibre ? Concret Coût Court terme Confort Théorie Risques Long terme Rigueur
  9. 9. Objectifs Qualité Productivité Evolutivité Réutilisabilité Maintenabilité Sécurité Future-proof ?
  10. 10. 8exemples autour de la Gestion du code
  11. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. @Oelita

×