コンサルタントとして、顧客の要求に応じて X と Y を使用してさまざまな製品や API をいじります。とても楽しいと思いますし、そこから多くのことを学びます。
私の意見では、時間の経過とともに優れた開発者になるのは、新しいことを理解し、学ぼうとする意欲です。したがって、サードパーティ製品を使用しているときに「舞台裏」で何が起こっているのかを常に理解しようとします。
私は自分の時間の約 10 ～ 15% を Reflector で費やして、メソッド X を呼び出すときに実際に何をしているのかを学びます。
平均してどのくらいの時間を費やしますか? これは、ソース コードやドキュメントなどを読む (開く) 場合にも当てはまります。
私にとっては場合によります。新しいテクノロジー スタックまたは API を学習しているときは、通常、Reflector を分解し、その使用量が増えます。
たとえば、最近 Commerce Server 2007 API を使い始めました。プロファイル システムに関するドキュメントの多くが不完全であるか、私の好奇心に十分な詳細が欠けていることがわかりました。そこで、リフレクターを分解し、それを使用してコマース メンバーシップ プロバイダーの実装を調べました (ネイティブの asp.net sql メンバーシップ プロバイダーの実装は言うまでもありません)。
コードを調べることで、メンバーシップ プロバイダーがそのように機能する方法と理由をよりよく理解することができました。
その後、コマース サーバー用のカスタム メンバーシップ プロバイダーを実装することができました。これは、ストック コマース サーバー メンバーシップ プロバイダーの制限の一部を補うものと思われます。私の目標は、私の会社のコマース ユーザー プロファイルの「標準」セットアップと構成を確立することだったので、私の実装は一般的で機能豊富なものには見えませんでした。
そのため、最初にコマース サーバーを使用していたときは、おそらく 20% の時間をリフレクターに費やしていました。理解が深まったので、少なくともコマースサーバーを検査するためにそれを使用することはめったにありません。
次に、私が最初に asp.net ajax と ajax Web コントロール ツールキットを使い始めたときです。ツールキットはオープンソースです。最初はコントロール ツールキットのコードにかなりの時間を費やしました。ドキュメントは問題ありませんでしたが、サンプルは非常に貧弱でした。ソース コードに分割することで、さまざまな Web コントロールを最大限に活用する方法をよりよく理解することができました。また、asp.net ajax JavaScript ライブラリの操作方法をよりよく、より深く学習するのにも役立ちました。最初は、おそらくツールキットのソース コードに約 10% の時間を費やしました。
毎日どのくらいの時間をリフレクターを使用していますか? それほど多くはありませんが、プロジェクトと、関連するテクノロジーが使い慣れているか新しいかによって異なります。
以前は時々使っていましたが、今は有料のソフトウェアになっているので、費やす時間は確実に減ります。
私は.netとコンパクトな.netフレームワークの両方を開発しているので、完全な.netアセンブリを逆コンパイルして、既存の機能をコンパクトなフレームワークに「コピー」することがあります。
それ以外は、ライブラリの逆コンパイルにはそれほど時間をかけません。ほとんどの場合、何かが機能せず、問題が明らかにアセンブリを指している場合にのみ、私は本当に自信を失う前に他の誰かを悩ませたくありません。
あなたが私にそれに数字を付けさせたいのなら、私は私の時間の5％と言うでしょう。
私の時間の1％未満がReflectorに費やされていると思います。なぜそれが良い学習ツールになるのかはわかりますが、期待どおりに機能する限り、何が隠されているのかを知る必要はあまりありません。しかし、それは興味深いアイデアです。
少し楽しみのためにreflektorを使用しましたが、現在はまったく使用していません。
C＃プログラムのすべてのソースを入手したので、何も逆コンパイルする必要はありません。
私はある時点で、自分の時間の 5% から 10% を Reflector に費やしたと思います。最初に .Net を学習したときです。これらの日は、おそらく月に 1/2 時間未満です。しかし、サードパーティのライブラリはあまり使用しません。
ソースコード/ドキュメンテーション、と言うのは難しいです。(ええ、オープン ソース コードの HAS ドキュメントのように....) 私の一般的なブログの読みの一部をそのせいにする必要がありますが、何パーセントかを言うのは非常に困難です。
ライブラリに対して書いている場合、ソースを持っているので、それを使用することはめったにありません。
.Net ライブラリに対して書いている場合、おそらく時間の 5% を費やしますが、それは、慣れていないものを使用していて、Google/MSDN/StackOverflow に失望させられた場合のみです。
サード パーティのライブラリを使用する場合、Reflector を使用する時間の 20% を費やしていると思います。1 つのプロジェクトで、Reflector を使用しておそらく 50% の時間を費やしました。これは、この特定の製品に不適切なドキュメント/フォーラム/知識に、必要なものが欠けていたか、完全に間違っていたためです。
Reflector を使用する必要がないときは幸せだと思います。これは素晴らしいツールですが、通常使用すると、面白くない厄介な問題が発生することになります。
多分2～3%？主にこの DSM プラグインを使用します: http://www.tom-carter.net
WindowsBase.dll で Reflector を使用すると、P/Invoking が非常に簡単になります。COM 相互運用については MS.Internal.Interop 名前空間、Win32 相互運用については MS.Win32.NativeMethods および MS.Win32.UnsafeNativeMethods を確認してください。
私はおそらく自分の時間の約 1% を Reflector に費やしています。これは本当に気の利いたツールですが、社内で非常に多くのコードを書いているため、DLL を逆コンパイルする必要はあまりありませんでした。
いつも使っています。実際のソースを見ることができるのに、なぜ潜在的に欠陥のあるドキュメントを見るのでしょうか?