Quels outils ou techniques sont utiles pour décrire une base de code inconnue? [fermé]

Lors de l'inspection manuelle du code inconnu (à réviser ou à modifier), il me semble avoir trois options.

• Une lecture descendante du code, en choisissant chaque fichier source suivant en fonction de la nature fondamentale du nom de fichier. Je finis généralement par lire presque tout. Certains fichiers deux fois.
• Une lecture en largeur , où je trouve et lis toute la méthode d'invocation avec une compréhension minimale. Lisez ensuite toutes les fonctions appelées par la fonction, etc. Ma pile mentale a tendance à déborder si je fais quelques appels profonds.
• Une lecture en profondeur , où je passe en revue tout le code dans un débogueur, incertain de savoir si cela prendra 8 minutes ou 8 heures.

Une fois que j'ai lu suffisamment de code pour avoir une compréhension assez solide de ce qu'il fait, je pense souvent que j'ai lu 80% ou plus de la base de code, tandis que le code fondamental est de 20% ou moins . J'ai perdu beaucoup de temps.

Quels outils sont utiles pour obtenir une compréhension rapide du code non familier? Y a-t-il des outils qui peuvent donner une "vue d'ensemble" du chemin de code critique et me permettre de descendre dans les détails de n'importe quelle partie?

La meilleure chose, bien sûr, est que quelqu'un qui connaît la base de code vous guide. Si ce n'est pas une option, il existe des outils qui peuvent vous aider.

• VisualStudio peut générer automatiquement un diagramme de classes UML d'une base de code. À tout le moins, il vous montrera les hiérarchies de classes.
• L'oxygène peut être extrêmement utile. Même si le code n'a pas les commentaires de style doxygen, doxygen peut toujours générer une documentation lisible, des diagrammes de classes et des graphiques d'appels, ce qui peut être très utile pour trouver votre chemin dans une base de code inconnue.

En règle générale, vous souhaitez également utiliser un IDE complet, où vous pouvez cliquer avec le bouton droit sur n'importe quoi et "aller à la définition". Cela peut vous faire gagner beaucoup de temps, par rapport à l'utilisation de grep sur de nombreux fichiers dans une structure de répertoire complexe.

Une autre chose importante, selon le temps que vous aurez à gérer le code. S'il y a des tests unitaires, parcourez les tests. S'il n'y a pas de tests, commencez à les écrire. Faites une hypothèse sur ce que fait une classe ou une fonction particulière et écrivez un test pour le tester. Cela demande beaucoup de discipline, mais c'est un excellent moyen d'obtenir des réponses sur ce qui se passe dans le code.

Il s'agit d'une approche plus radicale. Cette technique peut être utile pour un projet comportant de nombreuses classes qui ne sont pas organisées en espaces de noms significatifs.

Le but de cet exercice est de découvrir la relation de classe. Faites un clone jetable du projet, puis essayez de placer certaines classes dans des espaces de noms. Pour gagner du temps sur les tentatives répétées, utilisez certains outils de traitement de fichiers Regex pour automatiser cette modification.

Cela provoquera de nombreuses erreurs de compilation. Dans le processus de correction de ces erreurs, on comprendra mieux comment ces classes dépendent les unes des autres et décidera quelles classes pourraient être placées dans le même espace de noms.

Cette technique est utile dans la mesure où on peut l'appliquer même avec peu de compréhension de l'organisation du code du projet. Avec cela vient le risque que certaines classes soient égarées par cette technique en raison d'un malentendu.