Comment quelqu'un habitué à la pensée de PF doit-il lire le code impératif?

J'ai obtenu mon diplôme universitaire il y a environ cinq mois et je travaille dans une startup locale depuis quatre mois. Pendant mes études à l'université, j'ai étudié Haskell, F # etc par moi-même. On nous a enseigné Java à l'université, mais j'ai été très vite exposé à la programmation fonctionnelle, et j'ai passé beaucoup plus de temps avec lui qu'avec la programmation impérative. En conséquence, mon cerveau est câblé pour une pensée fonctionnelle. La société que j'ai rejointe utilise Python et le code est très impératif. J'ai du mal à lire le code impératif. Je ne peux pas garder une trace des mutations. Quand une imbrication for-if-else-for -... va plus de quatre niveaux, je perds complètement la trace de ce qui se passe dans le code. Pour ajouter à cela, Python est un langage dynamique, il n'y a donc pas de types dans le code. Il' Cela fait des semaines que je n'ai pas essayé de comprendre une partie de notre base de code (qui est soi-disant «modérément complexe»), mais je n'ai pas fait de progrès appréciables jusqu'à présent pour le comprendre. Veuillez m'offrir quelques techniques pratiques sur la façon dont je devrais procéder pour comprendre ce code. Merci d'avance!

Edit:
Je devrais peut - être aussi mentionner qu'il n'y a pas vraiment beaucoup de commentaires dans le code, et les noms ne sont pas non plus très intuitifs.

Comprendre le code hérité est difficile. Cela n'a presque rien à voir avec les fonctionnalités par rapport aux procédures.

1. Créez une carte quelconque. Un diagramme de composants des packages et modules Python. Pour chaque module, vous devrez créer des diagrammes de classes.

2. Utilisez l'interpréteur Python. Vous devriez pouvoir importer des modules, créer des objets et les exercer de manière interactive. C'est pourquoi Python est populaire. Vous pouvez imprimer type(x)pour voir de quel type est réellement une variable ( x ).

3. En cas de doute, assurez-vous de lire le code de test unitaire. S'il n'y a pas de code de test unitaire, vous avez de gros problèmes imminents en plus d'apprendre une nouvelle base de code.

4. Écrivez des trucs. Commencez avec les documents annexes. Ensuite, lorsque vous pensez savoir ce qui se passe, ajoutez des commentaires docstring aux fonctions, méthodes et classes. Ajoutez-les tôt et souvent.

5. Utilisez Sphinx avec 'autodoc' pour collecter ce que vous apprenez.

La partie la plus importante est la suivante. Il est difficile de garder les choses en tête. Il est plus facile de garder les choses dans les fichiers de documentation.

J'ai du mal à lire le code impératif. Quand une imbrication for-if-else-for -... va plus de quatre niveaux, je perds complètement la trace de ce qui se passe dans le code.

Attendez ... n'importe qui perd complètement la trace du code avec des niveaux d'imbrication aussi profonds. Ou, comme l'a dit Linus Torvalds:

Si vous avez besoin de plus de 3 niveaux d'indentation, vous êtes quand même foutu et devez corriger votre programme.

Je devrais peut-être aussi mentionner qu'il n'y a pas vraiment beaucoup de commentaires dans le code, et les noms ne sont pas non plus très intuitifs.

Cela ne semble pas comme si votre entreprise adhérait aux meilleures pratiques courantes.

Si j'étais vous, j'essaierais simplement de comprendre la base du code par discipline et force. Il suffit de creuser dedans, encore et encore et encore. C'est probablement comme n'importe quoi. En ce moment, vous avez l'impression d'être sous l'eau et vous ne pouvez pas respirer, mais continuez à examiner la base de code et bientôt vous nagerez à la surface.

Je crains que votre question manque de détails techniques pour vous offrir de bons conseils sur la façon de comprendre la base de code, mais il n'est jamais faux de la parcourir avec des collègues expérimentés en quelques séances. Laissez-les vous expliquer l'architecture globale et la façon dont les différents composants interagissent entre eux, ainsi que les décisions d'implémentation qu'ils ont prises.

Il est difficile de donner des conseils généraux pour la transition des langages fonctionnels vers les langages impératifs / OO. Bien sûr, je pourrais mentionner quelques phrases fleuries comme "Vous devez penser aux états et aux comportements des objets", mais cela ne vous aidera pas beaucoup, je pense que c'est quelque chose que vous devez expérimenter.

Si (gros si des mauvaises pratiques que vous décrivez) il y a des tests unitaires, alors vous pouvez les regarder pour voir comment le code est testé. Cela peut offrir un bon aperçu de ce que fait le code.

Sinon, je suggérerais de lire du code python plus générique pour s'habituer à la façon dont il est écrit.

Vous pouvez essayer de traduire certains fragments de Python en pseudo-Haskell ou tout ce que vous voulez. Cela peut vous donner une idée de quelles constructions impératives correspondent vaguement à quelles constructions fonctionnelles. À mesure que vous obtenez plus d'expérience, les constructions impératives commenceront à se sentir plus natives.

Je suis passé de la programmation OCaml et Haskell à la programmation Java et Python, et mon expérience est que la programmation impérative n'est pas un grand pas en avant comme la frappe dynamique, qui à ce jour semble étrangère.

Je vous suggère de mettre des points d'arrêt et de commencer à utiliser la commande Next (comme si vous déboguez), cela vous aidera à comprendre le flux (probablement sur les branches, il y a des chemins qui sont plus susceptibles d'être empruntés, sur ceux que vous devriez vous concentrer pour obtenir l'idée générale du code).

(J'ai eu de bons résultats avec Eclipse avec PyDev comme plugin Eclipse)