Outils et meilleures pratiques pour comprendre le code de quelqu'un d'autre

Question

Parfois, il faut creuser dans le code de quelqu'un d'autre, le comprendre et peut-être refactoriser/corriger. Je me demande donc quels outils/pratiques utilisez-vous pour faire cela? Il ne s'agit pas d'une langue ou d'une plate-forme spécifique, mais plutôt de conseils en général.
Je trouve moi-même très utile d'exécuter le code en question sous le débogueur (si c'est possible bien sûr), de définir des points d'arrêt et de parcourir le code.
J'ai également utilisé quelques outils UML avec des fonctionnalités de reverse engineering pour voir la grande image. La visualisation fonctionne plutôt bien pour moi. Il y a un outil que j'ai utilisé un peu: Understand. Ce n'est pas un outil UML, mais il a un tas de visualisations pour le code. Par exemple, organigramme de contrôle pour une fonction, qui ne fait pas partie d'UML, mais parfois c'est très utile.
J'ai entendu dire que parfois les gens écrivent des tests pour le code qu'ils veulent apprendre, mais cela n'a pas fonctionné pour moi. Parfois, le code que je veux comprendre n'est pas très testable.
Il existe d'autres outils, tels que les profileurs, les vérificateurs de dépendances, les enregistreurs, etc. Est-ce que quelqu'un l'utilise avec succès? Et comment?
À quoi sert la première chose? Quelle est la prochaine?

Answer 1

J'ai été dans cette situation avant ... Ce n'est pas très amusant. La meilleure façon que j'ai trouvée est d'écrire des tests unitaires pour couvrir les domaines qui vont changer. Même si des tests existent déjà, cela vous donne l'expérience à la fois de l'API et du comportement du code que vous avez l'intention de refactoriser. De plus, vous obtenez plus de tests pour vérifier l'implémentation de remplacement.

Answer 2

Êtes-vous à la recherche d'une structure de haut niveau, comme les modules, les espaces de nommage et la conception de classe? Ou essayez-vous de comprendre les internes des classes, par ex. comment fonctionnent les lignes de code spécifiques? Ce sont deux types d'outils d'analyse différents.

Answer 3

En règle générale, je partage ce genre de demandes en 2 camps:

1. corriger le bug, et non pas l'ensemble du code. Dans ce cas, j'aurais tendance à lire le code et à voir si je peux facilement mettre le correctif sans apporter de changements importants, par ex. ajouter 5 lignes de code ou moins. C'est là que les modifications apportées sont comme une frappe chirurgicale qui a un impact minimal pour atteindre le résultat souhaité. Détruisez le code et mettez en place des choses bien meilleures. Dans ce cas, il n'y a pas de bonne façon de faire le changement ou il y a beaucoup de petits changements qui veulent être regroupés dans un mini-projet où digérer tout le code est nécessaire et ce n'est pas un changement mineur et rapide . Prendre un site ASP et le mettre dans le dernier cadre .Net serait un exemple ici.

Déterminer quel type de changement est quelque chose nécessite un peu de pratique et de l'expérience comprendre ce que quelqu'un d'autre peut appeler, « une chose si vous pouviez ... » qui peut être une affaire énorme, mais ils ne le font pas voir de cette façon, par exemple Pouvons-nous ajouter un petit module qui enregistre toute erreur et m'envoie un e-mail quand quelque chose de mal arrive qui peut ne pas être si facile après que toutes les autres exigences soient réglées comme si le code ne pouvait pas envoyer de message faire.

Answer 4

Sorte de plate-forme spécifique, mais ReSharper est idéal pour démystifier la signification cachée du code .NET. J'aime la fonction "Find Usages Advanced" où vous pouvez rechercher des ensembles, des obtentions, des implémentations, etc ...

Answer 5

Vérifiez nWire.C'est un plugin Eclipse, actuellement pour Java & PHP, qui analyse votre code et offre des outils d'exploration, de visualisation et de recherche de code. L'outil consiste à comprendre les associations dans votre code: les hiérarchies de classe, les invocations, les instanciations et à peu près tout le reste. Je trouve cela très utile pour creuser dans des piles de code (BTW, pour moi, même mon propre code devient aliéné après quelques mois de ne pas le toucher).