Bonjour,
 
Comment doit-on s'y prendre quand on arrive dans un projet dont on n'a jamais vu le code ?
Je ne sais jamais par où commencer...
 
Merci d'avance de vos réponses

Pré-requis 1 : connaître le langage

Puis, tu ouvres le fichier

Ensuite, tu cherches la fonction main() (ou équivalent suivant le langage)

Et après, tu lis le code jusqu'à comprendre.  

edit : plus sérieusement, ta question n'est pas très précise. Par "projet", tu entends quoi, un binaire ? Deux ? Beaucoup plus ? Tu connais ce que fait le binaire avant de tenter de l'analyser ou tu pars du code sans même savoir ce qu'il est censé faire ?

Jusque là je suis d'accord mais je me demandais s'il y avait des techniques pour comprendre plus rapidement.  
Et une technique pour trouver le main en Java sous Eclipse ?

 
En partant du principe que tu n'as aucune documentation et que tu sais juste ce que fait le programme, soit la grande majorité des analyses à faire ? Je n'en connais pas en tout cas.
Pour ça que lorsque je dois coder une évolution, j'ajoute dans mon évaluation de charge un temps d'analyse conséquent, et c'est très bien compris d'ailleurs.  
Si c'est pour un debugging, l'analyse est en revanche beaucoup plus courte, j'ai rarement eu à comprendre plus que le bout de code concerné.
 

Je ne connais pas eclipse, mais bon, j'dirais lire le manifest du .jar est un bon départ, et s'il n'y a qu'un seul .java, alors la fonction main ne devrait pas être trop dure à trouver.

J'ai rarement vu des projets avec un seul .java
 

Merci c'est quelque chose à laquelle je n'avais jamais pensé
 
Merci pour vos réponses.

 
Et rarement avec un seul .jar non plus.  
Pour le reste, il n'y a plus qu'à prier que celui qui a écrit le code a d'abord passé du temps à le penser (ce qui n'arrive pas souvent), qu'il est compétent (ce qui n'est pas toujours le cas), qu'il est adepte du code auto-documenté (je n'en ai pas beaucoup vu), et qu'il remplit bien la javadoc (lol).

comprendre un nouveau projet ?
c'est long et tant que tu n'as pas foutu le nez dedans tu peux difficilement cerner les difficultés :
 
tu passes (en tout cas c'est mon cas) par les phases :
- ouah c'est tout beau tout mignion, ils ont fait des trucs de ouf les gars avant moi
- bon alors c'est où que je dois foutre mon bout de code pour faire la petite evolution qui m'est demandée
- hum c'est pas si facile que ca cette appli j'avais pas vu cette suptilité
- sous le caillou se cachait une montagne, j'avais pas vu la complexité du bouzin
- merde finalement c'est codé avec les pieds cette appli, j'aurai pu faire mieux
- je reecris une partie du code, et je crade un peu plus l'appli car j'ai pas le temps de réécrire l'appli complete
 

 
run->debug configuration
 
et la, tu as un search de main class

Ca m'est arrivé y'a pas longtemps (1 mois) pour un soft en php/mysql. J'ai commencé par demander : Ou sont les spécs? Où est le dossier de conception? Où est le MCD?... Y'avait les spécs mais pas complètes (des § où on pouvait lire un laconique "à définir" ). Donc reverse ingé sur la BD puis une fois que j'ai compris la structure de la bd, j'ai regardé l'architecture du code : d'abord les répertoires puis chaque fichier pour voir les liens entre l'IHM et les fichiers de code php. Avec tout ça, ça m'a permi d'avoir une bonne vue d'ensemble.

Mouais, demander les specs c'est un debut pour mettre le pied a l'etrier, mais le nombre de projet où les specs n'ont pas évolué avec le code...
 
Ensuite les docs techniques qui datent un peu : qui datent d'avant les 10 refactoring successifs...
 
La javadoc peut etre une aide, en espérant que les petits developpeurs bienveillant ont pensés à toi !
 

Ben moi, pour le projet Astres (cf ma signature) sur lequel je travaille depuis fin 2003 (14 versions mises en prod depuis) :
- les spécs sont à jour
- le dossier de conception est à jour (plus de 500 pages!)
- le manuel d'exploitation est à jour,
- le dossier de tests est à jour (plus de 300 pages!)
- le manuel est à jour (plus de 500 pages mais y'a beaucoup d'imprim-écran!).
- et je mets les commentaires en phpdoc pour les prototypes de chaque fonction.
 
D'un point de vue qualité, la doc fait partie intégrante du logiciel...
 
En plus, tenir à jour la doc, je trouve que c'est se montrer respectueux vis-à-vis de ceux qui vont passer derrière nous. Et même pour soir-même, ça aide. Quand on repasse sur du code complexe qui date de plusieurs mois, on est bien content de trouver de la doc dessus (pour répondre à des question du genre "pourquoi j'avais fait ça comme ça?" )

 
Merci je n'avais encore jamais remarqué depuis 2 ans que je connais Eclipse...

 
Personne dit que c'est impossible ou que c'est mal, c'est juste très rare Le cas classique c'est doc périmée/pas de doc.
Longue vie aux trop rares codeurs qui font du code autodocumenté