Atelier / débat bonnes pratiques sur l’architecture

Aujourd’hui a eu lieu un atelier / débat sur les bonnes pratiques. Un atelier / débat, c’est une sorte de réunion technique, mais où chacun est invité à exposer son opinion sur ce qui se dit pendant la réunion technique, un sorte de brainstorming géant. Le sujet des bonnes pratiques s’y prêtait bien, et malgré les peurs de certains, aucun lancé de troll malencontreux n’est à déplorer :-)

Expérience enrichissante pour tout le monde, que nous ne manqueront pas de réitérer !

 

Bonnes pratiques de développement PMSIpilot

Les slides de notre première réunion technique 2010, ce fut une bonne occasion de débattre de nos (bonnes et autres) pratiques PMSIpilot.

Merci à Eric Lemoine pour sa démo sur XHProf : l’intégration à la debug bar SF et la comparaison de runs va nous permettre d’être efficaces lors de nos profilings !

 

Introduction au Mob Programming chez PMSIPilot

Le Mob Programming est une technique de travail qui propose de développer une feature en équipe à la manière d’un pair-programming démultiplié !

Concrètement toute l’équipe se retrouve autour d’un PC avec vidéo-projecteur et chacun a tour de rôle sera chargé de coder en étant guidé par les réflexions de l’équipe.

Ainsi l’ensemble des avis peuvent être entendus et débattus au fur et a mesure que la feature prend forme (validation d’un pattern, d’une librairie , d’une interface, …).
On évite donc les allers-retours autour d’un développement et les risques d’effets tunnels.

… 

 

Les pmsiAteliers

Hier chez PMSIpilot, nous avons testé une nouvelle manière de ventiler les connaissances. A l’initiative de William (@wooshell) et Marion (@titeiko), des ateliers techniques directement présentés sur les postes des animateurs ont eu lieu. Les membres de l’équipe technique étaient libres de circuler entre chaque atelier afin de recueillir les informations qui les intéressaient.

Les thèmes abordés étaient les suivants :

Less – http://lesscss.org/
Pierre Yves (@pym) a présenté Less : un système dynamisant le css, qui introduit des variables, des fonctions et d’autres comportements normalement réservés aux langages de programmations.

les tests unitaires et Propel – http://www.propelorm.org/
Frédéric (@mageekguy) a présenté la façon de faire des tests en utilisant des mocks d’objets Propel pour enlever la dépendance à la base de données.

QUnit et testswarm – https://github.com/jeresig/testswarm
Gabriel (@gabrielpillet) a présenté Qunit un framework de tests unitaires pour le javascript et testswarm un outil d’intégration continue pour ces tests.

Vim – http://www.vim.org/
Geoffrey (@ubermuda) a présenté une initiation à Vim, un éditeur de texte en ligne de commandes.

Pflow
Marion (@titeiko) a présenté un outil interne s’interfaçant entre git (http://git-scm.com/), notre système de versionning, et redmine (http://www.redmine.org/), notre gestionnaire de tickets.

Les premiers retours de l’équipe technique sont positifs, et nous pensons mensualiser ces #pmsiAteliers. Ce système, plus dynamique que nos précédentes réunions techniques, permet de présenter plus de sujets, tout en suscitant un intérêt soutenu des participants durant une heure et demi. Pour nos futures itérations la durée sera rallongée.

 

Symfony chez PMSIpilot

PMSIpilot conçoit et réalise une suite informatique dédiée à l’amélioration de la gouvernance des hopitaux publics. Le périmètre fonctionnel peut s’apparenter à un outil décisionnel ou de Business Intelligence concernant l’activité, d’un point de vue financier et médical, de l’hôpital.

Il y a deux ans, le projet a connu un virage technologique important. D’une technologie obsolète et d’un conception un peu hasardeuse (PHP4, framesets, …), un projet de refonte vers symfony 1.2 a été lancé. Cette refonte a durée un peu plus de 20 mois / homme et a abouti à un seul projet symfony contenant plusieurs applications. PMSIpilot a, dès le début, pris le parti d’utiliser les conventions de symfony et le paradigme MVC.

En chiffres, aujourd’hui

  • 12 développeurs (en constante augmentation !),
  • 410 déploiements,
  • environ 50 000 utilisateurs répartis sur toutes ces instances,
  • environ 220 000 lignes de code PHP écrites et maintenues,
  • la prochaine release importante intégrera symfony 1.4.

lines of code

Comment symfony nous aide

La documentation et la communauté

La documentation de symfony nous permet d’intégrer rapidement une nouvelle recrue. Le fait de trouver de nombreuses contributions au framework (sur symfony-project.org ou bien ailleurs) est très facilitant également. Nous utilisons de nombreux plugins comme :

  • sfPropelPlugin
  • dwJpGraphPlugin
  • sfDB4toPropelPlugin
  • sfPropelSqlDiffPlugin
  • sfJqueryReloadedPlugin
  • sfValidatorHtmlPlugin
  • sfJobQueuePlugin
  • sfFormExtraPlugin

Parfois tels quels, parfois un peu modifiés pour nos besoins.

Le développement

  • le framework nous donne une bonne structure de base pour l’organisation du code source ainsi que des normes de codage, sur une équipe aussi importante cela permet de gagner du temps,
  • mis à part i18n et l’admin générator, on utilise la quasi totalité de la stack de symfony : MVC, le cache, les filtres, les évènements, le système de gestion des utilisateur, l’ORM, les tasks, …
  • symfony est suffisament flexible pour que nous puissions facilement l’adapter à nos besoins parfois bien spécifiques ; aujourd’hui nous avons étendu : sessionStorage, viewCacheManager, ApplicationConfiguration et ProjectConfiguration, sfAction, sfComponent, sfView, frontWebController, plein de choses autour de propel …
  • nous ajoutons des fonctionnalités tous les jours, et une grande réactivité nous est demandé pour suivre l’évolution de la réglementation ; le framework de test nous permet de garantir aucune régression et de livrer des correctifs très rapidement si nécessaire (voir plus bas),
  • le système de task, de gestions des fixtures, d’environnement de développement permet de proposer des méthodes faciles d’accès au développeur permettant d’instancier un environnement de dev complet et identique à ses collègues.

L’intégration continue

Dès la refonte du projet, sécuriser ces mises à jours a été une priorité. C’est pourquoi nous avons investi dans le développements d’un grand nombre de tests fonctionnels et leur suivi au sein d’une instance Hudson.
Hudson
Les tests fonctionnels chez PMSIpilot vérifient des cas d’utilisation standards mais sont surtout utilisés pour valider la totalité des données chiffrées présentées. A ce titre les quelques 250 000 tests fonctionnels sont majoritairement générés (on ne teste pas vraiment « les tests » mais « les étalons des tests »).

La création de nouvelles classes a entrainé l’écriture d’une centaine de tests unitaires (avec des efforts pour optimiser la couverture du code).

emma code coverage

Enfin, nous avons commencé l’écriture de tests d’interface avec Selenium (une dizaine aujourd’hui) afin de gérer plus facilement les différents navigateurs (parfois un peu datés) de nos clients. (oui, ça n’a rien à voir avec symfony …)

navigateurs

tests selenium

Pour boucler la boucle on a, en projet, l’intégration automatique de tests de montée en charge. (un outil à suggérer ?)

Comment nous tentons d’aider symfony

Dans la mesure du possible, nous tentons de faire bénéficier la communauté symfony de nos travaux, en remontant des bugs et en proposant des plugins . Nous essayons également de partager les slides des réunions techniques organisées au sein de l’équipe afin de diffuser les compétences au sein des équipes.

Chez PMSIpilot, on aime symfony. Si c’est votre cas aussi, n’hésitez pas à proposer votre candidature au service technique.