• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Reunion Technique PMSIpilot - Janvier 2010
 

Reunion Technique PMSIpilot - Janvier 2010

on

  • 1,893 views

Bonnes pratiques de développement

Bonnes pratiques de développement

Statistics

Views

Total Views
1,893
Views on SlideShare
1,544
Embed Views
349

Actions

Likes
0
Downloads
9
Comments
0

4 Embeds 349

http://www.pmsipilot.org 345
http://www.slideshare.net 2
http://webcache.googleusercontent.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Reunion Technique PMSIpilot - Janvier 2010 Reunion Technique PMSIpilot - Janvier 2010 Presentation Transcript

    • Réunion technique 13/01/09 Bonnes pratiques de développement
    • Plan Recommandations de codage – PHP Ne pas modifier Symfony Gestion des actions Routing SF Dépendances Refactoring Fichiers Gestion des plugins Javascript - CSS Débogage (+ Profiling) Etapes d'un développement Réunion technique 01/15/10 2
    • Best pratices (once again !?) Sont mouvantes Sont empiriques (= subjectives) Doivent nous servir et nous rassurer Réunion technique 01/15/10 3
    • Recommandations de codage - PHP Standard de codage PMSIpilot Indenter avec 2 espaces Ecrire les accolades sur des nouvelles lignes Respecter les règles de nommage SF Pour une classe, le nom de fichier se termine par .class.php Pour une task, le nom de fichier se termine par Task.class.php Si possible, ne pas fermer les tags PHP – Zend Programmer's Reference Guide : Ne pas l'inclure permet de se prémunir des problèmes liés à l'injection accidentelle d'espaces blancs dans la sortie. Réunion technique 01/15/10 4
    • Recommandations de codage - PHP Standard de codage PMSIpilot Préfixer les noms des classes maison par « pmsipilot » Logguer les erreurs Log::add() Déclencher des pmsipilotException plutôt que des sfException Utiliser les pre et post Execute sur les composants Ne pas utiliser l'autoformatting de votre éditeur Placer des @FIXME et @TODO (mode goret only) Etc cf. http://trac.symfony- project.org/wiki/HowToContributeToSymfony#CodingStand ards Réunion technique 01/15/10 5
    • Recommandations de codage - PHP Une variable doit être obligatoirement initialisée Même si PHP sette les variables non initialisées à null Réunion technique 01/15/10 6
    • Recommandations de codage - PHP Préférer sprintf à l'opérateur '.' pour concaténer Utiliser la méthode sprintf Plus lisible Permet le formatage (remplisseur, type, etc) N'émet pas d'erreur en cas de variable inexistante Au besoin, se servir de la syntaxe Heredoc Réunion technique 01/15/10 7
    • Recommandations de codage - PHP Rendre ses méthodes paramétrables Pour éviter d'avoir des paramètres facultatifs nuisibles lors des appels Mettre, en dernier paramètre de fonction, un tableau paramétrable à souhait Réunion technique 01/15/10 8
    • Ne pas modifier Symfony Même si la modification apporte un gain ! Buts : obtenir impérativement le comportement attendu de SF upgrader SF sans problèmes Modifier le core SF Etendre SF surcharge factories.yml ... Réunion technique 01/15/10 Voire ponctuellement Forker SF 9
    • Ne pas modifier Symfony Etendre SF : exemple de pmsipilotUser Mettre dans pmsipilotUser ce qui est commun à toutes les applis Coder dans myUser ce qui est spécifique à une application Réunion technique 01/15/10 10
    • Gestion des actions En début d'action, vérifier systématiquement les paramètres obligatoires Réunion technique 01/15/10 11
    • Gestion des actions Faites des redirect au lieu de forward Pour éviter de casser la navigation Pour éviter le re-post du formulaire si rechargement de la page Réunion technique 01/15/10 http://www.symfony-project.org/forms/1_2/fr/02-Form-Validation 12
    • (Gestion des actions) Casser le MVC Réunion technique 01/15/10 13
    • Routing SF Nous utilisons peu les routes Modules très rigides : à cause de références permanentes aux noms des modules et des actions URLs peu sexy Réunion technique 01/15/10 14
    • Dépendances Doivent nous obséder car spécialisation forte du code unit testing compromis Au minimum, les référencer Au mieux, les éviter ou les casser Dans l'idéal, les gérer injection de dépendances en PHP http://fabien.potencier.org/article/15/symfony-service-container Réunion technique 01/15/10 15
    • Dépendances - exemple 2010 : 1 appel à sfContext::getInstance() = 2 points boulet ? utiliser pmsipilotContext en dehors d'un contexte SF devient pénible utiliser pmsipilotContext dans différents contextes SF devient hasardeux Réunion technique 01/15/10 16
    • Dépendances - exemple Si inutile, éviter de passer des objets à un constructeur ou à un setter Réunion technique 01/15/10 17
    • Refactoring Eviter les classes qui ne contiennent que des méthodes statiques et fourre tout Eviter les mélanges de concept S'appuyer sur la POO (OMG) Réunion technique 01/15/10 18
    • Refactoring Ranger les librairies aux bons endroits plugins pmsipilotApp*Plugin Conserver la généricité du code Centraliser les modules, les surcharger Différencier les traitements bas niveau relevant du core Réunion technique 01/15/10 19
    • Refactoring Yes we can Jobs d'import Gestion utilisateur Composants PMSIpilot dans Visiopôle Criteria Gestion des menus Page de détails des séjours Message d'accueil Gammes, licences RAF pmsipilot*Action pmsipilot*User Tranches d'ages Réunion technique 01/15/10 Indicateur de synthèse 20
    • Fichiers Tout fichier créé doit être supprimé Ecrivez dans /var/tmp Utiliser pmsipilotUtils::myTempnam pour nommer les fichiers (cf. http://fr.php.net/tempnam) Eviter les accès au disque Un sfFinder dans le bon répertoire Vaut mieux Qu'un sfFinder trop large qui resserre avec un « prune » Réunion technique 01/15/10 21
    • Fichiers Référencer le chemin vers un fichier à partir du répertoire courant Pour ne pas harcoder de path Pour éviter par exemple des soucis lors de déplacement de code Ignorer les lignes vides Réunion technique 01/15/10 22
    • Gestion des plugins N'envisager de nouveaux plugins que s'ils ont des schema.yml Pour ne pas polluer Possibilité de maintenir un schéma DBDesigner par plugin Etre aware De la version du plugin Du placement et nommage des patchs Des dépendances avec d'autres plugins Du référencement des plugins (config/plugins.txt) ... Réunion technique 01/15/10 23
    • Javascript - CSS Tester en dev mais surtout tester en prod En prod, compression JS (pmsipilotCombineFilter) Tester sur FF mais surtout tester sur IE IE foire sur des utilisations particulières de fonctions jQuery jQuery.map() Statut des cases à cocher etc Réunion technique 01/15/10 24
    • Javascript - CSS Eclater les inclusions de js/css par action et par composant Plutôt que tout mettre dans le view.yml de l'application Utiliser la surcharge YAML (javascripts[-*] LOL) Coder des objets javascript Problématique des dépendances valable en JS Réunion technique 01/15/10 25
    • Javascript - CSS Sprites Réunion technique 01/15/10 26
    • Débogage ( + Profiling) Un traitement pédale ? vous incluez des url_for en boucle LOL ? votre task SF se retape un autoloading pour le fun LOL ? le logger Propel éclate votre RAM LOL ? Suivre la web debug toolbar Avant d'optimiser, MESURER Eventuellement, se mettre en prod Tout ce qui arrive en dev n'arrive pas forcément en prod (et vice versa) "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" Réunion technique 01/15/10 Donald Knuth 27
    • Débogage ( + Profiling) Xdebug + kcachegrind Xhprof Installation http://mirror.facebook.net/facebook/xhprof/ http://techportal.ibuildings.com/2009/12/01/profiling-with-xhprof/ Intégration Cf démo ! Réunion technique 01/15/10 28
    • Etapes d'un développement 1. faire un plan 2. écrire les tests possibles 3. penser sécurité 4. penser performance 5. penser simplicité et donc réutilisation 6. coder tout, ne rien tester 7. (optimiser) 8. tester tout, ne rien coder 9. coder 10. tester 11. coder Réunion technique 01/15/10 12. tester IE 6, IE 7, IE 8, FF 29
    • Conclusion Réunion technique 01/15/10 30
    • Merci de votre attention Questions Réunion technique 01/15/10 31