Comprendre le code des autres

Question

Je suis parfois assez malheureux pour apporter des modifications à des versions très anciennes, mal pas documentées et mal pas code conçu.

Il faut souvent beaucoup de temps pour effectuer un simple changement car le code existant n’est pas très structuré et je dois vraiment lire beaucoup de code avant d’avoir une idée précise de la situation.

Ce qui, à mon avis, aiderait beaucoup dans des cas comme celui-ci est un outil qui permettrait de visualiser un aperçu du code, voire d’explorer plus en détail. Je pense qu’il serait très difficile d’obtenir un tel outil, étant donné qu’il est difficile de trouver une structure où il n’y en a que peu ou pas.

Je suppose que ce n’est pas vraiment une question, mais plutôt une rêverie. Je devrais en faire une question - Que font les autres pour les aider à comprendre le code des autres peuples, le bon et le mauvais?

Answer 1

Je recommande vivement BOUML . C'est un outil de modélisation UML gratuit, qui:

• est extrêmement rapide (outil UML le plus rapide jamais créé, consultez les tests d'évaluation ),
• prend en charge l’importation C ++,
• dispose d’un excellent support d’exportation SVG, ce qui est important, car la visualisation de grands graphiques au format vectoriel, qui évolue rapidement, par exemple. Firefox est très pratique (vous pouvez rapidement basculer entre & "Oeil d'oiseau &"; Voir la vue détaillée de la classe),
• est complet et intensément développé (consultez la historique du développement ), il est difficile de croire que des progrès rapides sont possibles).

Donc: importez votre code dans BOUML et visualisez-le ici ou exportez-le au format SVG et visualisez-le dans Firefox.

Answer 2

Hmm, c’est difficile, tellement de choses à dire si peu de temps ...

1) Si vous pouvez exécuter le code, cela simplifie tellement la vie, les points de rupture (en particulier conditionnels) sont vos amis.

2) L’approche des puristes consisterait à écrire quelques tests unitaires, pour des fonctionnalités connues, puis à refactoriser pour améliorer le code et la compréhension, puis à nouveau testés. Si les choses se cassent, créez davantage de tests unitaires - répétez cette opération jusqu'à ce que ennuyé / ancien / déplacé vers un nouveau projet

3) ReSharper montre bien où les choses sont utilisées, ce qui appelle une méthode, par exemple, c'est statique mais c'est un bon début, et cela aide à la refactorisation.

4) De nombreux événements .net sont codés comme publics et peuvent être difficiles à déboguer dans les meilleures conditions. Recodez-les pour qu'ils soient privés et utilisez une propriété avec add / remove. Vous pouvez ensuite utiliser le point d'arrêt pour voir ce qui est à l'écoute d'un événement.

BTW - Je joue dans l’espace .Net, et j'aimerais un outil pour aider à faire ce genre de choses, comme Joel, est-ce que quelqu'un connaît un bon outil de révision de code dynamique?

Answer 3

On m'a déjà demandé de prendre possession de certains codes NASTY - à la fois travail et & "jouer &";

La plupart des amateurs pour lesquels j'ai repris le code l'avaient simplement fait évoluer pour faire ce dont ils avaient besoin au fil de plusieurs itérations. C’était toujours un énorme bazar incestueux de bibliothèque A appelant B, rappelant A, appelant C, appelant B, etc. Souvent, ils utilisaient des threads et non une section critique.

J'ai trouvé le meilleur / le seul moyen d'obtenir une poignée sur le code: commencez au point d'entrée du système d'exploitation [main ()] et construisez mon propre diagramme de pile d'appels montrant l'arbre des appels. Vous n'avez pas vraiment besoin de construire un arbre complet au début. Tracez simplement la ou les sections sur lesquelles vous travaillez à chaque étape et vous maîtriserez suffisamment les tâches à exécuter pour pouvoir les exécuter.

Pour couronner le tout, utilisez la plus grande tranche d’arbre mort que vous pouvez trouver et un stylo. Tout placer devant vous pour que vous n'ayez pas à revenir en arrière sur les écrans ou les pages vous simplifie la vie.

EDIT: On parle beaucoup de normes de codage ... elles ne feront que rendre un code médiocre cohérent avec un bon code (et seront généralement plus difficiles à détecter). Les normes de codage ne facilitent pas toujours la maintenance du code.

Answer 4

Je le fais régulièrement. Et ont développé des outils et des astuces.

• Essayez d'obtenir une vue d'ensemble (diagramme d'objets ou autre).
• Documentez vos conclusions.
• Testez vos hypothèses (en particulier pour le code vague).

Le problème, c’est que dans la plupart des entreprises, vous êtes apprécié par les résultats. C'est pourquoi certains programmeurs écrivent rapidement du code de mauvaise qualité et passent à un autre projet. Il ne reste donc que des déchets et votre patron compare vos progrès lents avec ceux qui sont rapides et sales. (Heureusement, mon employeur actuel est différent).

Answer 5

J'utilise généralement des diagrammes de séquence UML de différentes manières principales d'utilisation du composant. Je ne connais aucun outil capable de les générer automatiquement, mais de nombreux outils UML tels que BoUML et EA Sparx peuvent créer des classes / opérations à partir du code source, ce qui enregistre certaines saisies.

Answer 6

Le texte définitif sur cette situation est le "Code de travail hérité" de Michael Feathers. En tant que S. Lott dit de faire quelques tests unitaires pour établir le comportement du code de lagacy. Une fois que vous en avez, vous pouvez commencer à refactoriser. Il semble y avoir un exemple de chapitre disponible sur le site Web Object Mentor.

Answer 7

Consultez les tests unitaires d'anciennes applications de formulaires Web ASP.NET pour obtenir des conseils sur la prise en main. sur les applications existantes via des tests unitaires.

Il existe de nombreuses questions et réponses similaires. Voici la recherche https://stackoverflow.com/search?q=unit+test+legacy

Le fait est qu'il est probablement plus facile de se familiariser avec l'héritage, si vous écrivez des tests unitaires pour cet héritage.

Answer 8

Je n'ai pas eu beaucoup de chance avec les outils permettant d'automatiser la révision de code mal documenté / exécuté, car un programme déroutant / mal conçu se traduit généralement par un modèle peu utile. Ce n'est pas excitant ni immédiatement gratifiant, mais j'ai obtenu les meilleurs résultats en choisissant un poste et en suivant l'exécution du programme ligne par ligne, en documentant et en ajoutant des commentaires au fur et à mesure, et en procédant à une refactorisation, le cas échéant.

Answer 9

un bon IDE (EMACS ou Eclipse) pourrait aider dans de nombreux cas. Également sur une plate-forme UNIX, il existe des outils pour les références croisées (etags, ctags), la vérification (lint) ou gcc avec de nombreuses options d’avertissement activées.

Premièrement, avant d'essayer de comprendre une fonction / méthode, j'aimerais la reformuler un peu pour l'adapter à vos conventions de codage (espaces, accolades, indentation) et supprimer la plupart des commentaires s'ils semblent erronés.

Ensuite, je refacturerai et commenterai les parties que vous avez comprises, et essayerai de trouver / grep ces parties sur l’ensemble de l’arbre source et de les refactoriser là aussi.

Au fil du temps, vous obtenez un code plus agréable avec lequel vous aimez travailler.

Answer 10

Personnellement, je dessine beaucoup de schémas et je découvre les os de la structure.

La fad de jour (et peut-être même à juste titre) m'a demandé d'écrire des tests unitaires pour tester mes affirmations et de constituer un filet de sécurité pour les modifications apportées au système.

Une fois que je serai suffisamment à l'aise pour savoir ce que le système fait, je tenterai de corriger les bugs de la manière la plus saine possible et j'espère que mes filets de sécurité seront bientôt terminés.

C'est juste moi, cependant. ;)

Answer 11

J’ai utilisé les fonctionnalités de refactoring de ReSharper pour m’aider à comprendre un groupe de projets dont j’ai hérité récemment. Donc, pour comprendre le code non documenté très mal structuré d'un autre programmeur, je commence par le refactoriser.

Nettoyer le code, renommer correctement les méthodes, les classes et les espaces de noms, extraire les méthodes sont tous des changements structurels susceptibles de faire la lumière sur ce qu’un morceau de code est censé faire. Cela peut sembler contre-intuitif de refactoriser du code que vous ne & "Connaissez pas &"; Mais, à vrai dire, ReSharper vous permet vraiment de le faire. Prenons par exemple la question du code mort au hareng rouge. Vous voyez une méthode dans une classe ou peut-être une variable étrangement nommée. Vous pouvez commencer par essayer de rechercher des utilisations ou, ungh, faire une recherche de texte, mais ReSharper détectera le code mort et le colorera en gris. Dès que vous ouvrez un fichier, vous voyez en gris et avec les indicateurs de barre de défilement ce qui aurait jadis dérouté les harengs rouges.

Il existe des dizaines d’astuces et probablement un certain nombre d’outils pouvant faire la même chose, mais je suis un Junky de ReSharper.

A bientôt.

Answer 12

Familiarisez-vous avec le logiciel du point de vue de l'utilisateur. On peut apprendre beaucoup de choses sur la structure sous-jacente en étudiant et en interagissant avec les interfaces utilisateur.

Answer 13

• Imprimés
• Tableaux blancs
• Beaucoup de papier à lettres
• Beaucoup de Starbucks

Pouvoir gribouiller partout dans la pauvreté est la méthode la plus utile pour moi. Habituellement, je trouve beaucoup de & "Hein, c’est drôle ... &"; tout en essayant de faire des diagrammes de structure de code de base qui s'avèrent plus utiles que les diagrammes eux-mêmes à la fin. Les outils automatisés sont probablement plus utiles que ce que je leur attribue, mais l'intérêt de trouver ces éléments amusants dépasse pour moi la valeur des diagrammes générés rapidement.

Pour les diagrammes, je cherche surtout où vont les données. Où entre-t-il, où finit-il et par quoi passe-t-il en cours de route. En général, ce qui se passe avec les données semble donner une bonne impression de la mise en page globale, ainsi que de quelques os sur lesquels revenir si je suis en train de réécrire.

Answer 14

Lorsque je travaille sur du code hérité, je n'essaie pas de comprendre le système entier. Cela entraînerait une surcharge de complexité et une explosion cérébrale ultérieure.

Au lieu de cela, je prends une seule fonctionnalité du système et essaie de comprendre parfaitement son fonctionnement, de bout en bout. Je déboguerai généralement dans le code, en partant du point dans le code de l'interface utilisateur où je peux trouver la fonctionnalité spécifique (puisqu'il s'agit généralement de la seule chose que je pourrai trouver au début). Ensuite, je vais effectuer certaines actions dans l'interface graphique, puis explorer le code jusqu'à la base de données, puis faire une copie de sauvegarde. Cela aboutit généralement à une compréhension complète d'au moins une caractéristique du système et donne parfois un aperçu des autres parties du système.

Une fois que je comprends quelles fonctions sont appelées et quelles procédures stockées, tables et vues sont impliquées, je fais ensuite une recherche dans le code pour déterminer quelles autres parties de l'application reposent sur ces mêmes fonctions / procs. C'est ainsi que je découvre si un changement que je vais effectuer cassera tout autre élément du système.

Il peut aussi parfois être utile d’essayer de créer des diagrammes de la base de données et / ou de la structure du code, mais c’est parfois tellement mauvais ou incroyablement complexe qu’il vaut mieux ignorer le système dans son ensemble et se concentrer uniquement sur la partie vous devez changer.

Answer 15

Mon gros problème, c’est que j’ai (actuellement) de très grands systèmes à comprendre en un laps de temps assez court (je plains les développeurs de contrat sur ce point) et je n’ai pas beaucoup d’expérience dans ce domaine (ayant été chanceux auparavant). assez pour être celui qui conçoit à partir de la base.)

L’une des méthodes que j’utilise est d’essayer de comprendre le sens de la dénomination des variables, méthodes, classes, etc. Ceci est utile car il intègre (de plus en plus, espérons-le) une vue de haut niveau d’un train de pensée du niveau atomique .

Je dis cela parce que, généralement, les développeurs nommeront leurs éléments (avec ce qu’ils croient être) de manière significative et fourniront un aperçu de la fonction à laquelle ils sont destinés. Certes, cela est défectueux, si le développeur a une mauvaise compréhension de son programme, de la terminologie utilisée ou (souvent, à mon humble avis) tente de paraître intelligent. Combien de développeurs ont vu des mots-clés ou des noms de classes et seulement après avoir recherché le terme dans le dictionnaire, pour la première fois?

Answer 16

Tout dépend des normes et des règles de codage utilisées par votre entreprise.

Si tout le monde code dans un style différent, alors il est difficile de conserver le code du programmeur, etc., si vous décidez quelle norme vous allez appliquer certaines règles, tout ira bien :) Remarque: vous n'êtes pas obligé de le faire. beaucoup de règles, parce que les gens devraient avoir la possibilité de coder dans le style qui leur plaît, sinon vous pouvez être très surpris.