La présentation

J’ai complètement changé d’axe d’approche entre l’appel à proposition de Paris Web et le jour venu. J’ai retourné le sujet dans tous les sens pour arriver à transmettre le message de la manière la plus adaptée qu’il soit au public. Parce qu’il est vraiment essentiel de comprendre votre auditoire.

De ce fait, j’ai préféré laisser tomber l’atelier magistral où j’aurais été le seul à partager. L’approche choisie fût celle de l’interaction design (IxD) ; notion découverte la veille pendant la conférence de Stéphanie Troeth. L’idée étant de construire ensemble le corps de l’atelier, de produire ensemble la réflexion et d’en arriver à des conclusions plus rapidement.

Le plus amusant fût qu’on arrivait aux mêmes conclusions, et que les slides suivant la phase de design répondaient aux questions nouvellement créées.

Pour l’expérience, et le résultat produit, j’en suis satisfait

Déroulement de l’atelier

L’atelier consistait à passer en revue 3 des étapes du développement frontend : l’intégration HTML, l’habillage CSS et les interactions JavaScript. Chaque étape se divisait en 4 composants de travail :

• Production / réalisation
• Organisation / équipe
• Documentation
• Tests

Pour chacun de ces composants, toute personne dans la salle pouvait suggérer une bonne pratique, une mauvaise pratique ou un outil. Cela s’est matérialisé avec un tableau blanc découpé en 4 zones, dans lesquelles on collait des post-it.

Pour la petite histoire, n’ayant pas pensé à acheter les post-il avant d’arriver à Paris, je me suis rabattu sur le premier choix venu, en me basant sur la connaissance du terrain de David Larlet : Loisirs & Créations du Bercy Village.

C’est ainsi que je me retrouvais avec 200 post-it en forme de cœur,  de maison ou de fleur.

Un peu de gaieté pour un atelier sérieux et créatif.
D’ailleurs, parce qu’on n’a pas bossé pour rien, et que Paris Web c’est aussi la création en plus de share the love, voici la carte mentale de notre heure de travail :

Constats

Mon premier constat, en regardant la carte mentale, c’est qu’on a quand même réussi à produire un bon nombre d’éléments en 1 heure, avec un public qui n’était pas préparé et dans une configuration de salle de classe, remplie de surcroît.
La logistique s’est organisée d’elle-même, avec des contributions diverses pour ramasser les post-it, leur circulation et même la modération.

Quant au contenu en lui-même, plusieurs remarques s’imposent :

• la très grande majorité des contributions concernaient la production (c’était flagrant, face au tableau)
• par extension, il y a peu d’éléments de documentation et de tests et dans une moindre mesure, peu de travail en équipe/organisationnel (à part les classiques versionning)
• en production de CSS et de JavaScript, le nombre de mauvaises pratique équivaut ou dépasse les bonnes pratiques

En une phrase et une seule : le développement frontend, en tous cas représentatif de la population présente dans la salle, travaille dans son coin, avec ses méthodes, peu adaptables à d’autres cadres.

Et la suite ?

Mon avis c’est que si la production n’est pas forcément industrialisable au sens où on ne peut que difficilement automatiser la production du code, en revanche on peut automatiser les tests et la documentation, voire certains aspects d’organisation (diffusion automatique des commits, rapports etc.).

Une de mes hypothèses est que si le caractère individuel du travail est si marqué, c’est que nombre des méthodes, astuces et outils de travail sont basés sur des avis subjectifs. Pas étonnant que les réactions sur le mot industrialisation soient si virulentes et chargées d’émotions.

C’est une des raisons pour laquelle j’ai proposé en conclusion d’aller au-delà de nos jugements personnels pour formaliser des bonnes et mauvaises pratiques, que l’on applique ensuite à son projet si l’on est concerné. Un mélange des guidelines BBC et des bonnes pratiques Opquast en somme.

Ce que j’aimerais, c’est produire 2 livrables :

• une checklist de bonnes pratiques de développement frontend
• un livre blanc du développement frontend, comprenant en plus le processus de dialogue entre acteurs, pendant les phases projet

Ces livrables seront Open Source, libres, gratuits et créés collectivement, parce qu’on a tous des terrains d’expertise différents et complémentaires.

Share the love

Je ne manquerai pas de vous tenir informé des avancées de ces projets, qui me tiennent à coeur.
Je ne saurais que trop remercier les participants, présents lors de l’atelier Paris Web, ceux qui apporteront leur pierre à l ‘édifice (même si ça ne concerne qu’un changement de virgule dans une phrase) et ceux qui apporteront leur soutien, Elie Sloïm en tête. Il propose en effet de mettre à disposition la plate-forme Opquast en tant qu’outil de contribution.

Une idée qu’elle est bonne.

Il existe 4 phases dans la vie d’un développeur :

1. celle où il aime tout créer lui-même
2. celle où il aime utiliser un outil déjà tout prêt
3. celle où il aime concevoir son outil avec d’autres outils tout prêt
4. celle où il aime que les autres conçoivent pour lui (mais là il est patron ou armé d’une horde de stagiaires )

Les frameworks font partie de cette troisième catégorie. Ils existent dans à peu près tous les langages : CSS, PHP, JavaScript, Java, C#, Python, Ruby etc.
Mon discours portera sur les frameworks PHP, parce que c’est mon langage de prédilection mais aussi parce qu’un livre blanc sur les frameworks PHP pour l’entreprise est récemment sorti. Il parlera aussi bien aussi bien aux décisionnels qu’aux développeurs, à leur compte ou pour celui d’une entreprise.

De l’intérêt d’utiliser un framework

Un framework est littéralement ce que l’on peut appeler un socle logiciel : il propose des fonctionnalités de base et vous les utilisez pour concevoir votre propre application.

J’essaierai de faire court en énumérant une liste de quelques points à faire valoir dans l’utilisation d’un framework pour concevoir une application Web :

• développement accéléré
• convention over configuration : suivez les rails des conventions plutôt que de tout paramétrer
• DRY : écrivez le code une fois et réutilisez-le pour éviter le copier-coller (sans parler des gains de maintenabilité)
• mutualisation du code : un même socle pour plusieurs applications
• concentration du développement sur le code métier
• le framework vous décharge des tâches pénibles : sécurité, gestion des URL, gestion des permissions utilisateur, manipulation des bases de données, gestion du cache, accès aux fichiers etc.
• génération automatique d’interfaces (admin generator), de base de données (ORM), de modules/applications (scaffolding) etc.
• vecteur d’apprentissage individuel et collectif
• bénéfices de tout le travail d’une communauté … et de celui que vous réinjecterez

A contrario, on pourra critiquer les frameworks pour leur plus forte consommation en ressources qu’un développement maison.
Ce n’est évidemment pas une raison valable pour passer à côté d’autant plus qu’il existe de nombreuses solutions pour palier/réduire ce problème avec les gestionnaires de cache et les accélérateurs de code.

Framework PHP ou CMS ?

Maintenant vous me direz : pourquoi développer un logiciel avec un framework au lieu d’utiliser un bon CMS des familles ou tout autre logiciel faisant son office ?
Ce n’est à mon sens pas la bonne question à se poser : un framework n’est pas une fin en soi. Le choix du logiciel dépendra essentiellement du besoin, immédiat et futur. Vous aurez beau avoir le meilleur développeur d’un CMS de votre pays, si le choix de la solution technique est déjà erroné, il ne suffira pas à éviter la catastrophe.

J’ai beaucoup accroché à cette formule le jour où je l’ai entendu : si vous estimez à au moins 50% l’utilisation de spécifiques dans une solution logicielle existante de type CMS, vous faites fausse route. Le spécifique EST votre solution, le CMS devient une simple fonctionnalité.
Dans le cas d’un développement spécifique, le choix d’un framework est dans ce cas naturellement prescrit.

Dans tous les cas, ce sont vos besoins qui doivent vous guider vers le choix d’une solution et non l’inverse. Ne partez pas surtout d’une solution pour tenter d’y combler vos besoins.

Les principaux frameworks PHP

Le livre blanc sur les frameworks PHP expose en détail les frameworks majeurs en PHP avec leurs avantages, inconvénients et surtout une grille comparative permettant de mettre à bout à bout leurs différentes fonctionnalités.

Toutefois on peut retenir ces noms de frameworks PHP :

• CakePHP
• CodeIgniter
• EZ Components
• PEAR
• symfony
• Zend Framework

On pourrait classer ces frameworks en 2 catégories :

• les briques logicielles : ils se présentent comme des briques indépendantes qu’on peut utiliser à souhait dans n’importe quel projet, y compris d’autres frameworks. C’est notamment le cas de PEAR, EZ Components et Zend Framework ;
• les frameworks à proprement parler : ils imposent une structure particulière et des lignes directrices de développement pour être plus efficace. On citera dans ce cas symfony, CodeIgniter et CakePHP

symfony : champion toutes catégories

Lors de la lecture du livre blanc sur les frameworks PHP, vous remarquerez très probablement que le framework symfony a tout pour plaire. C’est en effet à l’heure où j’écris ces lignes le framework PHP le plus abouti et le plus intéressant à analyser.
Il jouit d’une excellente réputation, d’une incroyable stabilité et d’une communauté très active, quantitativement et qualitativement parlant. Si on ne devait en garder qu’un, ça serait lui.

Pourquoi j’apprécie énormément symfony :

• une documentation fonctionnelle et une documentation de l’API complètes
• utilisation intensive de fichiers YAML pour le paramétrage
• les fonctionnalités d’amin generator, de gestion de base de données avec l’ORM Propel et les outils d’automatisation qui en découlent
• facilité d’intégration d’Ajax sans pondre une seule ligne de JavaScript
• grand confort de développement
• des conventions inspirées des plus grands (Ruby on Rails, Django etc.)

Conclusion

Développeurs : renseignez-vous et intéressez-vous à au moins un framework. C’est bien pour le CV et vous gagnerez du temps.
Décideurs : exigez de savoir quelle solution on vous préconise et surtout, pourquoi celle-là. À plus forte raison si votre projet comporte beaucoup de besoins spécifiques, demandez s’il s’agit d’un framework et si ce n’est pas le cas, pourquoi ça n’a pas été envisagé. Vous gagnerez aussi du temps et j’espère de l’argent.

Les frameworks sont aujourd’hui partout et ont acquis une certaine maturité. Ces lettres de noblesse les rendent utilisables aussi bien pour des petits besoins que ceux d’entreprises, peu importe leur taille. Les gains de temps et l’incitation à la production de qualité sont des facteurs non-négligeables pour la pérennité de vos applications.

Attention toutefois : un mauvais développeur et/ou une mauvaise conception prédomineront toujours. Votre fromage industriel aura toujours le même goût, peu importe la qualité du pain

Je radote mais j’espère que vous trouverez suffisamment d’informations pour vous convaincre dans le livre blanc des frameworks PHP pour l’entreprise. C’est ce genre de publications qui me font aimer la société dans laquelle je travaille