Reprendre une application développée avec Windev ou Webdev

Il est toujours beaucoup plus facile de créer une application, plutôt que de reprendre une application existante. Car en créant une application, on pose toutes les bases de l'organisation du projet, du style de programmation, du mode de déploiement, etc. On décide de tout et on sait pourquoi on fait tel ou tel choix.

Reprendre une application existante est une tout autre histoire. On appel cela un TMA (Tierce Maintenance Applicative). Cela dépend de la taille du projet et de l'expérience du développeur.

Un développeur débutant devra privilégier la reprise d'une application existante, simple et n'utilisant pas des concepts de Windev trop complexe. Cela lui permettra de monter en compétence sans trop de risque. Si toutefois le projet est complexe, la reprise d'un projet par un débutant sera semée d'embuches. Le risque de planter le projet est assez important pour les raisons suivantes :

  • Manque de visibilité et de recul sur les techniques complexes de Windev
  • Risque d'apporter des modifications, sans comprendre les choix du développeur ayant créé l'application
  • Non-respect des règles de déploiement du projet
  • Non-respect des règles de gestion des données du projet
  • Non-respect des règles de codage (nommage des variables, etc.)
Il ne faut jamais faire des modifications importantes dans un projet que l'on découvre. Il faut d'abord d'approprier le projet pour comprendre dans quel esprit le développeur qui l'a créé, à travailler. Sinon on risque de déstabiliser le projet et ce sera difficile à récupérer.

Pour ma part, voici comment je procède pour reprendre une application existante :

  • Je fais une phase d'étude avec les étapes suivantes :
    • analyse les connexions aux données
    • analyse de la structuration des données dans le mode Entités/Relation
    • Compréhension du style de programmation utilisé (classique Windev, orienté objet, SQL, etc.
    • Reconstitution du mode de déploiement
    • Rajout du projet dans un GDS
    • Recherche des liens externes au projet (fichiers spécifiques, URL, Webservices, etc.)
  • À l'issue de la phase d'étude, je fais un rapport, soit formel s'il est destiné à d'autres interlocuteurs externes à SEALOG, soit moins formel si c'est uniquement pour l'équipe de développeur. 
  • J'utilise un outil comme CONFLUENCE pour créer des procédures ou des notes explicatives  
  • Je résume des fonctionnements complexes en créant de schéma explicatif
  • Ensuite, on peut commencer à faire de la maintenance de l'application, c’est-à-dire traiter les demandes de dysfonctionnement des utilisateurs 
  • On notera dans un outil de gestion de ticket comme JIRA, les demandes plus importantes à traiter plus tard, lorsque l'on se sera bien approprié l'application
Dans la reprise d'une application, l'erreur la plus courante, lors de la réponse à une demande d'un utilisateur est d'aller trop vite sans bien analyser les liens entre ce que l'on voit et croit comprendre et la réalité de l'application. Le temps passer à l'analyser d'un problème est bien souvent très supérieur au temps que l'on passe à développer, tester et déployer la solution.


Commentaires

Enregistrer un commentaire