Outils et techniques pour améliorer la compréhension du code non familier?

Question

J'ai réalisé que ma plus grande faiblesse en tant qu'étudiant en programmation est ma faible capacité à comprendre le code des autres. Je n'ai aucun problème avec le code 'textbook', ou code clairement commenté, mais quand on me donne un programme de quelques centaines de lignes, contenant une douzaine de fonctions différentes et aucun commentaire, je trouve qu'il est très difficile de commencer. Je sais que ce type de code est probablement plus susceptible d'être rencontré dans ma carrière, et je pense que le fait d'avoir une mauvaise compréhension du code va être un grand obstacle pour moi, donc j'aimerais me concentrer sur l'amélioration de mes compétences dans ce domaine. Quels outils/techniques ont aidé à améliorer la compréhension du code dans votre expérience?

Comment avez-vous tendance à vous attaquer à un code non commenté et non commenté? Pourquoi? Qu'en est-il de votre technique que vous trouvez utile?

Merci

Answer 1

Je trouve que le dessin l'appel graphique et l'héritage des arbres des travaux souvent pour moi. Vous pouvez utiliser n'importe quel outil que vous avez à portée de main; D'habitude, j'utilise simplement un tableau blanc. Habituellement, les unités/fonctions de code sont assez faciles à comprendre par elles-mêmes, et je peux voir clairement comment chaque unité fonctionne, mais j'ai souvent du mal à voir la situation dans son ensemble, et c'est là que la panne se produit. ce sentiment de "je suis perdu".

Commencez petit. Dites-vous: "Je veux accomplir x, alors comment cela se fait-il dans le code?" où x est une petite opération que vous pouvez tracer. Ensuite, il suffit de tracer le code, en faisant quelque chose de visuel que vous pouvez regarder en arrière après la trace.

Ensuite, choisissez un autre x et répétez le processus. Vous devriez avoir une meilleure idée du code chaque fois que vous faites cela. Quand vient le temps d'implémenter quelque chose, choisissez quelque chose qui est similaire (mais pas presque identique) à l'une des choses que vous avez tracées. En faisant cela, vous passez d'une compréhension au niveau des traces à une compréhension au niveau de l'implémentation.

Il est également utile de parler à la personne qui a écrit le code la première fois.

Answer 2

La première chose que j'essaie de faire est de savoir ce que le but du code est à un niveau élevé - le détail est sans importance jusqu'à ce que vous compreniez un peu sur le domaine du problème. De bons moyens de comprendre cela incluent de regarder les noms des identifiants, mais il est généralement encore plus utile de considérer le contexte - où avez-vous obtenu ce code? Qui l'a écrit? Était-ce une partie d'une application avec un but connu? Une fois que vous avez compris ce que le code est censé faire, vous pouvez en faire une copie et commencer à le reformater pour le rendre plus facile à comprendre personnellement. Cela peut inclure changer les noms des identifiants si nécessaire, trier toute indentation bizarre, ajouter des espaces pour casser les choses, commenter les bits une fois que vous avez compris ce qu'ils font, etc. C'est un début, en tout cas ... :)

Aussi - une fois que vous avez compris le but du code, le passage à travers un débogueur sur des exemples simples peut aussi parfois vous donner une idée plus claire de ce qui se passe sur FWIW ...

Answer 3

vous familiarisant avec le code étranger

Si le code de base est assez petit, vous pouvez commencer à lire tout de suite. À un moment donné, les morceaux commenceront à tomber ensemble.

Dans ce scénario, "assez petit" varie, il s'agrandit à mesure que votre expérience augmente. Vous commencerez également à profiter de la "tricherie" ici: vous pouvez passer des morceaux de code que vous reconnaissez par expérience comme "motif d'implémentation X".

Vous pouvez trouver utile de faire de petits détours en lisant le code, par ex. en recherchant une fonction comme vous le voyez être appelé, puis passer un peu temps en regardant par-dessus. Ne restez pas sur ces détours jusqu'à ce que vous compreniez ce que fait la fonction appelée; Ce n'est pas le but, et cela vous donnera l'impression de sauter et de ne pas progresser. Le but lors de la déviation est de comprendre ce que la nouvelle fonction fait en moins d'une demi-minute. Si vous ne pouvez pas, cela signifie que la fonction est trop compliquée. Abandonnez le détour et acceptez le fait que vous devrez comprendre votre fonction «actuelle» sans cette aide supplémentaire.

Si le code est trop grand, vous ne pouvez pas commencer à le lire. Dans ce cas, vous pouvez commencer par identifier les composants logiques du programme à un niveau élevé d'abstraction. Votre objectif est d'associer des types (classes) dans le code source à ces composants, puis d'identifier le rôle que chaque classe joue dans son composant. Il y aura des classes utilisées en interne dans un composant et des classes utilisées pour communiquer avec d'autres composants ou frameworks. Diviser et conquérir ici: d'abord diviser les classes en groupes apparentés, puis se concentrer sur un groupe et de comprendre comment ses pièces s'emboîtent.

Pour vous aider dans cette tâche, vous pouvez utiliser la structure du code source comme guide (pas comme la loi ultime, elle peut parfois être trompeuse en raison d'une erreur humaine). Vous pouvez également utiliser des outils tels que "find uses" d'une fonction ou d'un type pour voir où chacun est référencé. Encore une fois, n'essayez pas de digérer complètement ce que l'EDI vous dit si vous ne pouvez pas le faire raisonnablement rapidement. Lorsque cela se produit, cela signifie que vous avez choisi un morceau de métal compliqué sur une machine que vous ne comprenez pas très bien. Remettez-le et essayez quelque chose d'autre jusqu'à ce que vous trouviez quelque chose que vous comprenez.

Débogage code étranger

Ceci est une autre question tout à fait. Je vais tricher un peu en disant que, jusqu'à ce que vous accumuliez des tonnes d'expérience, il n'y a aucun moyen de déboguer le code avec succès tant qu'il vous est étranger.

Answer 4

Understand est un formidable outil d'analyse de code. Il était largement utilisé chez mon employeur précédent (L-3), donc je l'ai acheté là où je travaille actuellement.

Answer 5

Je comprends votre frustration, mais gardez à l'esprit qu'il ya beaucoup de mauvais code là-bas, alors gardez votre menton. pas tout le code est mauvais :)

c'est le processus que j'ai tendance à suivre:

1. look pour les tests unitaires comme ils devraient documenter ce que le code est censé faire ...
2. navigate à travers le code en utilisant le code rush/resharper/raccourcis visuels studio - cela devrait vous donner quelques idées sur les niveaux logiques et physiques impliqués ...Scannez le code en premier, en recherchant les modèles courants, les conventions de nommage et les styles de code - ceci devrait vous donner un aperçu des normes des équipes et peut-être l'esprit des codeurs d'origine ...
3. comme je navigue dans le code heirarchie I notez les objets utilisés ... généralement avec le stylo & papier dessin un simple activity diagram:
4. J'ai tendance à partir d'un point d'entrée commun, donc s'il s'agit d'une interface utilisateur, commencez à partir de la vue et suivez votre chemin jusqu'au code d'accès aux données, si son service commence à partir des limites du service et se poursuit jusqu'au code d'accès aux données ...
5. Recherchez le code qui pourrait être refaçonné - si vous le pouvez voir le code qui peut être refactorisé, vous avez appris à le simplifier sans changer son comportement ...
6. pratique en construisant la même chose que vous étudiez, mais d'une manière différente ...
7. pendant que vous lisez non-testé code, pensez à des façons de le rendre testable ...
8. Utilisez le code Rush outils de diagnostic pour trouver des méthodes qui sont de haute complexité de maintenance ou complexité cyclomatique et accorder une attention particulière à ces domaines parce que les chances sont, c'est là que le plus de bugs sont ...

Bonne chance