Travailler sur le code de quelqu'un d'autre [fermé]

J'ai à peine une année d'expérience en codage. Après avoir commencé à travailler, la plupart du temps, je travaillais sur le code de quelqu'un d'autre, en ajoutant de nouvelles fonctionnalités par rapport à celles existantes ou en modifiant les fonctionnalités existantes. Le type qui a écrit le code actuel ne fonctionne plus dans mon entreprise. J'ai du mal à comprendre son code et à accomplir mes tâches. Chaque fois que j'ai essayé de modifier le code, je me suis en quelque sorte mêlé des fonctionnalités. Que dois-je garder à l'esprit lorsque je travaille sur le code de quelqu'un d'autre?

Le code comporte-t-il des tests unitaires? Sinon, je vous suggère fortement de commencer à les ajouter. De cette façon, vous pouvez écrire de nouvelles fonctionnalités / corrections de bugs en tant que tests ayant échoué, puis modifier le code transmis par le test. Plus vous construirez, plus vous aurez l'assurance que votre code ajouté n'a pas cassé autre chose.

Écrire des tests unitaires pour du code que vous ne comprenez pas bien vous aidera à comprendre ledit code. Bien entendu, les tests fonctionnels doivent être ajoutés s'ils n'existent pas déjà. Mon impression était que ceux qui existaient déjà formaient la question OP. Si je me trompe sur ce point, alors ces tests fonctionnels devraient être votre première étape.

Eagle76dk fait un excellent point au sujet de l' obtention de votre gestionnaire à bord pour faire ce travail - plus de détails dans le poste de Eagle76dk.

En outre, au fur et à mesure que vous écrivez ces tests, je vous encourage à essayer de les écrire de manière à vérifier le comportement commercial que la méthode a peut-être tenté d'accomplir, et non le comportement du code. En outre, ne supposez pas du tout que les comportements commerciaux que vous voyez dans le code sont les bons. Si vous avez quelqu'un qui pourrait vous dire ce que l'application devrait faire, il est dans bien des cas plus précieux que ce que le code pourrait vous dire.

En plus d'une autre réponse mentionnant les tests unitaires, je vous suggère de vous assurer que tout est en contrôle de version afin que vous puissiez annuler facilement vos modifications. Et apporter de petites modifications pour rendre le code plus facile à gérer.

À mon avis, le moyen le plus rapide d'apprendre le code de quelqu'un d'autre (en particulier lorsque des modifications entraînent un comportement inattendu, comme vous l'avez décrit) consiste à parcourir le code à l'aide d'un débogueur .

Commencez par parcourir ce qui semble être la boucle principale / les principales méthodes du programme. Utilisez les fonctions pas à pas et pas à pas pour voir ce que font les différentes méthodes. Cela vous apprendra la structure générale du code.

Après cela, divisez pour mieux conquérir en abordant et en apprenant les différentes parties du programme à un niveau plus profond. Dans la plupart des débogueurs, vous pouvez étudier les variables et leurs valeurs actuelles . Étudiez comment ils changent et quand.

Définissez des points d' arrêt sur les méthodes qui déclenchent des comportements qui vous concernent. Par exemple, si vous essayez de modifier un texte dans le programme et que le texte revient toujours à sa valeur d'origine, définissez des points d'arrêt à tous les endroits où le texte est modifié ou essayez de déplacer toutes ces modifications vers une seule méthode. Utilisez la pile d'appels pour voir d'où cette méthode est appelée, etc.

Si la modification d'une ligne de code entraîne des modifications inattendues à d'autres endroits, placez un point d'arrêt sur cette ligne et voyez ce qu'il se passe là-bas, par exemple en vérifiant les valeurs des variables actuelles dans la portée, en utilisant step into ou la pile d'appels pour voir où. l'appel est venu.

En faisant cela beaucoup, vous commencerez à apprendre la structure du code étonnamment vite. J'ai débuté exactement comme vous l'avez fait lors de mes premiers travaux en programmation, avec beaucoup de codes écrits il y a de nombreuses années et modifiés par de nombreuses personnes au cours de nombreuses années. Le code n'était pas le mien seulement, car d'autres personnes y travaillaient en même temps. Je ne pouvais pas tout réécrire à ce stade. L'écriture de tests pour tout ce code m'aurait pris des mois, voire des années. Le débogueur m'a vraiment sauvé, je ne sais pas comment j'aurais appris le code sans cela ...

La première chose à garder à l'esprit est qu'il faut plus de temps pour lire le code que pour l'écrire. Passez du temps à comprendre comment l'autre gars a travaillé - son style et son approche des problèmes.

Essayez d’adopter le plus possible le style existant - sinon le gars qui vous suivra aura deux fois plus à s’ajuster.

Traiter avec le code de quelqu'un d'autre est la norme, pas l'exception, vous devez être capable de comprendre comment l'autre personne aurait résolu un problème ou implémenté une fonctionnalité. Une fois que vous avez fait cela, il vous sera plus facile de gérer son code.

Ne soyez pas trop pressé de supposer que le code de l'autre gars pue.

Mais soyez toujours méfiant.

Mais oui, il faut du temps pour comprendre le code d'un autre développeur. Plus une fonction ou un objet est utilisé par plusieurs parties du système, plus vous devez faire attention. Si vous pouvez résoudre le problème plus près du symptôme, cela peut parfois être utile. Par exemple, normalisez les données entrantes provenant d'un autre objet du côté de la clôture de l'objet à problème après la livraison des données, mais avant tout autre événement.

C'est un mauvais signe que de changer une chose en casse une autre de manière inattendue. Si vous avez d'autres développeurs plus expérimentés sur lesquels vous pouvez compter pour obtenir de l'aide, je leur conseillerais de les examiner pour vous expliquer les problèmes qui vous posent problème. À tout le moins, vous pouvez prendre quelques choses en les regardant déboguer.

Dans un monde idéal, tous les codes écrits par un développeur donné seront bien documentés, structurés et testés de manière compréhensible, avec des outils automatiques tels que des tests unitaires et des scripts de cas d'utilisation exécutés par l'utilisateur pour vérifier que vous obtenez le résultat attendu.

Cependant, la première chose que vous apprendrez, c'est que nous ne vivons pas dans un monde idéal!

Un grand nombre de développeurs ne documentent pas correctement leur code, voire pas du tout, ils associent logique métier et code non lié. Le seul test qu'ils effectuent est une analyse rapide de ce qu'ils s'attendent à être le cas d'utilisation normal.

Lorsque vous travaillez avec un code comme celui-ci, la première chose à faire est d'établir ce qu'il est censé faire. S'il y a des commentaires, ils peuvent vous donner des indices, mais ne comptez pas dessus. D'après mon expérience, de nombreux développeurs ne sont pas doués pour s'expliquer et même s'ils laissent des commentaires, ils pourraient ne pas avoir de sens. Cependant, à moins d'être le seul codeur de la société, quelqu'un doit sûrement avoir au moins une idée de base du code et de ce qu'il est censé faire. Demande autour de toi!

Si vous avez des tests unitaires, ils vous faciliteront grandement la vie. Sinon, l'apprentissage de la base de code peut impliquer l'écriture de tests unitaires pour le code existant. Normalement, cela n’est pas considéré comme une bonne pratique car si vous écrivez des tests unitaires pour s’ajuster au code existant, vous vous retrouverez avec des tests unitaires qui pensent que le code fonctionne tel quel (ils seront écrits pour supposer que le comportement qui est en fait un bogue est correct), mais au moins cela vous donne une base. Si vous découvrez par la suite que certains comportements que vous pensiez corrects sont en fait incorrects, vous pouvez modifier le test unitaire pour rechercher le résultat attendu plutôt que le résultat obtenu à présent par le code. Une fois que vous avez passé un test unitaire, vous pouvez apporter des modifications et évaluer les effets secondaires de vos modifications.

Enfin, la meilleure ressource dont vous disposez pour traiter un élément de code non documenté est de demander aux utilisateurs finaux. Ils peuvent ne rien savoir du code, mais ils savent ce qu'ils veulent que l'application fasse. La collecte des exigences est la première étape de tout projet, et les discussions avec les utilisateurs potentiels du système à développer constituent toujours un élément important. Pensez-y simplement que vous réalisez l’étape de capture des exigences pour un nouveau projet qui vient d’être déjà construit.

N'oubliez pas que même un code bien écrit et bien documenté peut être difficile à comprendre pour un étranger. Le code est essentiellement une expression de la façon dont l'auteur a pensé à l'époque, et chacun a son propre processus de pensée. Vous devrez apprendre à être un peu patient et à être détective. Il est difficile d'entrer dans le processus de réflexion d'une autre personne, mais il s'agit d'une compétence essentielle pour un programmeur qui effectue la maintenance du code existant. Comme la plupart des opérations de codage (environ 70%) sont liées au maintien du code existant, il s'agit d'une compétence importante à apprendre.

Oh, et maintenant que vous avez vu la douleur que peut causer un code mal documenté, non testé et brouillé, vous ne le ferez pas au prochain pauvre développeur, non? :) Tirez les leçons des erreurs de votre prédécesseur, commentez bien votre code, assurez-vous que chaque module a une responsabilité clairement définie, et assurez-vous de disposer d'un ensemble complet de tests unitaires que vous écrivez en premier (pour les méthodologies TDD) ou au moins à côté du code en cours de développement.

Gardez à l'esprit que la capacité de lire du code que vous n'avez pas écrit est une compétence très précieuse, probablement plus précieuse que la rédaction de code. Malheureusement, cela est largement minimisé et sous-enseigné dans les écoles.

Ce que j'essaie de dire, c'est qu'il est normal de ne pas toujours comprendre le code dès sa première lecture (tout comme il est normal de ne pas écrire du code parfait la première fois). Si vous acceptez le fait qu'il faut du temps pour obtenir un code étranger, cela ne vous gênera pas de déployer des efforts supplémentaires. Un petit résumé:

• Les tests unitaires seraient idéaux, mais pas toujours réalistes; surtout si vous travaillez dans une grande organisation avec une lourde bureaucratie.

• Apprenez à utiliser votre système de contrôle de version correctement; vous ne casserez jamais l'existant (pas vraiment jamais , mais c'est un bon filet de sécurité).

• Ne présumez pas que c'est mauvais simplement parce que vous ne le comprenez pas instantanément. Ne présumez pas que c'est bon simplement parce que cela fonctionne. L'important est de comprendre le style de code du responsable précédent et d'adapter les lignes ajoutées à son style. Le mainteneur venant après vous vous en remerciera.

• Malheureusement, dans certaines entreprises, la difficulté de lire du code peut être sous-estimée. Ceci est courant dans les grandes entreprises avec des processus rigides. Ils préfèrent souvent (implicitement) que vous poussiez un code qui fonctionne rapidement plutôt que de prendre votre temps pour écrire quelque chose de propre. Je vous laisse le soin de décider de la position de votre équipe sur ce point.

• Enfin, n'oubliez jamais que lire du code est une compétence . Plus vous le faites, mieux vous vous en tirerez. Une autre façon de le dire est que le seul moyen de devenir bon est de le pratiquer plusieurs fois. Comme mentionné ci-dessus, la lecture de code est et sera une partie beaucoup plus importante de votre travail que l'écriture.

À en juger par vos problèmes de casse par inadvertance, je vais supposer que le code n'est pas couvert par des tests automatisés. L'étape 0 consiste à commander immédiatement et à lire Travailler efficacement avec le code hérité de Michael Feathers. C'est simplement inestimable.

Les étapes de base, je suggère:

• Couvrez le code avec des tests couvrant les fonctionnalités actuelles.
• Refactor jusqu'à compréhensible.
• Ecrivez un test pour la fonctionnalité nouvelle ou modifiée.
• Implémentez la nouvelle fonctionnalité.
• Refactor jusqu'à satisfaction.

Je laisse délibérément de côté la spécification de la saveur des tests (unité, intégration, ...) - il suffit d'obtenir une sorte de couverture de test automatisée.

(et, oui, suivez le style de codage en termes de mise en page et de nommage)

Comme mentionné précédemment: bienvenue dans le monde réel. Je ne peux qu'être d'accord avec les réponses précédentes. Je souhaiterai seulement étendre la réponse avec mon expérience de travail sur les estimations de temps.

Une bonne suggestion pour que votre patron soit clair, il faudra du temps pour apprendre comment les autres développeurs pensent. Vous constaterez généralement que la solution actuelle dépend souvent de l'âge et de l'expérience du développeur.

Si vous avez de la chance, la tâche à accomplir doit être analysée et la compréhension de la documentation vous aidera beaucoup (mais ce n'est souvent pas le cas).

Mon expérience est que lorsque vous modifiez le code d'un autre, essayez de ne pas changer de code qui n'implique pas votre tâche actuelle. Vous connaissez peut-être une meilleure solution ou elle pourrait être écrite de manière plus intuitive, mais sa modification entraîne souvent des problèmes tels que:

• La tâche prendra plus de temps et votre patron ne la comprendra pas.
• Le code que vous modifiez doit être testé et cela coûte cher. La solution actuelle a été testée et approuvée.
• Il sera difficile de voir quels changements résoudront la tâche actuelle et lesquels ne sont que des corrections.

Mais n'hésitez pas à le dire à votre patron si vous voyez quelque chose qui, à votre avis, devrait être différent (cela montre que vous pouvez penser).

Enfin, assurez-vous de disposer de suffisamment de temps pour élaborer la solution. Une solution plus rapide vient avec l'expérience. Mais il existe rarement une solution rapide, car c’est la première / principale raison des erreurs et du code non maintenable.

Pensez-y comme d'effectuer une opération sur une personne.

Vous recherchez le problème à résoudre et remarquez que la plupart des artères, etc., ne sont pas configurées comme vous le feriez. Vous devez donc les couper et les découper jusqu'à ce que le problème vous convient, puis résoudre le problème.

Étonnamment, votre patient décède presque immédiatement.

Les applications héritées sont les mêmes. Ils ont déjà une méthode de travail: vous devez comprendre les différents composants du logiciel et leur relation les uns aux autres, puis effectuer vos modifications pour que cela fonctionne de la même manière. Ce n’est pas excitant de laisser aller votre créativité, mais vous pouvez le faire sur des projets personnels.

Je demanderais à un ingénieur en chef de vous asseoir pendant une heure environ tous les lundis pour vous expliquer un aspect différent du système. Prenez des notes de ce qu'il a dit et envoyez-les par courrier électronique à lui et à votre responsable pour voir si celui-ci a quelque chose à ajouter. Vous devriez vous mettre au courant assez rapidement de cette façon.

Pour ce qui est de ne pas casser des choses, assurez-vous d’abord de bien comprendre ce que fait le système. Testez avant - faites votre changement - testez après. Il n'y a pas de formules magiques; En acquérant de l'expérience, vous vous améliorerez ou vous ferez virer, je suppose!

Une chose que je n'ai pas vraiment vue évoquée ici - ne fonctionne pas sur une île.

À moins que vous ne soyez le seul programmeur de votre entreprise, il y a forcément quelqu'un qui a plus d'expérience que vous et très probablement beaucoup de personnes sur lesquelles vous pouvez compter.

Poser des questions. Beaucoup d'entre eux.

Ne vous inquiétez pas de "gêner" quelqu'un d'autre (dans des limites raisonnables) - Je préférerais que quelqu'un m'interrompe pour une question ou deux au cours d'un cycle de développement normal, plutôt que de devoir éteindre un feu dans un environnement de production plus tard.

Lorsque vous êtes prêt à enregistrer quelque chose, examinez-le avec votre (vos) mentor (s). Ils devraient pouvoir vous dire non seulement si quelque chose va casser quelque chose d'autre, mais plus important encore, pourquoi. Réviser le code fera également du mentor un meilleur programmeur, lui donnant ainsi une vue du système qu’il ne verrait peut-être pas aussi souvent.

N'oubliez pas que vous apprenez non seulement le système comme tout nouvel employé devrait le faire, mais vous apprenez également comment devenir programmeur.

Et cinq ans plus tard, encouragez le prochain New Guy à vous utiliser comme mentor.

Rappelez-vous qu’il ya toujours une raison en ce qui concerne le débogage du code . Lorsque vous essayez de trouver et de corriger le même bogue stupide depuis quelques jours et que vous ne faites aucun progrès, il est tentant de commencer à penser à un ou plusieurs des problèmes suivants:

• Je ne suis pas assez intelligent pour comprendre comment fonctionne ce code

• Le gars qui a écrit ce code n'avait aucune idée de ce qu'il faisait

• La magie est impliquée: magie très noire

Ce sont toutes des formes d'abandon. L'antidote est de toujours se rappeler que les ordinateurs sont déterministes: il y a toujours une raison à ce qu'ils font. Le code peut sentir comme une marée basse dans une conserverie de poisson et ressembler à un bol de linguines géant, mais en étant rationnellement implacable et en gardant l'esprit ouvert, vous comprendrez .

Que vous écriviez des tests unitaires dans la mesure du possible ou écrivez de petites applications impliquant le code que vous modifiez, vous devrez examiner, comprendre puis documenter la logique.

Si le code fonctionne généralement - cela sonne comme ça -, je conserverais le style de formatage du code pour ce module, que ce soit votre style ou non. Cela maintient les choses uniformes. Cependant, les bons commentaires ne sont jamais démodés.

Je conseille un système de test et une plateforme de test sur lesquels vous pouvez modifier et tester ce code sans interrompre la production.

Si vous pouvez supprimer des éléments du code dans une bibliothèque, je le ferais, sauf si vous travaillez sur une bibliothèque.

Au fil du temps, une fois que vous avez compris la logique, vous pouvez réécrire et tester.

Ce conseil dépend du langage que vous utilisez, de la possibilité d’obtenir un lit d’essai et d’autres contraintes.

Essayez d’utiliser certains outils d’analyseur de code pour trouver le code inutilisé qui peut être supprimé - de cette manière, vous n’aurez pas à vous soucier de ce code.

Nous avons remarqué ci-dessus que vous devez comprendre le but du système, pas seulement les détails du code. Un programmeur possédant suffisamment d'expérience pour écrire un système de saisie de commande est généralement à l'aise avec la partie "avancer" qui consiste à sélectionner des produits, à formater une facture et à traiter le paiement. Ils se retrouvent coincés lorsque l'utilisateur décide de ne pas laisser tomber et commence à annuler des transactions ou lorsqu'il commet une erreur dans le traitement du paiement et clique sur le bouton «Précédent». À ce stade, beaucoup de programmeurs sont déconcertés, car ils voient le code "venir de nulle part" et ne peuvent pas comprendre pourquoi il est là.

En bref, vous devez comprendre non seulement le «flux normal», mais tous les retours en arrière nécessaires si une personne commet une erreur ou change d’avis. Cela devient encore pire avec les remplacements de superviseur, où certains codes ne peuvent être exécutés qu'avec certains privilèges de compte.

Si une personne écrit 10 000 lignes de code par an et qu'une application a une durée de vie de dix ans, un programmeur chargé de récupérer le travail de quelqu'un d'autre devra peut-être comprendre 100 000 lignes de code. Diviser cela par 50 lignes par page est de 2000 pages. Si le programme est écrit selon un modèle de conception, le programmeur s'aperçoit que la compréhension d'un «bloc» conduit au moins à une compréhension générale de la plupart des autres. Si ce n'est pas le cas, il est nécessaire de lire la dernière ligne.

Certains programmeurs «font juste ce qu'on leur dit» et écrivent des spaghettis. Ils ne comprennent jamais la "grande image" - ils apportent simplement des corrections lorsque les utilisateurs se plaignent. Dans de telles circonstances, il est judicieux de commencer à migrer dans la mesure du possible vers un modèle approprié. Finalement, cela peut signifier de recoder des éléments qui ne sont pas «cassés». Ne vous inquiétez pas, assurez-vous que, tant que votre projet est en place, il est de plus en plus facile à gérer.

Il y a de très bonnes réponses ici. Mais je pense qu'il convient également de mentionner combien la familiarité avec de bons modèles de conception peut aider, lire le code existant (bien écrit) et écrire du code lisible.

Bien sûr, cela peut être très déroutant lorsque vous rencontrez un SomethingFactorycode existant qui ne suit pas réellement le modèle d'usine . Mais dans la mesure où votre équipe et votre cadre le permettent, il peut être avantageux de limiter au minimum ces cas.

Le fait de suivre des modèles de conception (là où les besoins de l’entreprise le permettent) peut également réduire considérablement la duplication de code, ce qui réduit à son tour les erreurs sur les modifications futures.

Quelques bonnes sources sur les modèles de conception sont

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

et bien sur le livre

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Suivre le flux de contrôle entre les méthodes est très important pour développer une carte mentale de la logique métier.

Notre solution repose sur la reconnaissance du fait que le système en cours d'exécution est l'une des rares informations fiables qui soit disponible à l'approche d'un système hérité. Notre approche réifie les traces d'exécution et utilise la programmation logique pour exprimer des tests sur celles-ci.

La génération d'un modèle de données de flux de travail est le meilleur moyen d'analyser tous les chemins de code:

En pratique, la révision de code devient lourde dans les flux de travail scientifiques hérités. L'origine de tels flux de travail signifie que les pratiques de génie logiciel n'ont peut-être pas été appliquées au cours du développement, ce qui a engendré une base de code qui est efficacement masquée. Bien que l'analyse statique dispose de techniques bien développées pour l'analyse de flux de données, elles ne prennent pas en charge le comportement dans les flux de travail du monde réel. Par exemple, quand un fichier de configuration doit être chargé pour déterminer comment les données doivent être traitées, ou quand l'évaluation de code dynamique est utilisée.

Et visualiser le flux de travail est idéal:

Un motif commun, se prêtant au développement visuel, est la présentation d'un flux de travail sous forme de graphique. Cela protège l'utilisateur de la complexité sous-jacente des ressources et de l'exécution

Références

• Comprendre les workflows hérités via l'analyse d'exécution (pdf)
• Test de logique basé sur trace de l'ancien système orienté objet (pdf)
• console.trace () - API Web | MDN
• Traçage des appels de méthodes via les mandataires
• Comment espionner vos méthodes Ruby
• Traçage facile des appels de fonctions imbriquées en Python - Site Web d'Eli Bendersky
• Enregistrement de la méthode d'entrée / sortie - Mebyon Kernow
• Trace: Instrumentation pour afficher les appels de fonction
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: invocations de méthode Trace Swift et Objective-C
• Debug :: Trace - L'extension Perl pour tracer les appels de sous-programmes - metacpan.org

Assurez-vous que vous utilisez un programme qui vous aide à rechercher des éléments dans le fichier actuel. Rien n’est pire que de savoir que la chose que vous recherchez se trouve dans le fichier actuel, mais vous faites défiler et faites défiler et vous ne pouvez pas le trouver. Une vue d'ensemble de l'outil que vous utilisez pour modifier le code aide vraiment à résoudre ce problème.