Comment analyser et comprendre une solution technique existante ?
D’où commencer la phase de diagnostique pour répondre à votre premiere tâche de maintenance ?
Comment étudier une implémentation technique existante pour réaliser une demande d’évolution ?
Dans cet article destiné aux développeurs logiciel, je partage avec vous la synthèse d’un retour d’expérience sur ma démarche utilisée lors de l’analyse d’une solution existante, pour entamer ma première tâche de maintenance ou d’évolution .
Se familiariser avec une solution existante :
1. Avoir une idée sur le périmètre fonctionnel via la consultation de la documentation dédiée ou à partir d’un support d’utilisateurs finaux (approche rapide), c’est la première condition pour s’intégrer au projet.
2. Consulter l’architecture globale du projet pour déterminer le périmètre technique, notamment le modèle de conception (MVC, SOA …), les technologies appliquées, la nature de l’environnement (Système d’exploitation, type de serveurs et BDD …) , ainsi que les différents composants ou modules de la solution (préciser les modules internes et les tiers externes).
3. Examiner la structure de chaque module (ou des modules principaux) à savoir la couche présentation, logique métier et la couche de données.
4. Commencer à mapper chaque domaine fonctionnel avec le module technique associé .
Phase de Diagnostique , Maintenance ou d’évolution :
Cette étape sert à corriger une anomalie déclarée, réaliser un ré-factoring ou l’amélioration d’une fonctionnalité, premièrement en commence par :
- Cerner le cadre fonctionnel et préciser le scénario d’exécution de la fonctionnalité en question, une fois validé et confirmé en peut passer au cadre technique où vous devez localiser un ou plusieurs lieux d’intervention : Intervention FrontEnd , Intervention sur le code Backend , Intervention au niveau de l’environnement technique (Serveur, OS, Service tier externe …)
- Adopter l’approche diviser pour régner et décomposer la fonctionnalité ou la demande en question, en plusieurs sous éléments faciles à traiter .
- Exécuter des tests unitaires pour comprendre les inputs(paramètres d’entrés), l’output (résultat attendu) et le Workflow exécuté .
- Analyser la liaison et l’impact sur l’existant, puis commencer petit à petit la conception et le développement TDD .
A vos idées pour enrichir ces pratiques et partager les expériences 😉