[:fr]La parole est aux speakers : Julien Janvier[:]

Publié le

[:fr]Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

L’art subtil du nommage

C’est bien connu, dans le développement logiciel, il n’y a que deux choses difficiles : l’invalidation de cache, et le nommage. Côté cache je ne peux malheureusement rien pour vous. En revanche, en ce qui concerne le nommage de nos chères variables, méthodes et classes, il est légitime de se poser quelques questions. Pourquoi est-ce si compliqué ? Y-a-t-il des pièges à éviter ? Existe-t-il des règles ou des méthodes qui pourraient nous aider ? Dans cette brève présentation, je vous propose d’explorer quelques pistes afin de tenter de répondre à ces interrogations.

Peux-tu nous parler un peu de ta contribution à Sylius ? Quel est ce projet et quelle a été ta contribution ?

Sylius est une solution e-commerce écrite en PHP et basée sur le framework Symfony. C’est à la fois une solution clef en main et un ensemble de librairies réutilisables facilitant la création de sa propre boutique sur mesure.
J’y ai participé activement en 2013 et 2014 en suivant le parcours classique d’un contributeur open-source qui veut s’impliquer dans un projet : rapport de bugs, traduction, correction de bugs, lecture assidue du code, propositions et écriture de nouvelles fonctionnalités et revues de code des autres contributeurs.

Cette expérience a été formatrice et enrichissante. A cette époque, je stagnais en tant que développeur. Ce que je faisais sur mon temps de travail ne me correspondait plus et j’avais envie d’améliorer mes compétences. Sylius m’a permis de découvrir ou de mettre en pratique les notions de SOLID, de découplage, de BDD ainsi que des outils comme Git, Behat ou encore PhpSpec. En 6 mois de contribution à Sylius, j’ai eu la sensation d’apprendre plus qu’en 3 ou 4 ans de vie professionnelle.

Même si aujourd’hui je ne contribue plus à ce projet, je continue de suivre son évolution. Je suis admiratif de ce qu’à réussi à construire Paweł et suis reconnaissant de ce projet. La récente sortie de la version 1.0 est une super nouvelle. Je profite de ce billet pour dire un grand bravo à l’équipe et à tous les contributeurs.

Travailler sur un projet open-source commercial à grande échelle comme Akeneo, comment ça se passe ?

Akeneo est un logiciel de gestion d’information produits. Nous avons deux éditions : une édition Communautaire open-source et une édition Entreprise payante.

Nous sommes moins “drivés” par la communauté que peuvent l’être Sylius ou encore Symfony, qui s’adressent aujourd’hui à un large public de développeurs. Et ceci pour deux raisons.

La première est le fait que nous sommes un éditeur logiciel dont le modèle commercial repose sur la vente de licences Entreprise. Contrairement à SensioLabs par exemple, qui gagne de l’argent autour de Symfony à travers du consulting, de la formation, du service et de super outils. Pour cela, nous nous basons sur l‘édition Communautaire. Plus elle est utilisée, plus d’utilisateurs satisfaits souhaitent passer sur la version Entreprise qui contient des fonctionnalités avancées, et plus d’extensions open-source sont publiées sur notre marketplace. Plus de licences Entreprise sont vendues, plus nous pouvons faire grossir l’équipe produit. Plus nous avons une équipe fournie et de qualité, plus nous avons de monde pour développer la version Communautaire. Bref, un cercle vertueux s’instaure. Le produit s’améliore et s’étoffe “de l’intérieur”, là où les autres projets open-source s’appuyent plus fortement sur une communauté de développeurs partiellement ou complètement bénévoles.
La seconde raison est que notre produit s’occupe d’un domaine métier très spécifique et vise à faciliter la vie des équipes marketing. L’outil s’adresse donc à un public ciblé et demande des connaissances métier fortes. Cela influe sur le nombre de contributions et leur nature. Même si nous avons donc moins de contributions que Sylius, Symfony ou les librairies PHP League par exemple, nous en avons tout de même, et de plus en plus. Nous avons beaucoup de contributions sur la traduction du logiciel et sur la mise à disposition d’extensions. Les contributions sur le cœur du produit viennent pour la plupart d’intégrateurs de la solution, et concernent quasi exclusivement des corrections de bugs. Le nombre de contributions est d’ailleurs un indicateur que nous suivons régulièrement, puisqu’il témoigne de le bonne diffusion de notre produit.
Le plus fascinant à mon sens, à travailler sur un projet open-source commercial qui est bien adopté, est de prendre du recul sur l’évolution de notre fonctionnement et de constater la vérification de la loi de Conway.

En 2013, le produit était développé par une équipe de 4 ou 5 développeurs. Nous avions un regard très technique sur les fonctionnalités et nous étions pressés par le temps afin de sortir la première version. Au quotidien, nous faisions du SCRUM, du moins dans les grandes lignes. L’équipe a énormément grossi, et notre organisation a de nombreuses fois changé. Aujourd’hui, l’équipe produit est constituée d’environ 35 personnes regroupant des développeurs bien sûr, mais aussi des Product Owners, des UX Designers, des DevOps et le Support. Nous travaillons également en collaboration avec les équipes marketing, ventes et pré-ventes ce qui n’était pas le cas auparavant puisque ces équipes n’existaient pas. Nous sommes organisés en équipes pluridisciplinaires de 5 à 7 personnes. Chaque équipe est responsable d’un sujet fonctionnel. Elle doit, de manière autonome, définir, prioriser, développer et tester les fonctionnalités qui répondent au mieux au cahier des charges qui lui a été donné. La seule règle immuable est de toujours penser à l’utilisateur final. La différence de qualité entre la version 1.0 et la version 2.0 d’Akeneo est flagrante; que ce soit du point de vue du code, de l’ergonomie, de la simplicité d’utilisation ou de l’adéquation aux besoins de nos utilisateurs. Elle est le reflet d’un changement d’organisation et de communication de l’équipe produit.

Tu étais orateur au PHP Tour à Nantes, que retires-tu de ton passage là-bas ?

Avant d’être orateur, j’étais tout d’abord participant. Et à ce titre, le PHP Tour était une excellente conférence ! Avec des sujets variés, intéressants, de qualité et de très bons speakers. La conférence était bien organisée et l’ambiance était conviviale et bon enfant.

En dehors de meetups locaux, le PHP Tour était ma première conférence en tant qu’orateur. Il y avait un peu de stress car je ne savais pas comment mon sujet serait reçu. En tout cas, ça vaut le coup de se jeter à l’eau. Cela donne l’occasion d’approfondir un domaine qui nous intéresse tout en échangeant son point de vue avec les autres. Je conseille à tout le monde d’essayer 🙂

Une conférence présentée par

Julien JANVIER
Julien JANVIER 		Développeur chez Akeneo, Julien est un amoureux de l'open source et du code depuis plus de 10 ans. Apprendre, partager et construire sont ses maître-mots.

Autres interviews

[:]

Categories: Forum PHP 2017
Tags:

Related Posts

Forum PHP 2017

[:fr]La parole est aux speakers : Nicolas Lœuillet[:]

[:fr]Jusqu’au PHP Tour 2018, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence ! Peux-tu nous présenter le projet wallabag et quel est ton rôle Read more…

Forum PHP 2017

[:fr]Retour de Kevin Nadin sur le programme d’accompagnement des speakers[:]

[:fr]L’AFUP est toujours à la recherche de nouveaux visages et de nouveaux profils pour la programmation de ses événements. Dans cette optique, un programme de mentoring est mis en oeuvre : un conférencier expérimenté accompagne Read more…

Forum PHP 2017

[:fr]La parole est aux speakers : François Zaninotto[:]

[:fr]Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence ! Qu’est qui t’a motivé à proposer ce sujet ? Dans ma Read more…