Comment plonger dans de grandes bases de code?
Quels outils et techniques utilisez-vous pour explorer et apprendre une base de code inconnue?
Je pense à des outils comme grep, ctags, des tests unitaires, des tests fonctionnels, des générateurs de diagrammes de classes, des graphes d'appel, des métriques de code comme sloccount, etc. Je serais intéressé par vos expériences, les aides que vous avez utilisées ou écrites vous-même et la taille de la base de code avec laquelle vous avez travaillé.
Je me rends compte que se familiariser avec une base de code est un processus qui se produit au fil du temps, et la familiarité peut signifier n'importe quoi de "je suis capable de résumer le code" à "je peux refactoriser et le réduire à 30% de la taille". Mais comment même commencer?
ce que j'ai toujours fait est le suivant:
Ouvrez plusieurs copies de mon éditeur (Visual Studio/Eclipse/Whats), puis déboguez 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 allez-y.
Je peux regarder méthode après méthode - mais c'est bien si je peux cliquer sur quelque chose et voir où dans le code il est exécuté et suivre. Permettez-moi de comprendre comment 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 le travail soit fait
Dans une large mesure, oui (désolé).
Approches que vous pourriez envisager:
- Essayez de découvrir ce que le code est censé faire, en termes commerciaux.
- Lisez toute la documentation qui existe, quelle que soit sa gravité.
- Parlez à quelqu'un qui pourrait savoir quelque chose sur le code.
- Parcourez le code dans le débogueur.
- Introduisez de petits changements et voyez ce qui casse.
- Apportez de petites modifications au code pour le rendre plus clair.
Certaines des choses que je fais pour clarifier le code sont:
- Exécutez un prettifier de code pour formater le code correctement.
- Ajoutez des commentaires pour expliquer ce que je pense que cela pourrait faire
- Modifier les noms de variables pour les rendre plus clairs (à l'aide d'un outil de refactoring)
- Utiliser un outil qui met en évidence toutes les utilisations d'un symbole particulier
- Réduire l'encombrement dans le code - code mis en commentaire, commentaires sans signification, initialisations de variables inutiles, etc.
- Modifier le code pour utiliser les conventions de code actuelles (à nouveau en utilisant des outils de refactoring)
- Commencez à extraire des fonctionnalités dans des routines significatives
- Commencez à ajouter des tests lorsque cela est possible (pas souvent possible)
- Débarrassez-vous des nombres magiques
- Réduire la duplication lorsque cela est possible
... et toutes les autres améliorations simples que vous pouvez apporter.
Progressivement, le sens derrière tout cela devrait devenir plus clair.
Quant à l'endroit où commencer? Commencez par ce que vous savez. Je suggère des entrées et des sorties. Vous pouvez souvent obtenir une idée de ce que ceux-ci sont censés être et de leur utilisation. Suivez les données dans l'application et voyez où elles vont et comment elles sont modifiées.
L'un des problèmes que j'ai avec tout cela est la motivation - cela peut être un vrai slog. Cela m'aide à considérer l'ensemble de l'entreprise comme un casse-tête et à célébrer les progrès que je fais, aussi petits soient-ils.
Votre situation est en fait courante. Quiconque doit entrer dans un nouvel emploi où il existe du code avec lequel travailler va en traiter un élément. Si le système est un système hérité vraiment méchant, il ressemble beaucoup à ce que vous avez décrit. Bien sûr, il n'y a jamais de documentation à jour.
Tout d'abord, beaucoup ont recommandé Travailler efficacement avec Legacy Code par Michael Feathers. C'est en effet un bon livre, avec des chapitres utiles comme "Je ne peux pas mettre cette classe dans un harnais de test" ou "Mon application n'a pas de structure" bien que parfois les plumes ne peuvent offrir que plus de sympathie que de solution. En particulier, le livre et ses exemples sont largement adaptés aux langues des accolades. Si vous travaillez avec des procédures SQL noueuses, cela peut ne pas être aussi utile. Je pense que le chapitre, "Je ne comprends pas assez bien ce code pour le changer", traite de votre problème. Feathers mentionne ici les choses évidentes telles que la prise de notes et le balisage des listes, mais souligne également que vous pouvez supprimer le code inutilisé si vous avez le contrôle de source. Beaucoup de gens laissent des sections de code commentées en place, mais ce n'est souvent pas utile.
Ensuite, je pense que votre approche suggérée est certainement une bonne étape. Vous devez d'abord comprendre à un niveau élevé quel est le but du code.
Travaillez certainement avec un mentor ou un membre de l'équipe si vous devez obtenir des réponses aux questions.
Profitez également de l'occasion pour prendre en charge le code si des défauts sont révélés (bien que parfois vous n'ayez pas à vous porter volontaire pour cela ... le défaut vous trouvera!). Les utilisateurs peuvent expliquer pourquoi ils utilisent le logiciel et comment le défaut les affecte. Cela peut souvent être une connaissance très utile lorsque vous essayez de comprendre la signification du logiciel. De plus, entrer dans le code avec une cible ciblée pour attaquer peut parfois vous aider à vous concentrer face à "la bête".
J'aime faire ce qui suit quand j'ai un très gros fichier source:
- Copiez tout le désordre dans le presse-papiers
- Coller dans Word/textmate que ce soit
- 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 étonné de voir à quel point le code semble étrangement familier lorsque vous revenez à votre éditeur normal.
Ça prend du temps
Ne vous sentez pas trop pressé en essayant de comprendre une base de code héritée, surtout s'il utilise des technologies/langages/frameworks que vous ne connaissez pas. C'est juste une courbe d'apprentissage inévitable qui prend du temps.
Une approche consiste à faire des allers-retours entre le code et les didacticiels sur les technologies associées. Vous lisez/regardez le didacticiel, puis regardez le code pour voir comment vos prédécesseurs l'ont fait, notant les similitudes et les différences, prenant des notes et posant des questions à tous les développeurs existants.
"Pourquoi avez-vous 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 manière. Pourquoi?"
"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 derrière les décisions de conception et de mise en œuvre.
Finalement, vous vous sentirez suffisamment familier avec lui pour pouvoir ajouter/corriger des choses. Si tout cela semble déroutant ou s'il semble qu'il y ait trop de "magie" en cours, vous n'avez pas passé assez de temps à le regarder, à le digérer et à le schématiser. La création de diagrammes (diagrammes de séquence, diagrammes de flux de processus, etc.) est un excellent moyen pour vous de comprendre un processus complexe, en plus ils aideront le "gars suivant".
cscope peut faire tout ce que ctags peut faire pour C, en plus, il peut aussi lister où toutes les fonctions en cours sont appelées. De plus, c'est très rapide. S'adapte 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 également utilisé wc pour obtenir LOC.
doxygen peut générer la syntaxe mise en évidence et le code de référence croisée en html. Utile pour parcourir une grande base de code.
La façon dont je recommande avec Drupal et ce n'est pas vraiment Drupal spécifique: commencez par le suivi des problèmes. Il y aura certainement de vieux 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 façon une tonne de façons d'utiliser le logiciel et vous pouvez commencer à jeter un œil dans la base de code où il se bloque. Ou vous pouvez commencer à l'étape à travers le code et voyez comment il arrive à l'endroit où il se bloque. De cette façon, vous commencerez non seulement à comprendre la base de code, mais aussi à accumuler 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 pour explorer de haut en bas l'architecture de code. Visualisez d'abord le graphique entre les assemblys ou les pots .NET, cela vous donnera une idée de la façon dont les fonctionnalités et les couches sont organisées, puis creusez dans les dépendances des espaces de noms (à l'intérieur d'un ou de quelques assemblages ou pots .NET apparentés) pour avoir une idée plus précise du code structure et enfin vous pouvez regarder les dépendances des classes pour comprendre comment un ensemble de classes collabore pour implémenter une fonctionnalité. Il existe plusieurs outils pour générer un graphique de dépendance, comme NDepend for .NET par exemple, qui a généré le graphique ci-dessous.
Un jour, un ingénieur logiciel assez fantastique m'a dit que la forme la plus coûteuse d'analyse et de maintenance du code consistait à parcourir le code ligne par ligne; bien sûr, nous sommes des programmeurs, et cela vient à peu près avec le travail. Le juste milieu, je pense, est de (dans cet ordre): 1. Obtenir un cahier pour créer des notes sur la façon dont vous comprenez le code et y ajouter au fil du temps 2. Reportez-vous à la documentation sur le code 3. Parlez aux auteurs ou autres qui ont pris en charge la base de code. Demandez-leur un "brain dump" 4. Si vous êtes au point où vous comprenez certaines des relations de classe de niveau détail, faites un débogage pas à pas du code pour faire une synthèse entre la façon dont vous pensiez que le code fonctionne et comment le code fonctionne réellement.
Tout d'abord, comprenez ce que cela est censé faire - sans quoi il est probable que ce soit du charabia. Parlez aux utilisateurs, lisez le manuel, peu importe.
Ensuite, 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é, je les passe en revue et je passe à la suivante, en construisant lentement une image de l'ensemble.
Si le projet a eu des tests unitaires, j'aime aussi les parcourir, ils sont toujours très révélateurs et instructifs.
- Exécutez tous les tests, si vous en avez, et voyez quel code est couvert et lequel ne l'est pas.
- Si le code que vous devez modifier n'est pas couvert, essayez d'écrire des tests pour le couvrir.
- Modifiez le code. Ne cassez pas les tests.
Voir Michael Feathers 'Travailler efficacement avec Legacy Code
Voici ma courte liste:
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 avoir quelques tours car au début j'aurais une histoire qui, au fur et à mesure que je me familiariserais avec le code, je pourrais avoir de nouvelles questions demander pendant que je travaille à travers l'oignon du projet préexistant.
Exécutez le code et voyez à quoi ressemblent les systèmes. Certes, il peut y avoir plus de quelques bugs, mais cela peut être utile pour avoir une idée de ce qu'il fait. Il ne s'agit pas de changer le code, mais plutôt de voir comment cela fonctionne. Comment les différentes pièces s'assemblent-elles pour former un système global?
Recherchez des tests et d'autres indicateurs de la documentation de base qui peuvent aider à construire un modèle mental interne du code. C'est là que je suggérerais probablement au moins quelques jours à moins qu'il n'y ait bien sûr très peu de documentation et de tests.
Dans quelle mesure je connais les langages et les frameworks utilisés dans ce projet? L'importance ici est la différence entre regarder certaines choses et dire "Oui, vu une douzaine de fois auparavant et le sais assez bien" et "Qu'est-ce qui est tenté ici? Qui a pensé que c'était une bonne idée?" genre de questions que même si je ne les disais pas à haute voix, 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 utile de consacrer un peu de temps à découvrir quelle est la structure et quels modèles puis-je trouver dans ce code.
Dernier point mais non des moindres: connaître les attentes de ceux qui dirigent le projet en termes de ce que vous êtes censé faire à chaque moment, compte tenu des quelques idées suivantes sur ce à quoi on peut s'attendre:
- Mettez-vous de nouvelles fonctionnalités?
- Corrigez-vous des bugs?
- Êtes-vous en train de refactoriser le code? Les normes sont-elles nouvelles pour vous ou sont-elles très familières?
- Êtes-vous censé simplement vous familiariser avec la base de code?
Je dirais de commencer par la documentation, etc., mais d'après 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 la connexion, la liste déroulante des clients, etc. La meilleure façon de déterminer si les modèles sont cohérents consiste à analyser une poignée de threads.
Je pense que cela va de soi mais, à mon avis, il vaut mieux 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 je me concentre davantage 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.
Imprimez le code source et commencez à le lire. S'il est particulièrement volumineux, n'en imprimez que certaines parties pour mieux le comprendre et faire autant de notes/commentaires que nécessaire.
Suivez le programme à partir 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 classe 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.
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 montrera ensuite ce qui commence et parfois comment les choses sont liées.
Après cela, j'explore. La base de données et DAO sont configurés quelque part, donc j'ai une idée de la façon dont les choses sont stockées. Peut-être qu'une sorte de classe d'instance globale est également lancé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 prochain point d'entrée des informations. Les outils de réfraction, de recherche et de débogage facilitent ma recherche. Je peux alors déterminer où commence et se termine le traitement des informations, en parcourant tous les fichiers de classe.
J'essaie ensuite d'écrire le flux sur du papier, juste pour envelopper d'abord ma tête autour des choses. Le bouton Soumettre passe à la vérification générique qui est ensuite transmise au DAO ou à la base de données, puis stockée dans la base de données. Il s'agit d'une simplification grossière de la plupart des applications, mais c'est l'idée générale. Le stylo et le papier sont extrêmement utiles ici, car vous pouvez tout noter rapidement et ne pas avoir à vous soucier du formatage dans un programme qui était censé vous aider.
Certaines choses que je fais ...
1) Utilisez un outil d'analyse de source comme Moniteur source pour déterminer les différentes tailles de module, les mesures de complexité, etc. pour avoir une idée du projet et aider à identifier les domaines qui ne sont pas triviaux.
2) Parcourez le code de haut en bas dans Eclipse (bon d'avoir un éditeur qui peut 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 en Visio pour obtenir une meilleure image de l'architecture. Cela peut également être utile pour d'autres sur le projet.
La première chose que vous devez faire lors de l'apprentissage d'une nouvelle base de code est de savoir ce qu'elle est censée faire, comment elle est utilisée et comment l'utiliser. Ensuite, commencez à regarder la documentation architecturale pour savoir comment le code est présenté, regardez également comment la base de données à ce stade. En même temps, vous apprenez l'architecture, c'est le bon moment pour examiner les flux de processus ou utiliser les documents de cas. commencez ensuite à plonger et à lire le code après avoir compris la situation dans son ensemble, mais uniquement le code lié à tout travail que vous pourriez faire sur ce code, n'essayez pas simplement de lire tout le code. Il est plus important de savoir où le code doit faire X que comment X est fait, le code est toujours là pour vous dire comment le trouver.
Je trouve qu'essayer d'intervenir et de lire du code sans but au-delà de l'apprentissage du code est généralement improductif, essayer de faire vous-même de petits changements 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 actuellement. Sinon, vous vous sentirez dépassé et votre tête pourrait exploser. Je pense qu'un aperçu de haut niveau est utile (s'il est disponible), mais il est probable que vous passerez beaucoup de temps dans le débogueur pour suivre le déroulement du programme. C'est une bonne idée d'avoir un aperçu de l'application et de la voir utilisée, afin que vous puissiez comprendre comment/pourquoi/pourquoi le code est utilisé.
J'exécute généralement une sorte d'outil de complexité du code sur le code pour me dire où se trouvent les problèmes. Les domaines qui obtiennent un score élevé sont probablement très difficiles à mettre à jour. Par exemple, je suis tombé sur une fonction qui a obtenu 450 sur l'échelle cyclomatique. Effectivement, des centaines de FI. Très difficile à maintenir ou à changer. Alors préparez-vous au pire.
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 qu'on lui dise qu'il est moche.
Faites de petites étapes, même le plus petit changement de code peut avoir un impact important.
Je trouve qu'il est utile de trouver des flux de code de programme, donc si je fais des changements, je peux faire des recherches de dépendances pour voir quelles méthodes/fonctions appellent quoi. Supposons que je change de méthode C.
Si seulement 1 méthode/fonction appelle C, alors c'est un changement assez sûr. Si des centaines de méthodes/fonctions appellent C, alors cela aurait un plus grand impact.
Espérons que votre base de code soit bien architecturée, écrite et maintenue. Si c'est le cas, il faudra un certain temps pour le comprendre, mais finalement la marée sera inversée.
S'il s'agit d'une grosse boule de boue, vous ne comprendrez peut-être jamais (ou ne voudrez pas comprendre) son fonctionnement interne.
J'ai tellement fait ...
Voici mon approche actuelle pour les situations où "quelque chose fonctionne", et vous devez le faire "fonctionner d'une autre manière".
- Obtenez des objectifs, ce système devrait résoudre (s'ils ne sont pas écrits) - écrivez-le. Demandez au directeur, aux autres employés, même anciens s'ils sont disponibles. Demandez au client ou recherchez n'importe quel document.
- Obtenez la spécificité. S'il n'existe pas - écrivez-le. Cela ne vaut pas la peine de le demander à quelqu'un, comme s'il n'existait pas, alors vous êtes dans une situation où les autres s'en moquent beaucoup. Donc, seule façon d'écrire votre propre (plus tard, il sera beaucoup plus facile de s'y référer).
- Obtenez le design. N'existe pas - écrivez-le. Essayez de vous référer à tous les documents et au code source autant que possible.
- Écrivez la conception détaillée de la pièce que vous devez modifier.
- 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.
- faire en sorte que le système puisse être construit en une seule étape. Et testez avec l'ancien code. Mettez-le sur SVC s'il ne l'est pas déjà.
- Implémentez les changements. Pas avant.
- vérifiez après un mois environ que rien n'est cassé.
Une autre tâche facultative qui peut nécessiter entre chaque étape: f off manager (propriétaire du projet) qui vous dit que "ces changements doivent être effectués déjà hier". Après quelques projets, il peut même commencer à aider à obtenir des spécifications et des documents à l'avance.
Mais généralement (en particulier pour les scripts), cela n'est tout simplement pas possible dans le domaine d'activité (le coût sera trop élevé, tandis que la valeur sera trop faible). Une option consiste à ne pas apporter de modifications jusqu'à ce que la masse critique soit atteinte et que le système cesse de fonctionner (par exemple, un nouveau système arrivera) ou que la direction ait décidé que tout cela en valait la peine.
PS: Je me souviens d'un code qui a été utilisé pour 5 clients avec des paramètres différents. Et chaque changement (nouvelle fonctionnalité) était nécessaire en pensant à "quelles pièces sont utilisées" et à "quelle configuration les clients ont" afin de ne rien freiner, et de ne pas copier du code. La définition de leurs paramètres dans les cv du projet et l'écriture de spécifications réduisent ce temps de réflexion à presque 0.
Il n'y aura pas de documentation ou il y aura peu de documentation, ou elle sera obsolète. Retrouvez toute la documentation qui existe. S'il se trouve dans un référentiel d'équipe, n'en faites pas de copie. Sinon, mettez-le là et demandez à votre responsable la permission de l'organiser, peut-être avec une certaine supervision.
Obtenez tout dans le référentiel de l'équipe et ajoutez un glossaire. Toutes les bases ont du jargon; documentez-le dans le glossaire. Créez des sections pour les outils, les 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.
Téléchargez ensuite un document Mise en route avec "ProductName" ou similaire. Que ce soit juste un flux mental et une auto-organisation au fil du temps. Parcourez ensuite les documents obsolètes et remettez-les à jour. Les autres développeurs l'apprécieront, vous contribuerez d'une manière unique tout en apprenant le code. En particulier, documentez toutes ces choses qui vous tromperont ou sont mal nommées ou contre-intuitives.
Une fois que votre courbe d'inclinaison arrive à son terme, ne vous inquiétez pas de mettre à jour la documentation. Laissez le prochain nouveau gars faire ça. Quand il arrive, dirigez-le vers votre travail. Quand il vous embête continuellement pour des réponses, ne lui répondez pas. Ajoutez plutôt la question à votre documentation, puis remettez-lui l'URL. Canne à pêche.
Un effet secondaire est que vous aurez créé un outil que vous pourrez référencer dans des mois à partir de maintenant lorsque vous oublierez.
Et bien que ce ne soit pas de la documentation, un problème connexe concerne toutes les petites procédures originales et intensives que font vos coéquipiers. Automatisez-les avec des lots, des scripts SQL et autres, et partagez-les également. Après tout, les connaissances procédurales sont sans doute aussi importantes que les connaissances déclaratives en termes de productivité dans un nouvel environnement. Quoi qu'il en soit, ne le faites pas; au lieu de cela, créez un script et exécutez le script. La canne à pêche frappe à nouveau.
Cela arrive souvent. Jusqu'à ce que je commence à travailler sur une plate-forme open source, je ne pense pas avoir jamais commencé un travail qui n'a pas commencé avec l'admission que le code avait des "bizarreries".
Vous pouvez obtenir un long chemin avec un débogueur d'étape et beaucoup de ténacité. Malheureusement, il faut souvent du temps et de l'expérience pour apprendre une grosse boule de boue particulière et même après des années, il peut encore y avoir un sous-système qui apparaît et dont personne n'a la moindre connaissance.
Je pense que l'une des choses les plus importantes est de prendre une fonctionnalité simple, de choisir la plus simple à laquelle vous pouvez penser et de la mettre en œuvre. S'il y a une liste de souhaits maintenue, utilisez-la ou parlez-en à quelqu'un qui connaît la base de code et demandez-lui de suggérer une fonctionnalité. Habituellement, je m'attendrais à ce que ce soit un changement avec 5 ~ 20 LOC. L'important n'est pas que vous ajoutiez une fonctionnalité très sophistiquée mais que vous travaillez (ou plutôt grappling :)) avec la base de code et que vous parcouriez tout le workflow. Vous auriez à
- Lisez le code pour comprendre le composant que vous modifiez
- Changez le code et comprenez comment cela affecte le système environnant.
- Testez le changement et identifiez ainsi comment les composants interagissent entre eux
- Écrivez le cas de test et, espérons-le, cassez un ou deux cas de test afin de pouvoir les corriger et comprendre les invariants du système.
- Construisez la chose ou voyez le CI le construire puis expédiez-le
La liste est longue, mais le fait est qu'un mini-projet comme celui-ci vous fait parcourir tous les éléments de votre liste de contrôle pour vous familiariser avec un système et entraîne également un changement productif.
Une petite chose que je voulais ajouter:
Un outil que j'ai commencé à utiliser récemment pour ce type de problème qui a énormément aidé est la cartographie mentale. Au lieu d'essayer de saisir tous les détails de la façon dont quelque chose est implémenté dans ma tête, je vais construire une carte mentale décrivant le fonctionnement du système que je traverse. Cela m'aide vraiment à mieux comprendre ce qui se passe et ce que je dois encore comprendre. Cela m'aide également à garder une trace de ce que je dois changer à une échelle très précise.
Je recommande d'utiliser avion libre parmi la pléthore de choix de cartographie mentale.
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 comme un processus général. Les étapes que j'ai documentées sont les suivantes:
- Créer une feuille de vocabulaire
- Apprenez l'application
- Parcourir la documentation disponible
- Faire des hypothèses
- Localiser des bibliothèques tierces
- Analyser le code
Ce processus est écrit dans le contexte d'une grande application de bureau, mais les techniques générales sont toujours applicables aux applications Web et aux modules plus petits.
extrait de: n processus pour apprendre une nouvelle base de code
Je peux partager quelques petits conseils.
Pour un produit existant, je commence à les tester intensivement. Si vous choisissez/obtenez une tâche, je me concentrerai davantage sur la fonctionnalité particulière.
La prochaine étape serait de trouver le code où je peux pénétrer et commencer à explorer Sur le chemin, je trouverai les modules dépendants, les bibliothèques, les frameworks, etc.
La prochaine étape serait de créer un diagramme de classe simple avec ses responsabilités (comme les cartes CRC)
Commencez à apporter des modifications mineures ou à corriger des bogues mineurs à corriger et à valider. Ainsi, nous pouvons apprendre le flux de travail du projet; pas seulement le code. Souvent, les grands produits auront une sorte de tenue de livres à des fins d'autorisation et d'audits (par exemple, les projets de soins de santé)
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 travail avec ce projet pendant longtemps. C'est très important car cela vous aide également à bien vous entendre avec l'équipe.
Je vous encourage à écrire des tests unitaires avant de changer quoi que ce soit dans la boule de boue. Et seulement modifiez suffisamment le code à la fois pour faire passer les tests. Au fur et à mesure que vous refactorisez, ajoutez des tests unitaires avant de savoir que vous savez que la fonctionnalité commerciale n'a pas été interrompue par la refactorisation.
La programmation par paire est-elle une option? Avoir une autre personne pour faire rebondir ses idées est une excellente idée pour faire face à cette quantité de méchanceté.
Voici une procédure que nous utilisons pour éliminer les doublons.
- sélectionnez un préfixe de commentaire standard pour les doublons (nous utilisons
[dupe]juste après le marqueur de commentaire; - rédiger des spécifications avec vos équipes sur les noms à utiliser pour la procédure en double;
- 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 sympathie des différentes implémentations du même but (la chaîne sera alors:
[dupe][procedure_arbitrary_name][n]); - troisième tour: le responsable de chaque procédure le réécrit dans la classe concernée;
- quatrième tour:
grepheureux!
Cela fait longtemps que je n'ai pas moi-même dû plonger dans une grande base de code. Mais au cours des dernières années, j'ai essayé à plusieurs reprises de faire entrer de nouveaux développeurs dans des équipes où nous avions une base de code existante, assez importante.
Et la méthode que nous avons utilisée avec succès, et je dirais que c'est le moyen le plus efficace sans aucun doute à mon humble avis, est la programmation par paires.
Au cours des 12 derniers mois, nous avons eu 4 nouveaux membres dans l'équipe, et chaque fois, le nouveau membre s'apparierait avec un autre membre connaissant bien la base de code. Au début, le membre de l'équipe plus âgé aurait le clavier. Après environ 30 minutes, nous transmettions le clavier au nouveau membre, qui travaillerait sous la direction du membre le plus âgé de l'équipe.
Ce processus s'est avéré très efficace.
Ma façon d'étudier un grand projet de code est la suivante:
- faire le projet et l'utiliser.
- utilisez IDE pour ouvrir le projet. Par exemple: Eclipse ou Codelite. Puis utilisez IDE pour indexer tout le code source du projet).
- Utilisez IDE pour générer un diagramme de classes si le langage du projet prend en charge cette fonction.
- Trouvez la méthode principale, la méthode principale est une entrée du programme et la méthode principale est également une bonne entrée pour explorer le projet.
- Trouvez les structures de données et les fonctions principales du programme. Jetez un œil à la mise en œuvre.
- Modifiez du code du projet, faites-le et utilisez-le, regardez s'il fonctionne correctement! Vous serez encouragé par la modification du programme.
Après avoir compris le flux principal du programme et la mise en œuvre du système de base, vous pouvez explorer les autres modules du programme.
Maintenant que vous avez compris le grand projet de code, profitez-en!