Comment plongez-vous dans les grandes bases de code?

Quels outils et techniques utilisez-vous pour explorer et apprendre une base de code inconnue?

Je pense à des outils tels que grep, ctagsdes tests unitaires, des tests fonctionnels, des générateurs de diagrammes de classes, des graphiques d'appel, des métriques de code sloccount, etc. Je serais intéressé par vos expériences, les aides que vous avez utilisés ou écrits vous-même et la taille de la base de code avec laquelle vous avez travaillé.

Je me rends compte que la familiarisation avec une base de code est un processus qui se produit avec le temps, familiarité pouvant aller de "je suis capable de résumer le code" à "je peux le refactoriser et le réduire à 30% de sa taille". Mais comment même commencer?

ce que j'ai toujours fait est le suivant:

Ouvrez plusieurs copies de mon éditeur (Visual Studio / Eclipse / Whatever), puis procédez au débogage et effectuez des sauts de ligne dans le code. Découvrez le flux du code, tracez la pile pour voir où se trouvent les points clés et partez de là.

Je peux regarder méthode après méthode - mais c'est bien si je peux cliquer sur quelque chose, puis voir où il est exécuté dans le code et le suivre. Laissez-moi avoir une idée de la façon dont le développeur voulait que les choses fonctionnent.

Comment manges tu un éléphant?

Une bouchée à la fois :)

Sérieusement, j'essaie d'abord de parler aux auteurs du code.

Dois-je pirater jusqu'à ce que je fasse le travail

Dans une large mesure, oui (désolé).

Approches que vous pourriez envisager:

1. Essayez de savoir ce que le code est censé faire, en termes commerciaux.
2. Lisez toute la documentation existante, peu importe sa gravité.
3. Parlez -en à tous ceux qui pourraient savoir quelque chose au sujet du code.
4. Parcourez le code dans le débogueur.
5. Introduisez de petits changements et voyez ce qui se casse.
6. Apportez de petites modifications au code pour le rendre plus clair.

Certaines des choses que je fais pour clarifier le code sont:

1. Exécutez un prettificateur de code pour formater le code correctement.
2. Ajoutez des commentaires pour expliquer ce que je pense que cela pourrait faire
3. Modifier les noms de variables pour les rendre plus claires (à l'aide d'un outil de refactoring)
4. Utilisation d'un outil mettant en évidence toutes les utilisations d'un symbole particulier
5. Réduire l'encombrement dans le code - code commenté, commentaires sans signification, initialisations de variables inutiles, etc.
6. Modifier le code pour utiliser les conventions de code actuelles (à nouveau à l'aide des outils de refactoring)
7. Commencez à extraire des fonctionnalités dans des routines significatives
8. Commencez à ajouter des tests si possible (pas souvent possible)
9. Débarrassez-vous des nombres magiques
10. Réduire les doublons si possible

... et toutes autres améliorations simples que vous pouvez apporter.

Peu à peu, le sens de tout cela devrait devenir plus clair.

En ce qui concerne l'endroit pour commencer? Commencez avec ce que vous savez. Je suggère des entrées et des sorties. Vous pouvez souvent savoir ce qu’ils sont censés être et à quoi ils servent. Suivez les données via l'application et voyez où elles vont et comment elles sont modifiées.

Un des problèmes que j'ai avec tout ça, c'est la motivation - ça peut être un vrai boulot. Cela m’aide à penser l’ensemble de l’entreprise comme un casse-tête et à célébrer les progrès que je réalise, aussi petits soient-ils.

Votre situation est réellement commune. Toute personne qui doit entrer dans un nouvel emploi où il existe un code existant doit en traiter un élément. Si le système est un système hérité vraiment méchant, alors il ressemble beaucoup à ce que vous avez décrit. Bien sûr, il n'y a jamais de documentation actuelle.

Premièrement, beaucoup ont recommandé de travailler efficacement avec Legacy Code de Michael Feathers. C'est en effet un bon livre, avec des chapitres utiles tels que "Je ne peux pas intégrer cette classe à un harnais de test" ou "Mon application n'a pas de structure", bien que parfois Feathers puisse seulement offrir plus de sympathie que de solution. En particulier, le livre et ses exemples sont en grande partie destinés aux langages d'accolades. Si vous travaillez avec des procédures SQL noueuses, cela risque de ne pas être aussi utile. Je pense que le chapitre "Je ne comprends pas assez bien ce code pour le changer" parle de votre problème. Feathers mentionne ici des choses évidentes telles que la prise de notes et le balisage de listes, mais souligne également le fait que vous pouvez supprimer le code inutilisé si vous avez le contrôle de code source. Beaucoup de gens laissent des sections de code commentées en place,

Ensuite, je pense que votre approche suggérée est certainement une bonne étape. Vous devez d'abord comprendre à un niveau élevé quel est l'objectif du code.

Travaillez certainement avec un mentor ou un membre de l’équipe si vous devez répondre à des questions.

En outre, profitez de l’opportunité de supporter le code si des défauts sont révélés (même si parfois vous n’avez pas à vous porter volontaire pour cela… le défaut vous trouvera!). Les utilisateurs peuvent expliquer pourquoi ils utilisent le logiciel et en quoi le défaut les affecte. Cela peut souvent être un élément de connaissance très utile lorsque vous essayez de comprendre la signification du logiciel. De plus, entrer dans le code avec une cible déterminée à attaquer peut parfois vous aider à vous concentrer lorsque vous faites face à "la bête".

J'aime faire ce qui suit quand j'ai un très gros fichier source:

• Copier tout le bazar dans le presse-papier
• Coller dans Word / textmate
• Réduisez la taille de la police au minimum.
• Faites défiler vers le bas en regardant les modèles dans le code

Vous seriez surpris de voir à quel point le code est étrangement familier lorsque vous revenez dans votre éditeur normal.

Ça prend du temps

Ne vous sentez pas trop pressé lorsque vous essayez de comprendre une base de code héritée, en particulier si elle utilise des technologies / langages / frameworks avec lesquels vous n'êtes pas familier. C'est juste une courbe d'apprentissage inévitable qui prend du temps.

Une approche consiste à effectuer des va-et-vient entre le code et les tutoriels sur les technologies associées. Vous lisez / regardez le didacticiel, puis consultez le code pour voir comment vos prédécesseurs l'ont fait, en notant les similitudes et les différences, en prenant des notes et en posant des questions aux développeurs existants.

"Pourquoi as-tu fait cette partie de cette façon"

"J'ai remarqué que la plupart des gens en ligne le font de cette façon, et vous l'avez tous fait d'une autre façon. Pourquoi est-ce?"

"Qu'est-ce qui vous a poussé à choisir la technologie X plutôt que la technologie Y?"

Les réponses à ces questions vous aideront à comprendre l'historique du projet et le raisonnement qui sous-tend les décisions de conception et de mise en œuvre.

Finalement, vous vous sentirez assez familier pour pouvoir commencer à ajouter / corriger des choses. Si tout vous semble confus ou qu'il semble y avoir trop de "magie", vous n'avez pas passé assez de temps à regarder, digérer et schématiser. La création de diagrammes (diagrammes de séquence, diagrammes de flux de processus, etc.) est un excellent moyen de comprendre un processus complexe. En outre, ils aideront le «prochain type».

cscope peut faire tout ce que ctags peut faire pour C, il peut également indiquer où toutes les fonctions actuelles sont appelées. En plus c'est très rapide. Échelle facilement à des millions de LOC. S'intègre parfaitement à Emacs et Vim.

Compteur de code C et C ++ - cccc peut générer des métriques de code au format html. J'ai utilisé wc aussi pour obtenir LOC.

doxygen peut générer la syntaxe surlignée et le code référencé en HTML. Utile pour parcourir une base de code volumineuse.

Comme je le recommande avec Drupal et ce n’est pas vraiment spécifique à Drupal: commencez par le suivi des problèmes. Il y aura certainement d'anciens rapports de bogues non fermés. Pouvez-vous les reproduire? Si oui, mettez à jour le ticket en le confirmant. Si non, fermez-le. Vous trouverez de cette manière une multitude de façons d'utiliser le logiciel et vous pourrez commencer à jeter un coup d'œil dans la base de code où il se bloque. Ou vous pouvez commencer à parcourir le code et voir comment il arrive à l'endroit où il se bloque. De cette façon, vous ne commencerez pas seulement à comprendre le code, mais vous accumulerez également une tonne de karma et vos questions seront chaleureusement accueillies par la communauté.

Une chose importante à faire est d'utiliser des outils pour générer des graphiques de dépendance dans une architecture de code d'exploration descendante. Tout d’abord, visualisez un graphe entre des assemblys ou des binaires .NET, cela vous donnera une idée de la manière dont les fonctionnalités et les couches sont organisées, puis explorez les dépendances des espaces de noms (dans un ou plusieurs assemblys ou binaires .NET apparentés) pour avoir une idée plus précise du code. structure et enfin, vous pouvez consulter les dépendances de classes pour comprendre comment un ensemble de classes collabore pour implémenter une fonctionnalité. Il existe plusieurs outils pour générer un graphe de dépendance, comme NDepend pour .NET par exemple, qui a généré le graphe ci-dessous.

Un jour, un ingénieur logiciel assez fantastique m'a dit que la forme la plus chère d'analyse et de maintenance du code consistait à parcourir le code, ligne par ligne; Bien sûr, nous sommes des programmeurs, et cela vient pratiquement avec le travail. Le bon moyen, je pense, est de (dans cet ordre): 1. Demandez à un cahier de créer des notes expliquant comment vous comprenez que le code fonctionne, et ajoutez-le à mesure que le temps passe 2. Consultez la documentation sur le code 3. Parlez aux auteurs ou à d’autres personnes qui ont pris en charge la base de code. Demandez-leur un "brain dump" 4. Si vous êtes au point de comprendre certaines relations de classe de niveau de détail, effectuez un débogage progressif du code afin de faire une synthèse entre la façon dont vous pensiez que le code fonctionne et: comment le code fonctionne réellement.

D'abord, comprenez ce que c'est censé faire - sans cela, c'est du charabia. Parlez aux utilisateurs, lisez le manuel, peu importe.

Puis appuyez sur Exécuter et commencez à parcourir le code pour ce qui semble être les fonctions clés.

Diviser et conquérir. Je regarde chaque fonctionnalité et le code associé, passe en revue et passe à la suivante, construisant lentement une image de l'ensemble.

Si le projet comportait des tests unitaires, j'aime bien les passer en revue, ils sont toujours très révélateurs et instructifs.

1. Exécutez tous les tests, si vous en avez, et voyez quel code est couvert et lequel ne l'est pas.
2. Si le code que vous devez modifier n'est pas couvert, essayez d'écrire des tests pour le couvrir.
3. Changer le code. Ne pas casser les tests.

Voir Michael Feathers ' Travailler efficacement avec le code hérité'

Voici ma courte liste:

1. Si possible, demandez à quelqu'un de donner une vue d'ensemble du code. Quels modèles ont été pris en compte, quels types de conventions puis-je m'attendre à voir, etc. Cela peut prendre quelques tours, car au début, j'aurais une histoire qui, à mesure que je me familiariserais avec le code, pourrait poser de nouvelles questions demander pendant que je travaille sur l'oignon du projet préexistant.

2. Exécutez le code et voyez à quoi ressemble le (s) système (s). Certes, il y a peut-être plus que quelques bugs, mais cela peut être utile pour avoir une idée de ce que ça fait. Il ne s'agit pas de changer le code, mais simplement de voir comment cela fonctionne. Comment différentes pièces s'assemblent-elles pour constituer un système global?

3. Recherchez des tests et d’autres indicateurs de la documentation de base pouvant vous aider à créer un modèle mental interne du code. C’est là que je suggérerais probablement au moins quelques jours à moins que la documentation et les tests soient extrêmement limités.

4. Dans quelle mesure est-ce que je connais les langages et les frameworks utilisés dans ce projet? L'importance ici est de faire la différence entre regarder certaines choses et aller dans la conversation: "Oui, vu cela une douzaine de fois auparavant et je le connais assez bien", et "Qu'est-ce qui est tenté ici? Qui a pensé que c'était une bonne idée?" genre de questions qui, bien que je ne les dise pas à voix haute, je les penserais surtout si je regarde un code hérité qui peut être assez fragile et que les personnes qui l'ont écrit ne sont pas disponibles ou ne se souviennent tout simplement pas pourquoi les choses ont été faites comme elles étaient. Pour les nouveaux domaines, il peut être intéressant de passer plus de temps à apprendre quelle est la structure et quels motifs puis-je trouver dans ce code.

Dernier point mais non le moindre: connaître les attentes des responsables du projet en ce qui concerne ce que vous êtes censé faire à chaque instant, à l'aide des quelques idées suivantes sur ce à quoi vous pouvez vous attendre:

• Ajoutez-vous de nouvelles fonctionnalités?
• Êtes-vous en train de corriger des bugs?
• Êtes-vous refactoring de code? Les normes sont-elles nouvelles pour vous ou sont-elles très familières?
• Êtes-vous censé vous familiariser avec la base de code?

J'essaie toujours de commencer par le point d'entrée dans le programme, car tous les programmes en ont un (par exemple, méthode principale, classe principale, init, etc.). Cela me permettra ensuite de voir ce qui commence et parfois comment les choses sont liées.

Après cela, je descends au sol. La base de données et DAO sont configurés quelque part, ce qui me permet de comprendre comment les choses sont stockées. Peut-être une sorte de classe d'instance globale est-elle également démarrée, et là je peux comprendre ce qui est stocké. Et avec de bons outils de réfraction, je peux savoir qui appelle quoi.

J'essaie ensuite de trouver où l'interface est configurée et gérée, car c'est le point d'entrée d'informations suivant. Les outils de réfraction, de recherche et de débogage facilitent ma recherche. Je peux alors comprendre où commence et finit le traitement de l'information, en parcourant tous les fichiers de classe.

J'essaie ensuite d'écrire le flux sur du papier, juste pour commencer par comprendre les choses. Le bouton d'envoi transmet à la vérification générique, qui est ensuite transmise à la base de données DAO ou à la base de données, puis stockée dans la base de données. C'est une simplification excessive de la plupart des applications, mais c'est l'idée générale. Stylo et papier sont extrêmement utiles ici, car vous pouvez tout noter rapidement et ne pas avoir à vous soucier du formatage dans un programme censé vous aider.

Je dirais que commencer par la documentation, etc., mais selon mon expérience, la profondeur de la documentation et des connaissances locales est souvent inversement proportionnelle à l'âge, à la taille et à la complexité d'un système.

Cela étant dit, j'essaie généralement d'identifier quelques threads fonctionnels. Par fonctionnel, je veux dire des choses comme se connecter, dresser une liste de clients, etc. Si les modèles sont cohérents, un seul thread devrait vous donner une belle section, pas nécessairement complète, du système. Le meilleur moyen de déterminer si les modèles sont cohérents consiste à analyser une poignée de threads.

Je pense que cela va sans dire mais, à mon avis, il est préférable de comprendre le système d'un point de vue fonctionnel plutôt que d'un point de vue technique. En général, je ne m'inquiète pas trop des outils utilisés (ORM, bibliothèques de journalisation, etc.) et me concentre plus sur les modèles (MVP, etc.) utilisés. D'après mon expérience, les outils sont généralement plus fluides que les modèles.

J'ai tellement fait ...

Voici mon approche actuelle pour les situations où il y a "quelque chose qui fonctionne", et vous devez le faire "fonctionner d'une autre manière".

1. Obtenez des objectifs, ce système devrait résoudre (s'ils ne sont pas écrits) - écrivez-le. Demandez au responsable, aux autres employés, même anciens, s’ils sont disponibles. Demandez au client ou recherchez une pièce de documentation.
2. Obtenez la spécificatio. S'il n'existe pas, écrivez-le. Ce n'est pas la peine de demander à quelqu'un de le faire, comme si cela n'existait pas, alors vous êtes dans une situation où les autres ne s'en soucient pas beaucoup. Donc, seule façon d’écrire propre (plus tard, il sera beaucoup plus facile de s'y référer).
3. Obtenez le design. N'existe pas - écris-le. Essayez de vous référer le plus possible aux documents et au code source.
4. Rédigez une conception détaillée de la pièce à modifier.
5. Définissez comment vous le testez. Vous pouvez donc être sûr que l'ancien et le nouveau code fonctionnent de la même manière.
6. faire en sorte que le système puisse être construit en une étape. Et testez avec l'ancien code. Mettez-le à SVC s'il ne l'est pas déjà.
7. Implémenter des changements. Pas avant.
8. vérifiez au bout d'un mois que rien n'est cassé.

Encore une tâche facultative qui peut nécessiter entre chaque étape: le gestionnaire de projet (propriétaire du projet) qui vous indique que "ces modifications doivent déjà être effectuées hier". Après quelques projets, il peut même commencer à aider à obtenir des spécifications et des documents à l'avance.

Mais généralement (surtout pour les scripts), cela n’est tout simplement pas possible dans le champ d’activité (le coût sera trop élevé, alors que la valeur sera trop faible). Une option consiste à ne pas apporter de modifications avant que la masse critique ne soit atteinte et que le système ne soit plus en production (par exemple, un nouveau système viendra) ou que la direction ait décidé que tout cela en valait la peine.

PS: Je me souviens d'un code utilisé pour 5 clients avec des paramètres différents. Et chaque changement (nouvelle fonctionnalité) nécessitait de penser "quelles parties sont utilisées" et "quelle configuration ont les clients" afin de ne rien freiner et de ne pas copier le code. Définir leurs paramètres pour projeter CVS et rédiger des spécifications réduit ce temps de réflexion à presque 0.

Imprimez le code source et commencez à le lire. S'il est particulièrement volumineux, n'en imprimez que des parties sélectionnées pour mieux le comprendre et rédigez autant de notes / commentaires que nécessaire.

Parcourez le programme en partant du début de son exécution. Si vous êtes affecté à une partie particulière de la base de code, tracez l'exécution dans cette partie et déterminez quelles structures de données sont utilisées.

Si vous utilisez un langage orienté objet, essayez de créer un diagramme de classes général. Cela vous donnera un bon aperçu de haut niveau.

Malheureusement, à la fin, vous devrez lire autant de code que possible. Si vous êtes chanceux, les programmeurs précédents ont écrit autant de documentation que possible pour vous aider à comprendre ce qui se passe.

La première chose à faire pour apprendre une nouvelle base de code est d’apprendre ce qu’elle est censée faire, comment elle est utilisée et comment l’utiliser. Commencez ensuite par consulter la documentation architecturale pour connaître la structure du code, ainsi que la base de données. En même temps, vous apprenez l'architecture, c'est un bon moment pour examiner tous les flux de processus ou documents d'utilisation. Commencez ensuite à lire et à lire le code une fois que vous avez compris la situation dans son ensemble, mais que seul le code associé à tout travail que vous effectuez sur ce code ne doit pas simplement essayer de lire tout le code. Il est plus important de savoir où le code doit faire X que de savoir comment X est fait, le code est toujours là pour vous dire comment vous pouvez le trouver.

Je trouve qu'essayer de lire et de lire du code sans avoir d'autre objectif que d'apprendre le code est généralement improductif, essayer de faire de petits changements vous-même ou revoir le code des changements de quelqu'un d'autre est une utilisation beaucoup plus productive de votre temps.

Si une base de code est volumineuse, concentrez votre attention sur les parties sur lesquelles vous travaillez. Sinon, vous vous sentirez submergé et votre tête pourrait exploser. Je pense qu'une vue d'ensemble de haut niveau est utile (si elle est disponible), mais il est probable que vous passiez beaucoup de temps dans le débogueur pour suivre le déroulement du programme. C'est une bonne idée d'avoir une vue d'ensemble de l'application et de la voir utilisée afin de comprendre comment / quoi / pourquoi le code est utilisé.

J'utilise généralement un outil de complexité du code pour me dire où sont les problèmes. Les zones qui obtiennent un score élevé sont probablement très difficiles à mettre à jour. Par exemple, je suis tombé sur une fonction qui a marqué 450 sur l’échelle cyclomatique. Effectivement, des centaines de FI. Très difficile à maintenir ou à changer. Alors préparez-vous au pire.

Aussi, n’ayez pas peur de poser des questions aux développeurs existants, surtout s’ils ont travaillé sur le système. Gardez vos pensées internes pour vous et concentrez-vous sur la résolution des problèmes. Évitez les commentaires qui pourraient déranger les autres développeurs. Après tout, c’est peut-être leur bébé et personne n’aime à se faire dire que leur bébé est moche.

Faites de petits pas, même le plus petit changement de code peut avoir un impact important.

Je trouve qu'il est utile de créer des flux de code de programme. Ainsi, si je fais des modifications, je peux faire des recherches de dépendance pour voir quelles méthodes / fonctions appellent quoi. Supposons que je change de méthode C.

Si seulement 1 méthode / fonction appelle C, il s'agit d'un changement relativement sûr. Si des centaines de méthodes / fonctions appellent C, l'impact serait plus grand.

J'espère que votre base de code est bien conçue, écrite et maintenue. Si tel est le cas, il faudra un certain temps pour le comprendre, mais la tendance sera finalement inversée.

Si c'est une grosse boule de boue, il est possible que vous ne compreniez jamais (ou ne vouliez pas comprendre) son fonctionnement interne.

Certaines choses que je fais ...

1) Utilisez un outil d’analyse de source tel que Source Monitor pour déterminer les différentes tailles de module, métriques de complexité, etc., afin de vous familiariser avec le projet et d’aider à identifier les domaines non triviaux.

2) Parcourez le code de haut en bas dans Eclipse (ce qui est bien d’avoir un éditeur capable de parcourir les références, etc.) jusqu’à ce que je sache ce qui se passe et où dans la base de code.

3) Parfois, je dessine des diagrammes dans Visio pour obtenir une meilleure image de l'architecture. Cela peut également être utile pour d’autres personnes participant au projet.

Cela arrive souvent. Jusqu'à ce que je commence à travailler sur une plate-forme open source, je ne pensais pas avoir jamais commencé un travail qui ne soit pas né avec l'aveu que le code avait quelques «bizarreries».

Vous pouvez obtenir un long chemin avec un débogueur de pas et beaucoup de ténacité. Malheureusement, il faut souvent du temps et de l'expérience pour apprendre une grosse boule de boue. Même après des années, il peut toujours exister un sous-système dont personne n'a la connaissance.

Je vous encourage à écrire des tests unitaires avant de changer quoi que ce soit dans la boule de boue. Et ne changez que suffisamment de code à l’époque pour réussir les tests. Lorsque vous effectuez une refactorisation, ajoutez des tests unitaires à l'avance pour que vous sachiez que la fonctionnalité métier n'a pas été interrompue par la refactorisation.

La programmation en binôme est-elle une option? Avoir une autre personne pour échanger des idées est une excellente idée pour gérer cette quantité de méchant.

Voici une procédure que nous utilisons pour éliminer les doublons.

• sélectionnez un préfixe de commentaire standard pour les doublons (nous l'utilisons [dupe]juste après le marqueur de commentaire;
• rédigez des spécifications avec vos équipes sur les noms à utiliser pour la procédure de duplication;
• premier tour: tout le monde prend des fichiers et ajoute [dupe][procedure_arbitrary_name]avant la procédure dupliquée;
• deuxième tour: tout le monde prend une procédure, ou un sous-ensemble de procédure, et attribue une valeur indiquant l'ordre de similarité des différentes implémentations ayant le même objectif (la chaîne sera alors:) [dupe][procedure_arbitrary_name][n];
• troisième tour: le responsable de chaque procédure la réécrit dans la classe appropriée;
• quatrième tour: grepheureux!

Je pense que l’une des choses les plus importantes est de prendre une fonctionnalité simple, de choisir la plus simple possible et de la mettre en œuvre. Si la liste de souhaits est maintenue, utilisez-la ou contactez une personne familiarisée avec la base de code et demandez-lui de vous suggérer une fonctionnalité. D'habitude, je m'attendrais à ce que ce soit un changement avec 5 ~ 20 LOC. Le point important n’est pas que vous ajoutiez une fonctionnalité très sophistiquée, mais que vous travailliez (ou plutôt vous attaquiez :)) avec la base de code et suiviez tout le flux de travail. Vous auriez à

1. Lisez le code pour comprendre le composant que vous modifiez.
2. Changez de code et comprenez son impact sur le système environnant.
3. Testez le changement et identifiez ainsi l'interaction des composants
4. Ecrivez le scénario de test et, espérons-le, séparez un ou deux scénarios de test pour pouvoir les résoudre et comprendre les invariants du système.
5. Construisez la chose ou voyez l'IC la construire puis l'expédier

La liste est longue, mais un mini-projet comme celui-ci vous guide dans tous les éléments de votre liste de contrôle pour vous familiariser avec un système et permet également un changement productif.

Une petite chose que je voulais ajouter:

Un outil que j'ai commencé à utiliser récemment pour résoudre ce type de problème qui a énormément aidé est la cartographie conceptuelle. Au lieu d’essayer d’entasser tous les détails de la mise en œuvre de quelque chose dans ma tête, je vais construire une carte conceptuelle décrivant le fonctionnement du système que je suis en train de vivre. Cela m'aide vraiment à comprendre plus profondément ce qui se passe et ce qu'il me reste à comprendre. Cela me permet également de garder une trace de ce que je dois changer à une échelle très précise.

Je recommande d'utiliser l'avion libre parmi la pléthore de choix de cartographie de l'esprit.

Il n'y aura pas de documentation ou il y aura peu de documentation, ou elle sera périmée. Trouvez toute la documentation existante. Si c'est dans un référentiel d'équipe, ne faites pas de copie. Sinon, mettez-le là et demandez à votre responsable l'autorisation de l'organiser, éventuellement avec un peu de supervision.

Obtenez tout dans le référentiel pour l'équipe et ajoutez un glossaire. Toutes les bases ont du jargon; documentez-le dans le glossaire. Faire des sections pour les outils, produits, spécifiques au client, etc.

Créer / Mettre à jour un document de création d'environnement logiciel. Tous les outils, bizarreries, choix d'installation, etc. vont ici.

Ensuite, téléchargez un document de mise en route "ProductName" ou similaire. Que ce soit juste un flux de pensée et une auto-organisation dans le temps. Puis parcourez les documents périmés et remettez-les à jour. Les autres développeurs l'apprécieront, vous contribuerez de manière unique tout en apprenant le code. Documentez en particulier toutes les choses qui vous bloquent ou sont mal désignées ou qui sont contre-intuitives.

Une fois que votre courbe inclinée se termine, ne vous inquiétez pas pour la mise à jour de la documentation. Laissez le prochain nouveau gars faire ça. Quand il arrive, dirigez-le vers votre travail. Quand il vous demande constamment des réponses, ne lui répondez pas. Ajoutez plutôt la question à votre documentation, puis donnez-lui l'URL. Canne à pêche.

Un des effets secondaires est que vous aurez créé un outil auquel vous pourrez vous référer vous-même dans les mois à venir.

Et bien que ce ne soit pas de la documentation, un problème connexe est constitué par les procédures peu manuelles et intensives de vos collègues. Automatisez-les avec des lots, des scripts SQL, etc., et partagez-les également. Après tout, la connaissance procédurale est sans doute aussi importante que la connaissance déclarative pour devenir productive dans un nouvel environnement. Quoi que ce soit, ne le fais pas; écrivez plutôt le script et exécutez le script. La canne à pêche frappe à nouveau.

J'ai écrit un article assez long sur ce sujet. Voici un extrait

J'ai réfléchi à ce problème pendant un bon moment. J'ai décidé de rédiger ma propre solution personnelle en tant que processus général. Les étapes que j'ai documentées sont les suivantes:

1. Créer une feuille de vocabulaire
2. Apprendre l'application
3. Parcourir la documentation disponible
4. Faire des hypothèses
5. Localiser les bibliothèques tierces
6. Analyser le code

Ce processus est écrit dans le contexte d'une application de bureau volumineuse, mais les techniques générales restent applicables aux applications Web et aux modules plus petits.

tiré de: Un processus d'apprentissage Une nouvelle base de code

Il y a quelques petits conseils que je peux partager.

Pour un produit existant, je commence à les tester de manière intensive. Si vous choisissez / obtenez une tâche, je me concentrerai davantage sur cette fonctionnalité.

• La prochaine étape serait de trouver le code où je pourrais entrer et commencer à explorer En chemin, je trouverai les modules dépendants, les bibliothèques, les frameworks, etc.

• La prochaine étape serait de créer un diagramme de classes simple avec ses responsabilités (comme les cartes CRC)

• Commencez par apporter des modifications mineures ou corrigez des bogues mineurs. Ainsi, nous pouvons apprendre le flux de travail du projet; pas seulement le code. Souvent, les gros produits ont une comptabilité en guise d’autorisation et d’audits (projets de santé, par exemple).

• Parlez aux personnes qui travaillent déjà sur le projet. Exprimez vos idées, vos pensées et obtenez en retour leur expérience et leurs points de vue sur le fait de travailler avec ce projet pendant longtemps. Ceci est très important car cela vous aide également à bien vous entendre avec l'équipe.

Cela fait longtemps que je n'ai pas eu à plonger moi-même dans une grande base de code. Mais au cours des dernières années, j'ai souvent essayé de faire entrer de nouveaux développeurs dans des équipes où nous disposions d'une base de code existante plutôt volumineuse.

Et la méthode que nous avons utilisée avec succès, et je dirais que c'est le moyen le plus efficace sans poser de questions à mon humble avis, est la programmation en paires.

Au cours des 12 derniers mois, nous avons eu 4 nouveaux membres dans l’équipe, et chaque fois, le nouveau membre était jumelé avec un autre membre connaissant bien la base de code. Au début, le membre le plus âgé de l'équipe aurait le clavier. Après environ 30 minutes, nous passions le clavier au nouveau membre, qui travaillerait sous la direction du membre le plus âgé de l'équipe.

Ce processus s'est avéré assez réussi.