Discussion :

[yetanotherlogin]

Bonjour

(Si une autre partie du forum est plus adaptée à ma question, merci de me l'indiquer.)

De manière générale, j'aimerais savoir comment font les programmeurs expérimentés pour comprendre le plus rapidement possible la logique d'un programme qu'ils sont amenés à modifier et y intégrer de nouvelles fonctionnalités?

Y a-t-il des méthodes/outils plus productifs que de suivre le code source ligne à ligne avec papier/crayon afin de peu à peu comprendre la logique?

Je trouve que c'est lent et qu'il est difficile de ne pas se perdre dans les détails.

Merci pour toute information.

[wiztricks]

Salut,

La principale difficulté porte sur la relativement bonne compréhension de l'existant nécessaire à la réalisation de ces modifications sans trop de dégâts (régressions fonctionnelles).

"Idéalement", une application est livrée avec une documentation dont les seuls intérêts sont:
- faciliter cette prise de connaissance par un/des développeurs d'un niveau raisonnable,
- documenter suffisamment l'application pour estimer la faisabilité et le coûts des évolutions.

Dans la pratique, la réalisation d'une telle documentation est souvent négligée et lorsqu'elle existe, elle permet rarement de satisfaire les besoins énoncés précédemment...

Et on se retrouve avec:
- une documentation qui existe à défaut de répondre à nos questions,
- des tas de sources,
- des scripts de constructions,
- un existant qui fonctionne,

Et il va falloir mettre un peu tout çà en forme pour définir ce qu'il faudra modifier. Cette mise en forme consiste à redécouvrir:
- l'organisation des différents fonctionnalités réalisées par l'application,
- les flux correspondants (au moins) aux principaux traitements effectués,

Une application, c'est comme une sorte de machine construite pour réaliser certaines fonctions. Avec de l'expérience, on peut rapidement construire une organisation qui a défaut de coller à l'application, donnera une "carte" qui permettra de la lire et de faire la part des choses entre important et secondaire.

Si l'application est "bien construite", elle sera généralement suffisamment bien structurée pour que l'important et le secondaire soit lisible.

Dans ce cas, le graphe des appels de méthodes/fonctions ressemblera à un arbre a plusieurs niveaux. Sinon il ressemblera à un parapluie: des tas de méthodes/fonctions appelées à la suite les unes des autres sans plus.

Puis, suivant le langage de développement, nous avons la possibilité de mettre en œuvre des outils de reverse engineering ou de trace qui permettent de construire des diagrammes de classes ou de séquences à partir des sources ou du contexte d'exécution.

Ces outils ne sont peut être pas à mettre en branle immédiatement: ils génèrent beaucoup d'informations qui vont dans des détails qui poseront des tas de questions qu'on ne saura peut être pas encore prioriser correctement.

C'est l'expérience qui vous permet d'arbitrer s'il faut élargir la connaissance globale ou décortiquer les détails.
- W

[yetanotherlogin]

Merci pour les infos. Je me demandais s'il existait un outil type Director qui pourrait afficher la logique d'un logiciel sous forme de storyboard sur lequel on pourrait zoomer in/out sur différentes parties afin d'avoir plus ou moins de détails.

Apparemment, c'est de la science-fiction ;-)