Accélérer le démarrage de nouveaux projets grâce à des gabarits solides

Démarrer un nouveau projet est toujours une étape excitante pour une équipe de développement. Puisque nous sommes une entreprise de services, démarrer un nouveau projet est une situation dans laquelle nous nous retrouvons souvent chez Mirego.

Plutôt que de partir de zéro à chaque fois, nous avons pris l’approche de projets gabarits, sur lesquels nous nous basons pour démarrer chaque nouveau projet. Nous croyons que cette approche est celle qui offre le plus d’avantages au niveau fiabilité, productivité et maintenabilité tout en comportant le moins de compromis possibles au niveau de la flexibilité dont avons besoin à chaque nouveau projet.

Cet article présente la philosophie derrière cette approche et ce qu’elle nous permet d’accomplir.

Projet gabarit (boilerplate)

Nous appelons projet gabarit un projet de référence qui contient toutes nos bonnes pratiques en matière de développement de produits numériques. Bref, il s’agit d’une coquille prête à accueillir le code spécifique d’un nouveau projet.

Lorsque nous démarrons le développement d’un nouveau projet, nous dupliquons ces fichiers de référence et pouvons immédiatement débuter l’implémentation de fonctionnalités propres à ce projet.

À travers un ensemble de technologies open-source que nous trouvons pertinentes dans la majorité de nos projets, ces bonnes pratiques constituent un regroupement de décisions et d’opinions que nous maintenons et faisons évoluer au fil du temps.

Nous possédons un projet gabarit pour chacune des technologies que nous utilisons majoritairement : Elixir, Ember.js, Kotlin Multiplatform et React.

Notre philosophie

1. Ne pas réinventer la roue

La notion de code réutilisable n’a rien de nouveau ; les développeurs s’y appuient depuis toujours. Réutiliser les mêmes lignes de code dans plus d’une situation contribue grandement à la productivité d’une équipe. Plus ce code réutilisable se situe à la base d’un produit numérique (i.e. ses fondations), plus son apport à la productivité est multiplié.

Au fil des années, nous avons réalisé que dans la majorité de nos projets, les fondations étaient pratiquement identiques et qu’il était redondant de toujours les rebâtir à chaque projet.

En utilisant un gabarit, il devient facile de développer des projets plus efficaces à maintenir puisqu’ils s’appuient sur les mêmes bases. Aussi : un développeur qui rejoint une nouvelle équipe sera déjà très familier avec les fondations et les conventions d’un projet qui lui auraient été autrement inconnues.

2. Fondations solides et production-ready

Un élément des projets gabarits est le niveau de confiance que nous portons pour ceux-ci. L’entièreté du code retrouvé dans ces projets est présentement déployée en production ; il n’y a donc pas de place pour l’expérimentation.

D’ailleurs, avant qu’une fonctionnalité soit intégrée dans un projet gabarit, elle doit minimalement avoir été intégrée et déployée en production dans un projet, pas le contraire.

Cela nous assure un très haut niveau de fiabilité dans les fondations de nos nouveaux projets, puisque nous n’y intégrons pas des fonctionnalités intéressantes « pour les prochains projets » ; nous y rapatrions des fonctionnalités production-ready à partir de projets matures.

3. Amélioration continue de nos pratiques

Le fait de maintenir des projets de référence de façon indépendante à nos projets en développement permet de traiter ceux-ci au même titre que des librairies réutilisables.

Cela signifie que non seulement ils peuvent, mais ils doivent évoluer au fil du temps à mesure que nos bonnes pratiques évoluent. Puisque nous démarrons fréquemment de nouveaux projets, nous avons souvent la chance de réviser nos opinions et de remettre en question ces pratiques.

Et comme dans toute bonne librairie réutilisable, il est important d’exposer l’historique des changements qui sont appliqués pour donner de la visibilité sur les améliorations, corrections de problèmes, etc.

4. Open-source pour contribuer aux communautés

Nous avons pris la décision de publier ces projets gabarits sous licence open-source publique pour deux raisons : redonner aux communautés open-source et tirer avantage de ces communautés.

La grande majorité des produits que nous bâtissons s’appuient sur des technologies open-source ; il est donc tout à fait normal que nous souhaitions redonner à ces communautés en mettant de l’avant nos bonnes pratiques, nos façons de faire et nos choix technologiques.

Rendre ces projets disponibles publiquement nous permet également de recevoir des suggestions d’améliorations de la part de cette communauté pour rendre ces fondations encore plus solides.

Avec l’approche des projets gabarits, nous croyons avoir trouvé le bon compromis entre l’utilisation de fondations stables et solides mais à la fois flexibles et évolutives.

Ces projets nous permettent de nous lancer très rapidement dans le développement d’un nouveau produit numérique, sans avoir à faire de compromis sur la stabilité, la qualité et la maintenabilité de celui-ci.