Un développeur qui rejoint votre équipe ne commence pas forcément par écrire du code.

Lorsqu’il arrive sur une application existante, il découvre un environnement qu’il n’a pas conçu : des règles métier, une architecture, une base de données, des choix techniques et des pratiques de développement déjà en place.

Avant de contribuer efficacement, il doit donc comprendre cet environnement. 

Que doit-il comprendre en premier pour devenir rapidement opérationnel ?

La réponse ne se résume pas à la technologie utilisée. Elle commence par trois éléments essentiels : le métier, l’architecture et les données. 

Comprendre le métier avant de comprendre le code

Une application répond toujours à un besoin métier.

Avant de modifier une fonctionnalité, un développeur doit comprendre ce que l’application permet de faire, qui l’utilise et quelles règles régissent son fonctionnement.

Cette compréhension est importante parce qu’une même fonctionnalité peut avoir des conséquences différentes selon le contexte métier. 

Par exemple, modifier la manière dont une donnée est calculée ou enregistrée peut avoir des impacts sur d’autres fonctionnalités de l’application.

Comprendre le métier permet donc de ne pas considérer le code comme une succession de fonctions à modifier, mais comme la traduction technique d’un fonctionnement métier.

Le développeur doit progressivement pouvoir répondre à des questions simples :

• Quel problème l’application résout-elle ?
• Qui utilise cette fonctionnalité ?
• Quelles sont les règles métier importantes ?
• Pourquoi cette donnée est-elle utilisée de cette manière ?
• Quelles conséquences peut avoir une modification ?

Avant de comprendre comment modifier une fonctionnalité, il faut comprendre pourquoi elle fonctionne ainsi.

Analyser l’architecture pour comprendre comment l’application est construite

Une fois le contexte métier mieux compris, le développeur doit pouvoir se représenter l’architecture de l’application.

Il ne s’agit pas simplement d’identifier les technologies utilisées.

Il doit comprendre comment les différentes parties du système sont organisées et communiquent entre elles :

• application frontend ;
• backend ;
• APIs ;
• services ;
• bases de données ;
• systèmes externes ;
• mécanismes d’authentification ;
• traitements spécifiques.

Cette analyse permet de comprendre où intervenir lorsqu’une évolution est demandée.

Deux applications peuvent utiliser exactement la même technologie tout en ayant des architectures très différentes.

C’est pourquoi connaître Symfony, Django, React ou une autre technologie ne suffit pas à comprendre immédiatement une application existante.

Le développeur doit d’abord comprendre les choix qui structurent le projet.

Comprendre la structure de la base de données

La base de données constitue également une partie essentielle de la compréhension d’une application.

Elle permet souvent de voir comment les informations sont organisées et comment les différentes fonctionnalités sont liées entre elles.

Le développeur doit notamment identifier :

• les principales entités ;
• les relations entre les données ;
• les dépendances existantes ;
• les informations utilisées par les différentes fonctionnalités ;
• les contraintes qui peuvent influencer une évolution.

Cette étape permet notamment d’éviter une erreur fréquente : modifier une fonctionnalité sans mesurer les conséquences sur les données existantes.

Une évolution qui semble simple côté interface peut nécessiter plusieurs adaptations côté backend et base de données.

Comprendre les données, c’est donc aussi comprendre une partie du fonctionnement réel de l’application.

Identifier les choix et les contraintes existants

Lorsqu’un développeur arrive sur un projet, certaines décisions ont déjà été prises.

Elles peuvent concerner l’architecture, les technologies, la structure des données, les conventions de code ou encore les méthodes de déploiement.

Toutes ces décisions ne sont pas forcément documentées.

Il peut également exister des contraintes liées à l’historique du projet, aux fonctionnalités déjà utilisées par les clients ou à des dépendances avec d’autres systèmes.

Avant de proposer une modification, le développeur doit donc chercher à comprendre pourquoi l’existant fonctionne de cette manière.

L’objectif n’est pas de considérer automatiquement que tout ce qui existe doit être conservé.

Mais il faut comprendre l’existant avant de décider ce qui doit être modifié.

Prendre connaissance du code et des pratiques de l’équipe

Après avoir compris le métier, l’architecture et les données, le développeur peut entrer plus précisément dans le code.

Il doit alors découvrir la manière dont l’équipe travaille :

• organisation du code ;
• conventions de développement ;
• gestion des branches ;
• revues de code ;
• tests ;
• gestion des tickets ;
• processus de déploiement ;
• outils de collaboration.

Cette étape facilite son intégration dans le fonctionnement de l’équipe.

L’objectif n’est pas de lui demander de reproduire exactement les habitudes de chaque développeur, mais de lui permettre de travailler dans le cadre technique et organisationnel déjà établi.

Passer progressivement de la compréhension à l’autonomie

L’intégration ne s’arrête évidemment pas à la phase de découverte.

Le véritable objectif est de permettre au développeur de devenir progressivement autonome.

La progression peut être résumée ainsi :

Métier → Architecture → Base de données → Code existant → Prise en charge → Autonomie

Au début, le développeur aura naturellement davantage besoin d’échanger avec l’équipe interne.

Puis, à mesure qu’il comprend le projet, il peut prendre en charge des sujets de plus en plus importants avec moins d’accompagnement.

C’est cette progression qui permet au renfort de devenir une véritable capacité supplémentaire pour l’équipe.

Une intégration réussie commence par la compréhension

Lorsqu’un développeur rejoint une équipe, sa valeur ne repose donc pas uniquement sur sa maîtrise technique.

Il doit aussi être capable d’entrer dans un projet qu’il n’a pas conçu, de comprendre les décisions prises avant son arrivée et de travailler avec les personnes qui connaissent déjà l’application.

Chez DevelopA, cette phase de compréhension fait partie de l’intégration au projet : comprendre l’environnement existant avant de contribuer à son évolution.

L’objectif est ensuite de permettre au développeur de prendre progressivement en charge une partie réelle du développement, tout en respectant l’architecture, les pratiques et les contraintes du projet.

À retenir

Un développeur peut maîtriser parfaitement une technologie.

Mais pour être efficace sur votre application, il doit d’abord comprendre ce qu’elle fait, comment elle est construite et comment ses données sont organisées.

Car intégrer un développeur à une équipe existante ne consiste pas simplement à lui donner accès au code.

Il faut d’abord lui donner les clés pour comprendre le projet.

Un nouveau développeur arrive dans votre équipe : quelle est la première chose que vous lui faites découvrir ?