Upgrade to Pro — share decks privately, control downloads, hide ads and more …

42 bonnes pratique pour Symfony2

42 bonnes pratique pour Symfony2

7d0490ac1ac3bbd80889f36efa32e4eb?s=128

Tugdual Saunier

April 05, 2013
Tweet

Transcript

  1. 42 BONNES PRATIQUES POUR SYMFONY2 Tugdual Saunier (@tucksaun)

  2. ATTENTION

  3. Ce qui suit n'est trié ni par importance, ni par

    criticité.
  4. Bien entendu toute bonne pratique est discutable.

  5. Il y a toujours des exceptions.

  6. Soyez donc pragmatiques! Et remettez dans le contexte.

  7. POUR COMMENCER

  8. DOCUMENTATION La documentation est abondante. Lisez la.

  9. DOCUMENTATION Vous l'avez déja lue? Relisez la réguliérement

  10. DOCUMENTATION Quand vous cherchez de la doc ou de l'aide.

    Utilisez S y m f o n y 2 (majuscule, pas d'espace). Il y a tellement de ressources disponibles pour symfony (1.x) que vous perdriez du temps à trier.
  11. BOOTSTRAPPING À moins d'être à l'aise et de maîtriser parfaitement

    Symfony2, Utilisez la Standard Edition.
  12. BOOTSTRAPPING Utilisez la Standard Edition. Mais nettoyez! Supprimez le AcmeDemoBundle

    Supprimez les dépendances dont vous n'avez pas besoin Changez le favicon etc
  13. PROFILER La Web Debug Toolbar vous donne de nombreuses informations

    utiles. Ayez toujours un oeil dessus.
  14. PROFILER Interceptez les redirections (en dev). Cela vous facilitera le

    debug et vous permettra de voir plus facilement les informations collectées par le profiler.
  15. ORGANISATION

  16. SCM IGNORE app/cache/* app/logs/* app/bootstrap.php.cache web/bundles vendor app/config/parameters.yml Mais pour

    ce dernier, inclure un fichier app/config/parameters.yml.dist
  17. VOS MOTS DE PASSE SONT CONFIDENTIELS! Ne mettez pas d'identifiants

    en dur dans la configuration (utilisez les parameters) Ne versionnez pas votre p a r a m e t e r s . [ i n i | y m l ] Utilisez les variables d'environnements
  18. VOS MOTS DE PASSE SONT CONFIDENTIELS! # a p p

    / c o n f i g / c o n f i g . y m l d o c t r i n e : d b a l : u s e r n a m e : % d a t a b a s e _ u s e r n a m e % p a s s w o r d : % d a t a b a s e _ p a s s w o r d %
  19. VOS MOTS DE PASSE SONT CONFIDENTIELS! # a p p

    / c o n f i g / p a r a m e t e r s . y m l p a r a m e t e r s : d a t a b a s e _ u s e r n a m e : s y m f o n y d a t a b a s e _ p a s s w o r d : s 3 c r 3 t
  20. VOS MOTS DE PASSE SONT CONFIDENTIELS! < V i r

    t u a l H o s t * : 8 0 > S e r v e r n a m e w w w . d o m a i n . t l d # . . . S e t E n v S Y M F O N Y _ _ D A T A B A S E _ U S E R N A M E " s y m f o n y " S e t E n v S Y M F O N Y _ _ D A T A B A S E _ P A S S W O R D " s 3 c r 3 t " < / V i r t u a l H o s t >
  21. VOS MOTS DE PASSE SONT CONFIDENTIELS! Ce n'est pas limité

    aux mots de passe, valable pour toute information 'confidentielle'.
  22. CODING STYLE Respectez tout le temps le même coding style.

    De préférence suivez celui de Symfony2.
  23. CODING STYLE Un outil est disponible pour vous aider à

    respecter le coding style Symfony2: PHP Coding Standards Fixer http://cs.sensiolabs.org/
  24. APPLICATIONS? APPLICATION! Par défaut, une seule application existe dans un

    projet Symfony2. Il est extrêmement rare d'en avoir besoin de plusieurs, réfléchissez-y bien.
  25. APPLICATIONS Si vous voulez vraiment en utiliser plusieurs, votre arborescence

    doit être uniforme et respecter un maximum celle de la Standard Edition (dossier a p p ).
  26. BUNDLES Votre projet est composé de Bundles.

  27. BUNDLES Un Bundle = Une Fonctionnalité Si vos bundles ont

    pour vocation à être réutilisés, et si vos bundles sont découplés. U s e r B u n d l e = > G e s t i o n U t i l i s a t e u r F o r u m B u n d l e = > F o r u m P r o d u c t B u n d l e = > G e s t i o n d e p r o d u i t s S t o r e B u n d l e = > E - C o m m e r c e
  28. BUNDLES & COMPONENTS/LIBRAIRIES Idéalement, vos bundles ne doivent être que

    le lien entre Symfony2 et votre logique métier. Cette logique métier doit être indépendante. Inspirez vous du découplage entre Bundles et Components de Symfony2.
  29. BUNDLES & COMPONENTS/LIBRAIRIES Symfony\Bundle\FrameworkBundle\DependencyInjection Symfony\Component\DependencyInjection Symfony\Bundle\FrameworkBundle\Validator Symfony\Component\Validator Symfony\Bundle\FrameworkBundle\HttpKernel Symfony\Component\HttpKernel Symfony\Bundle\TwigBundle

    \Twig
  30. ROUTING Aucune route ne doit être déclarée dans a p

    p / c o n f i g / r o u t i n g . y m l . Ce fichier doit uniquement contenir des imports, les déclarations des routes doivent se trouver dans le même bundle que le controlleur associé à cette route.
  31. TEMPLATING Suivez les conseils de Grégoire Pineau ;)

  32. I18N Internationalisez dès le début L'internationalisation après coup est bien

    plus longue et complexe.
  33. CONTROLLEURS

  34. FORMS Après le traitement avec succès en POST, vous devez

    toujours rediriger l'utilisateur : sécurité ergonomie évite la duplication
  35. ORM Les queries doivent être créées dans des classes dédiées

    (Repository, Peer), pas dans les controlleurs.
  36. INCONTOURNABLE Aucun code métier dans les controlleurs. Ils doivent récupérer

    les services (ou instancier les objets métier) et les appeler puis passer le résultat à la vue. C'est tout!
  37. LONGUEUR Max 20 lignes par action Au dessus, cela signifie

    souvent qu'ils contiennent de la logique métier. Pas plus de 10 actions par controlleurs Au dessus, ça devient inmaintenable.
  38. LONGUEUR Les annotations peuvent vous permettre de garder vos controlleurs

    légers et sans fioritures. Elles vous permettent également de centraliser l'information et de rassembler une déclaration de route avec l'action associée.
  39. MODÈLE

  40. "UTILS" Ne créez pas de classes "utilitaires" remplies de méthodes

    statiques.
  41. FORMS Ecrivez vos formulaires dans des form types. Réutilisablité N'alourdit

    pas les controlleurs Organisation plus "propre"
  42. FORMS Déclarez ces types en services.

  43. FORMS Si vos form types ont des dépendances, injectez les

    par le constructeur, pas par les options.
  44. SESSIONS La logique de persistance en session doit se trouver

    dans un service avec la session injectée. Pas dans les controlleurs.
  45. SESSIONS Minimisez la quantité de données en session.

  46. LOGGING La configuration par défaut de monolog n'écrira les logs

    de débug qu'en cas d'erreur. N'hésitez donc pas à logger.
  47. ORM Utilisez vos entités pour le stockage d'informations. Utilisez des

    classes métiers dédiées pour les manipuler. "Treat your entities like princesses". Facilite les TU, le refactoring et le découpage bundles/components.
  48. DIC

  49. DIC Le DIC est sans doute l'outil le plus puissant

    de Symfony2. C'est lui qui apporte toute sa flexibilité à Symfony2. Lisez, apprenez, testez!
  50. DIC Utilisez la configuration XML dans vos bundles.

  51. DIC N'injectez pas le container. Injectez uniquement les dépendances nécessaires.

  52. DIC Ne mettez pas de chemin en dur. Vous pouvez

    utiliser % k e r n e l . r o o t _ d i r % ou déterminer les chemins au moment de la compilation du DIC.
  53. VUE

  54. UTILISEZ TWIG Il vous contraindra à respecter le MVC

  55. UTILISEZ TWIG Intuitif Performant Puissant Sécurisé (Autoescaping)

  56. ASSETS Utilisez Assetic

  57. EXTENSIBILITÉ / MAINTENABILITÉ

  58. BUNDLES Vous ne devez pas avoir d'import de configuration des

    bundles dans a p p / c o n f i g / c o n f i g . y m l . C'est l'extension DI du bundle qui doit s'en charger.
  59. BUNDLES Utilisez la configuration sémantique # a p p /

    c o n f i g / c o n f i g . y m l m y _ b u n d l e : f o o : b a r m y _ f e a t _ i s _ e n a b l e d : t r u e f e a t _ c o n f i g : l o r e m : i p s u m
  60. BUNDLES Validez cette configuration vous permet: de modulariser (charger si

    nécessaire) vos services. de vous assurer que la configuration est correcte au moment du warmup... et d'afficher des messages clairs au développeur en cas d'erreur.
  61. COMMANDES Ecrivez des commandes pour vos batches et tâches répétitives.

  62. TESTS Testez unitairement et fonctionnellement!

  63. PROD

  64. FRONT CONTROLLER Ne déployez pas w e b / a

    p p _ d e v . p h p Pour être plus précis, le seul front controller à déployer est w e b / a p p . p h p
  65. FORMS Surtout ne désactivez pas le CSRF.

  66. FORMS Changez la clef s e c r e t

    du p a r a m e t e r s . y m l !
  67. FORMS Rappelez vous, "Vos mots de passe sont confidentiels!". Le

    s e c r e t l'est également! (D'où son nom)
  68. FORMS Encore mieux, utilisez en plus l'option i n t

    e n t i o n dans vos formulaires. Cela rendra le token unique pour chaque type de formulaire.
  69. DOCTRINE Activez les caches Doctrine (metadata et query). Aucune incidence

    sur le fonctionnement, juste sur les perfs.
  70. PERSONNALISEZ VOS PAGES D'ERREURS C'est plus classe Évite de reconnaître

    la page d'erreur par défaut
  71. LOGS La configuration de monolog est très bien pour la

    prod. N'activez pas le log de toutes les requêtes!
  72. CACHE Cacher les pages est simple avec Symfony2. Ne générez

    pas deux fois le même contenu, mettez en cache.
  73. PHP Utilisez PHP 5.4. Vous gagnerez en performance et en

    consommation mémoire.
  74. PHP Installez et activez APC. Vous gagnerez en performance. (Ne

    sera normalement plus nécessaire avec PHP 5.5 ;) )
  75. POUR FINIR

  76. None
  77. N'oubliez pas que Symfony2 est un Framework PHP Objet

  78. Ne vous demandez donc pas "Comment faire ceci en Symfony2",

    mais demandez vous "Comment faire ceci en PHP Objet".
  79. Respectez les bonnes pratiques PHP. Respectez les bonnes pratiques de

    la POO.
  80. Pas de références Pas de globals Pas de short tags

    Type Hinting UTF-8 PSR-x ...
  81. ainsi que celles du CSS, HTML, JavaScript, Twig, etc ...

  82. en bref, respectez également les bonnes pratiques de tous les

    autres outils que vous utilisez.
  83. mais également celles du web, de la gestion de projet,

    du développement en général.
  84. QUESTIONS ?

  85. MERCI À TOUS