Etre complètement libre d’utiliser sa techno ou langage préféré dans sa boîte. Le rêve ? Et bien dans la pratique, ce n’est pas toujours si simple !
Laïla Atrmouh et Jules Truong sont tous les deux développeurs full-stack pour bureauxapartager.com. Ils nous expliquent pourquoi et comment l’équipe technique a dû faire un tri parmi toutes les technologies utilisées au niveau de leur stack technique.
Un peu d’histoire
Le site Web bureauxapartager.com existe depuis 2012, et est une marketplace de bureaux.
Le but est de permettre à la fois aux professionnels du co-working d’exposer leurs offres ainsi qu’aux non-professionnels de pouvoir réduire leurs loyers en partageant un bureau/un ou plusieurs postes de travail. Nous avons également créé morning-coworking, notre marque d’espaces de co-working, ainsi que Link, un logiciel de gestion d’espaces.
Les technos utilisées
Backend
- PHP 7
- Symfony 2.8, 3.4, 4.1
- ApiPlatform
- Golang
- NodeJS, NextJS
Database
- MySQL
- MongoDB
Messaging
- RabbitMQ
Frontend
- AngularJS
- ReactJS Redux
- VueJS Vuex
Devops
- Kubernetes
- Docker
Hébergement
- Google Cloud Platform
Testing
- PhpUnit
- Behat
- Cucumber
- Jest
Bureaux A Partager en quelques chiffres
- Le site Web bureauxapartager.com
- 2223 offres de bureaux en ligne
- 1697 offres de salle de réunion en ligne
- 1000 utilisateurs uniques par jour
- Link
- 200 clients (1 client = 1 espace de coworking)
- 12 devs , pour une équipe produit/tech de 18
- Méthodologie Agile
- Sprint de 15 jours
- 2 mises en prod par semaine
- Environ 100 commits par semaine
- 30 repositories Github
2013 – 2017 : Une grande liberté dans le choix des technos et langages
A l’origine, bureauxapartager.com est développé avec Symfony 1.4. Quant à notre application Link, elle est codée en Symfony 2 et AngularJS, et une API NodeJS pour la partie service d’évènements.
Plus tard, en 2017, une refonte du site bureauxapartager.com nous conduit à utiliser Symfony 3 et VueJS. Puis peu de temps après, Golang au niveau du nouveau service d’évènements, afin qu’il puisse être utilisé à la fois sur bureauxapartager.com et Link.
De façon générale, nous pensons qu’il est très important pour un développeur d’être assez libre dans ses choix de technos. Cela permet constamment d’entretenir l’envie d’apprendre et de découvrir de nouvelles façons de travailler.
Grâce à cette approche et cette liberté, notre culture technique des différents concepts web s’est enrichie au contact des différents langages et frameworks utilisés : nous avons eu l’occasion d’appréhender le protocole AMQP en mettant en place RabbitMQ sur bureauxapartager.com, nous nous sommes améliorés en tests automatisés en mettant en place PHPUnit, Behat ainsi que des tests End-to-End (pour tester une fonctionnalité touchant plusieurs briques applicatives de bout en bout).
Au final, cet environnement est bénéfique pour toute l’équipe : il nous permet de tester de nouvelles technos qui nous plaisent, et de rester très motivés en temps et en rigueur.
Crédit photo “Welcome to the Jungle”
2017 : Quand la dispersion devient un frein
Cette liberté sur plusieurs années nous a conduit à avoir des briques applicatives aux technos différentes. Sur l’écosystème de bureauxapartager.com par exemple, nous nous retrouvons avec :
- 3 applications Golang,
- ainsi que d’une application NodeJS,
- puis d’une application VueJS,
- 1 autre en ReactJS,
- et enfin une application Symfony qui intègre un peu de Vue !
Notre stack technique est donc diversifiée mais également complexe à appréhender. Avoir une telle stack nous amène à apprendre constamment, mais sans jamais vraiment maîtriser à 100% une technologie particulière.
Par exemple, le langage de programmation Golang est initialement maîtrisé par une seule personne de l’équipe, créant ainsi une dépendance forte. Cela induit forcément des délais de production plus long quand quelqu’un d’autre développe sur ce langage. Et comme beaucoup trop de technos et d’outils sont présents, nous n’avons pas le temps de monter suffisamment en compétence sur chacun.
Côté recrutement, il devient également compliqué de trouver des profils maîtrisant toutes les technologies de notre stack.
Lorsque l’équipe était petite (2-3 personnes), chacun pouvait décider de la techno sur laquelle il souhaitait partir. Avec une équipe grandissante et aujourd’hui à 12, c’est une autre histoire !
Il donc temps de discuter des choix technos qui ont été fait et de revoir notre stack !
Décembre 2018 : Faire un choix
Faire appel à un consultant externe
La discussion du choix de technos à privilégier génère des tensions au sein de l’équipe. Historiquement, il n’y a pas de CTO, donc nous prenons les décisions de manière consensuelle, et il devient de plus en plus compliqué de trancher.
Pour nous aider dans notre choix et tout remettre à plat, nous faisons donc appel à un consultant. Il est là pour nous guider sur notre vision produit et technique. Il organise donc des ateliers pour nous aider à définir une vision claire, mais aussi notre architecture technique.
Durant l’atelier sur l’architecture, nous commençons par cartographier l’ensemble des outils, frameworks, langages que nous utilisons sur chacun des projets, à savoir Link et bureauxapartager.com.
S’il y a certes quelques points communs entre les deux projets (Symfony, MySQL, GCP), il y a aussi beaucoup de points divergents (Vue vs React vs Angular). Il nous semble alors évident que nous utilisons beaucoup trop de technos différentes pour faire la même chose. Nous avons 3 langages différents pour du backend API et 3 frameworks JS front.
L’étape suivante est donc de réduire le nombre de langages et framework utilisés.
L’heure du choix
Vient alors la question fatidique sur les projets futurs : quelle technologie devrions-nous adopter ?
Notre décision se porte sur les 3 critères suivants :
- Expertise de l’équipe
- Facilité de recrutement sur Paris
- Coût d’apprentissage et formation
Les arguments sont les suivants :
- PHP est le langage le plus maîtrisé au sein de l’équipe
- PHP ne pose pas de difficultés pour le recrutement
- La communauté autour de PHP, ReactJS, Symfony est très active
- Go présente des coûts de formation et de recrutement
- Aucun framework NodeJS n’est convaincant
Nous sommes conscients que NodeJS et Golang sont des langages plus performants en terme de temps que PHP mais comme nous n’avons pas cette problématique, Symfony est le choix parfait dans notre cas.
Nous décidons donc d’arrêter d’utiliser NodeJS, Golang et Angular pour les prochains projets mais continuons à maintenir les applications existantes.
L’écosystème de tests (unitaires, fonctionnels ou end-to-end) dans le langage PHP est tout de même beaucoup plus riche que dans d’autres langages (Golang ou NodeJS). Comme nous accordons une importance particulière à éviter les régressions, c’est un critère de plus dans notre décision.
En ce qui concerne le framework front JavaScript, notre choix se porte finalement sur ReactJS. Nous avons pour projet de développer des applications mobiles et le choix de React Native semble le plus logique.
En effet, comme notre équipe est essentiellement composée de développeurs Web, il est plus simple de privilégier ReactJS, qui sera bénéfique à la fois pour du développement Web et Mobile.
Avoir une personne extérieure à l’équipe a été un facteur clé dans notre prise de décision. Cette personne nous a apporté un regard neutre sur le projet et nous a aidé à nous confronter aux incohérences de notre stack dans un cadre bienveillant.
Un des gros chantiers qui arrive concerne la réalisation de services pour des fonctionnalités communes entre Link et bureauxapartager.com : cet atelier, qui met à plat notre architecture technique, nous a permis de bien clarifier notre stack en vue de ce projet.
Malgré ces changements, nous souhaitons continuer à apprendre et à se faire plaisir en codant.
Lorsque nous souhaitons expérimenter d’autres langages, nous avons des “open projects” à notre disposition : il s’agit d’une journée par mois qu’un·e développeur·se de l’équipe peut prendre pour regarder un sujet qui l’intéresse. Nous sommes aussi très libres d’organiser notre temps pour faire de la veille.
Bilan
Se mettre d’accord sur notre stack a été bénéfique pour l’équipe. Cela a longtemps été une source de conflits mais en parler a permis de poser les choses à plat et se mettre d’accord ensemble pour la suite.
Des APIs existent encore et continuent à fonctionner aujourd’hui en Golang et en NodeJS. Nous ne pensons pas les migrer dans un futur proche. Aujourd’hui, il y a 4 développeurs de l’équipe qui maîtrisent désormais mieux Go et nous faisons de notre mieux pour faire travailler tout le monde sur les différentes briques et favoriser le partage de connaissances.
Merci à Laïla et Jules pour avoir partagé une partie de l’histoire de la stack technique de Bureaux A Partager.
Si vous avez envie de les rejoindre, sachez qu’un poste de développeur·se fullstack Symfony/ReactJS est justement ouvert.