コードのナビゲート
VIMよりも優れたエディターを入手してください。
私はKomodo Editを使用しています。
もっともっとメモリにコミットしなければならない気がする
良い。考えるのは良いことです。「学習」が最終的に「記憶」につながることがわかりました。
常に「grep」を実行し、コードを読んでインターフェイスを特定します。
これは典型的なものです。それらを覚えていない場合は、複雑すぎますか？簡素化する時間。
シンプルは作成が難しいです。しかし、思い出すのに苦労するとき、それは悪い設計の徴候です。
grepを使用します。わたしにはできる。私のKomodo Editにはたくさんの素敵な検索機能があります。Notepad ++も同様です
使用しているオブジェクトのインターフェイスを特定する
Doc Stringsとhelp()関数が機能します。私はそれらを使用します。毎日。
リファクタリングの効率化...単体テストの品質に大きく依存します。
それはニュースではありません。静的言語であっても、それは常に真実です。
静的言語では、コンパイルされる限り、実際に動作する可能性が高いと仮定して、しばしば怠け者になります。これは明らかに偽ですが、怠け者になります。
これらの問題には回避策があると確信しています。
これらは「問題」ではなく、「回避策」を必要としません。
動的言語とは、操作するオブジェクトのタイプを正確に知らないことです。パラメーターを受け取ると、「quack（）」および「feathers（）」メソッドが定義されていると想定しますが、ドキュメントの場所はわかりません（実際、複数の実装に複数のdocstringがあります）。
「オブジェクトのタイプを知らない」？本当に。オブジェクトのクライアントを設計するとき、どのタイプを設計したかがわかります。
私は複数のクライアントで使用されるサービスを、定義すると、私は必要なインタフェースを定義したとき、「正確な」タイプは、関係ありませんquack()とfeathers()。
最後に、微妙な問題が発生するまれなケースで「正確な」タイプを判別するためのRead-Execute-Print-Loopなどのツールがあります。それが私が実際に毎日使っていることです。
>>> x = some_mystery_factory( some, args )
>>> type(x)
>>> dir(x)
少なくともPythonでは、オブジェクトの型をほどくのはそれほど難しくないようです。動的言語にはREPLが必要であり、何が起こっているのかを簡単に確認できます。
予想されるパラメーターの順序もわかりません。IDEがそこを支援するのは難しいようです。
それはあまり意味がありません。 help()動作します。
そして、私のIDEはしばしば定義を見つけることができます。常にではありません-一部の複雑な動的構成体は、基本クラスを簡単に隠すことができます。その場合、メソッド定義を見つけるためにオブジェクトのクラスを実際に考えなければなりません。もちろん、私はコードを書いているので、そこにはほとんど（またはまったく）謎はありません。