Naviguer dans le code
Obtenez un meilleur éditeur que VIM.
J'utilise Komodo Edit.
J'ai l'impression de devoir me consacrer beaucoup plus à la mémoire
Bien. Penser, c'est bien. Je trouve que «l'apprentissage» mène finalement à la «mémoire».
"Grep" et lisez constamment le code pour identifier les interfaces.
C'est typique. Si vous ne vous en souvenez pas, alors ils sont trop complexes, n'est-ce pas? Il est temps de simplifier.
La simplicité est difficile à créer. Mais lorsque vous avez du mal à vous souvenir, c'est un symptôme de mauvaise conception.
J'utilise grep. Ça marche pour moi. Mon Komodo Edit a beaucoup de belles recherches. Notepad ++ aussi
Identifier les interfaces des objets que j'utilise
Doc Strings et la help()fonction fonctionnent. Je les utilise. Du quotidien.
Refactoring efficace ... cela dépend énormément de la qualité de mes tests unitaires.
Ce ne sont pas des nouvelles. Cela a toujours été vrai, même dans un langage statique.
Dans un langage statique, nous devenons souvent paresseux, en supposant que - tant qu'il est compilé - il est très probable qu'il fonctionne. C'est manifestement faux, mais nous devenons paresseux.
Je suis sûr qu'il existe des solutions à ces problèmes.
Ce ne sont pas des "problèmes" et ne nécessitent pas de "solutions de contournement".
Un langage dynamique consiste précisément à ne pas connaître le type des objets que vous manipulez. Lorsque vous recevez un paramètre, vous supposez qu'il définit une méthode "quack ()" et "feathers ()", mais vous ne savez pas où se trouve la documentation (en fait, ils auront plusieurs docstrings dans leurs implémentations multiples).
"ne connaissant pas le type des objets"? Vraiment. Quand je conçois le client d'un objet, je sais quel type j'ai conçu.
Lorsque je définis un service, utilisé par plusieurs clients, le type "exact" n'est pas pertinent, lorsque j'ai défini l'interface requise de quack()et feathers().
Enfin, j'ai la lecture-exécution-impression-boucle et d'autres outils pour déterminer le type "exact" dans les rares cas où j'ai un problème subtil. C'est ce que j'utilise tous les jours.
>>> x = some_mystery_factory( some, args )
>>> type(x)
>>> dir(x)
Il ne semble pas trop difficile - du moins en Python - de dérouler le type d'un objet. Les langues dynamiques doivent avoir un REPL, ce qui permet de voir assez facilement ce qui se passe.
Vous ne connaissez pas non plus l'ordre des paramètres attendu. Il semble difficile pour un IDE de vous y aider.
Cela n'a pas beaucoup de sens. help()travaux.
Et mon IDE peut souvent localiser la définition. Pas toujours - certaines constructions dynamiques alambiquées peuvent facilement cacher la classe de base. Dans ce cas, je dois réellement penser à la classe de l'objet pour localiser la définition de la méthode. Bien sûr, j'écris le code, donc il y a peu (ou pas) de mystère.