Discussion :

[Battant]

Bonjour,


Pendant ma formation mon professeur insistait beaucoup sur le fait qu'il fallait tracer un programme pour en trouver les erreur. D'ailleurs c'est un de mes points faibles que j'ai pu constater lors d'un examen.

Il s'agit de suivre l’évolution des variables d'un programme afin d'en prédire les bugs et les corriger.. Mon professeur conseillait de faire cela en imprimant le code.

Maintenant, je dois me plonger dans le code de dollibarr (erp open source). Le code est passablement volumineux. Toutefois, depuis l'échec à l'examen j'ai toujours voulus trouver des cours et des exercices sur les traces car je sais que c'est mon point faible. mes problèmes de vue ne vont peut-être pas aider mais il fait que j'essaie tout de même. Peut-être aurais-je besoin d'une synthèse vocale. Mon point fort c'est l'audition et ma mémoire auditive infinie..

Mon professeur insistait aussi sur la conception avec l'organigramme en passant par l'uml et le pseudo code. Dans ce domaine, j'ai été surpris de constater que les programme open source n'avais souvent pas de conceptions. Cela me parait être le cas avec et kde pim.

Je suis motivé pour faire des traces

Auriez-vous des conseils a me donner ?

Est-ce que quelqu'un connaît cette technique ?

Faut-il tracer des petits code pour commencer et si oui lesquelles ?

Je remercie le modérateur de bien vouloir ranger le message. Je ne suis pas sûr de l'endroit ni du forum.

Merci pour votre réponse.

Salutations

[souviron34]

Auriez-vous des conseils a me donner ?

Est-ce que quelqu'un connaît cette technique ?

Faut-il tracer des petits code pour commencer et si oui lesquelles ?

Je remercie le modérateur de bien vouloir ranger le message. Je ne suis pas sûr de l'endroit ni du forum.

Bonjour..

Alors en gros une "trace" est un texte contenant une info sur ce qui se passe, ou là où on en est, ou une erreur.

En général, la fonction de base sera du style

print_trace ( int Code, string Texte)

qui souvent contiendra soit un "printf", l'impresson du texte à l'écan, ur une console ou dans un fichier de log, soit dans un popup d'une IHM.

On identifie en général 3 à 4 niveaux (qu'on peut identifier via le code, ce qui par exemple dans une IHM peut se traduire par une icône différente):

• INFO : juste une info sur ce qu'on fait, là où on en est, etc
  
  
• WARNING : une info avertissant d'un danger potentiel (on est en limite de mémoire, de perofrmance, d'espace disque, on détecte quun fil est débranché, ...)
  
  
• ERROR : une info dissant que quelque chose s'est mal passé (erreur d'allocation de mémoire, d'écriture sur disque, time-out de non-réponse d'un périphérique, tentative de division par zéro, etc) : c'est une erreur qui empêche la bonne excution de la fonctionalité demandée, mais n'empêche pas la poursuite du logiciel (par exemple une erreur de time-out peut être simplement due au fait qu'on vient d'allumer le périphérique, et qu'il faut un certain temps pour qu'il soit dispo)
  
  
• FATAL_ERROR : c'est une erreur qui fait que le logiciel ne peut pas continuer : il n'y a plus d'espace disque où écrire, etc etc.

On y ajoute souvent 3 "flags" généraux qui vont encadrer l'écriture des traces :

• RUNTIME (ou rien)
• DEBUG
• FULL_DEBUG

Par exemple, avec FULL_DEBUG on pourra ajoute rà la trace la ligne du code source où ça s'est produit, le nom de la fonction à l'intérieur de laquelle ça s'est produit, etc.

Avec DEBUG, on pourra par exemple détailler les différentes étapes d'un algo ("avant telle boucle", "écriture dans fichier", etc)


Avec RUNTIME (ou rien) on aura le minimum de ce qu'on veut avoir comme trace.

Tu vois donc qu'avec ça, tu as 4*3 = 12 possiiblités de traces différentes.

En général, on combine un peu : dans la 2ième série de manière générale on n'utilise que DEBUG.. Mais dans un soft pro la première liste est utilisée tout le temps.

[DonQuiche]

Bonjour.

Pendant ma formation mon professeur insistait beaucoup sur le fait qu'il fallait tracer un programme pour en trouver les erreur.

Oui, ou une séance avec un débogueur interactif. Quand ce dernier est disponible et applicable, c'est presque toujours plus avantageux.

A moins que tu ne veuilles parler de l'exécution mentale d'un algorithme. Dans ce cas je ne vois rien d'autre que la pratique. Reprends tous les algorithmes de tes divers cours et entraîne-toi. Mais je ne pense pas qu'il existe d'ouvrages ou de cours dédiés.

Mon professeur insistait aussi sur la conception avec l'organigramme en passant par l'uml et le pseudo code. Dans ce domaine, j'ai été surpris de constater que les programme open source n'avais souvent pas de conceptions. Cela me parait être le cas avec et kde pim.

UML et le pseudo-code sont des outils de communication. Rien de plus, rien de moins. Ce sont des outils qui servent à expliquer aux membres de l'équipe ce qu'ils doivent faire, comment vont interagir leurs parties respectives ou comment fonctionne telle ou telle partie existante du programme. Et qui plus est ils sont limités : il ne faut pas chercher à couvrir exhaustivement le code (aucun intérêt) et toujours garder à l'esprit que ces artefacts se périment rapidement car le code final ne correspond jamais exactement à ce qui avait été prévu et que les évolutions sont inévitables.

Leur place dans la réalité du développeur est donc modeste bien que parfois significative. Ajoute à cela que les équipes libres sont moins structurées et que les dévs bénévoles ne vont pas contribuer si tu leur demandes de reproduire bêtement les diagrammes UML produits par d'autres. Tu as ton explication.


Surtout UML n'est pas une aide au raisonnement : la normalisation, l'agnosticisme et les ambitions d'UML se mettent inévitablement en travers de notre route, ne serait-ce que parce que les éditeurs sont du coup bien trop rigides à force d'essayer de se synchroniser avec le code, de vouloir générer celui-ci et de respecter les normes. Visio, le couple stylo/papier ou l'imagination sont bien plus souples et utiles à la réflexion. Quant au pseudo-code, bien que plus sympa, même problème : autant écrire directement du code. C'est aussi rapide, on bénéficie d'IDE modernes avec colorisation et assistant de refactorisation, et on peut tester dans la foulée.

Toutefois les choses sont différentes pour un étudiant : vous avez encore souvent du mal avec la syntaxe du langage et donc le pseudo-code vous permet de vous focaliser sur l'algorithme afin de ne pas être bloqués par la syntaxe. Même chose avec UML : les élèves et le professeur doivent communiquer ensemble, cette norme satisfait ce besoin.

[Mat.M]

Auriez-vous des conseils a me donner ?

Est-ce que quelqu'un connaît cette technique ?

j'ai une méthode très simple pour tracer
Il suffit de créer une fonction tracer_message et tu ouvres un fichier texte en mode ajout , tu écris l'heure et la date et des messages pertinents
Tu peux appeler cette fonction dans les grandes étapes du programmes l'initialisation les phases critiques

Mon professeur insistait aussi sur la conception avec l'organigramme en passant par l'uml et le pseudo code. Dans ce domaine, j'ai été surpris de constater que les programme open source n'avais souvent pas de conceptions. s

pas seulement dans le domaine de l'Open Source; en milieu professionnel aussi.
De par mon expérience, à part 2 grosses SSII, les projets informatiques sur lesquels j'ai été amené à travailler ont été conçus à "l'arrache" comme on dit sans aucune pré-analyse.
Si tu ne fais pas des spécifications minimales, une architecture minimale de projet qui est son épine dorsale, ton projet informatique va couler techniquement et financièrement

[Mat.M]

UML et le pseudo-code sont des outils de communication. Rien de plus, rien de moins. .

ehh UML ce n'est pas qu'un outil de communication.
Cela sert
* à avoir une vision globale du projet
* à formaliser la conception de parties d'un projet informatique notamment en modules
*au besoin à recourir à des "design patterns"
* à valider éventuellement l'architecture de tout ou partie d'un projet
donc à être en accord avec ses idées et sa conception des choses.

Maintenant si certaines personnes considérent que UML et la pré-conception/analyse c'est gadget et accessoire, tout comme la phase de tests d'ailleurs, alors pas étonnant que des tas de projets informatique se cassent la figure...

[DonQuiche]

ehh UML ce n'est pas qu'un outil de communication.
Cela sert
* à formaliser la conception de parties d'un projet informatique notamment en modules
*au besoin à recourir à des "design patterns"
* à valider éventuellement l'architecture de tout ou partie d'un projet
donc à être en accord avec ses idées et sa conception des choses.

Ces trois points peuvent être réalisés sans UML et ce dernier ne t'apporte absolument rien pour cette tâche, au contraire. Si tu cherches simplement à concevoir, pas besoin de normalisation lourdingue et inadaptée à ton langage, et encore moins d'éditeur fastidieux et bien moins pratique qu'un stylo ou que Visio.

Maintenant si certaines personnes considérent que UML et la pré-conception/analyse c'est gadget et accessoire, tout comme la phase de tests d'ailleurs, alors pas étonnant que des tas de projets informatique se cassent la figure...

Le stylo-bille et la langue française sont deux choses totalement différentes. Il en va de même pour UML et la conception.

Je réitère : UML ne sert qu'à communiquer. Si tu n'es pas d'accord, c'est que tu ne comprends pas correctement ces problématiques.

[Mat.M]

Reprends tous les algorithmes de tes divers cours et entraîne-toi. Mais je ne pense pas qu'il existe d'ouvrages ou de cours dédiés.

un algorithme ça ne s'apprend pas par coeur , exception faite des "classiques" comme les tris, les structures de données, les arbres binaires qui sont les bases.
Un algorithme c'est au programmeur de l'élaborer c'est pour ça que l'esprit logique, la capacité d'abstraction , la capacité d'analyse c'est important chez un programmeur bref un peu l'esprit mathématique.
J'aurais préférence à embaucher un matheux plutôt qu'un "expert" C# ou Java pour travailler sur un projet informatique

[DonQuiche]

un algorithme ça ne s'apprend pas par coeur , exception faite des "classiques" comme les tris, les structures de données, les arbres binaires qui sont les bases.
Un algorithme c'est au programmeur de l'élaborer c'est pour ça que l'esprit logique, la capacité d'abstraction , la capacité d'analyse c'est important chez un programmeur bref un peu l'esprit mathématique.
J'aurais préférence à embaucher un matheux plutôt qu'un "expert" C# ou Java pour travailler sur un projet informatique

Qu'essaies-tu de dire ? Pourquoi nous parler d'algorithme ? Relis la discussion et ne te laisse pas égarer par le mot "trace".

[Mat.M]

Le stylo-bille et la langue française sont deux choses totalement différentes. Il en va de même pour UML et la conception.

Je réitère : UML ne sert qu'à communiquer. Si tu n'es pas d'accord, c'est que tu ne comprends pas correctement ces problématiques.

??
Je n'ai pas abordé le problème de la langue française; j'ai abordé UML.
Quant à ne "ne pas comprendre ces problèmatiques" tu peux penser ce que tu veux..
je n'affirme pas que UML soit indispensable mais jamais je ne lancerais un projet informatique sans analyse préalable avec UML au besoin

[Mat.M]

Qu'essaies-tu de dire ? Pourquoi nous parler d'algorithme ? Relis la discussion et ne te laisse pas égarer par le mot "trace".

Moi y en a à pas comprendre ce que dit le monsieur
??? C'est toi qui a utilisé le terme d'algorithme
C'est plutôt à toi de relire la discussion non ?

[DonQuiche]

??
Je n'ai pas abordé le problème de la langue française; j'ai abordé UML.
Quant à ne "ne pas comprendre ces problèmatiques" tu peux penser ce que tu veux..
je n'affirme pas que UML soit indispensable mais jamais je ne lancerais un projet informatique sans analyse préalable avec UML au besoin

Le sytlo-bille sert à retranscrire la langue française, UML sert à retranscrire l'analyse et la conception. UML n'est pas l'analyse ou la conception, il est le moyen que tu utilises pour communiquer le fruit de ton analyse et de ta conception aux autres. Pour ton usage personnel tu peux dessiner tes boîtes rondes ou carrées, on s'en fiche tant que tu sais ce que tu veux dire.

Moi y en a à pas comprendre ce que dit le monsieur
??? C'est toi qui a utilisé le terme d'algorithme
C'est plutôt à toi de relire la discussion non ?

Mais on s'en fout des algos c'est pas le sujet. Il ne parvient pas à exécuter mentalement un code, un algorithme. On ne parle pas d'écriture/conception d'algorithme, il en est au stade avant ça où il ne parvient pas encore à se représenter mentalement le déroulement d'une boucle et comment les variables sont modifiées.

Donc je lui dis de reprendre des pseudo-codes, des algos, et de les exécuter mentalement. Et toi je ne sais pas de quoi tu nous parles.