自動リファクタリングツールの使用を開発者に妨げているものは何ですか？
IDE（Eclipse、NetBeans、IntelliJ、Xcode、Visual Studioなど）で自動リファクタリングツールを使用することについて同僚と話し合っており、その多くが驚いたでした。そのようなツールを使用して不快です。それらの1つは、20年間熟練した開発者（Smalltalk、C/C++、Java、Javascript）であり、彼はめったにIDE andevenを使用しません）彼は自動リファクタリングツールを使用せず、多くのリファクタリングを行っていますが、手動でallしています。
個人的には、リファクタリングツールに大きく依存しています。プロジェクトで作業するときはいつでも、自動リファクタリングをサポートするIDEを選び、可能な限りそれらのリファクタリングを使用するようにしています。
Stack Exchangeのプロの開発者が自動リファクタリングツールを使用しているかどうかを知りたいです。そして、もしそうでなければ、なぜでしょうか？
作業を開始するために、同僚が自動リファクタリングツールを使用しない理由をいくつか次に示します。
Trust-複数のファイルに影響を与える可能性があるプルアップのような複雑なリファクタリングである場合は特に、ツールの動作を信頼しないことがあります。彼らはツールが微妙なバグをもたらすかもしれないことを心配しています。
発見可能性-IDEですぐに明白ではないため、そのようなリファクタリングが利用可能であることを彼らは気付かないことさえある
柔軟性-時々、ツールは剛性が高すぎて、希望どおりに動作させるにはあまりにも多くの設定が必要であるように感じることがあります。
更新-要約
これまでの回答に基づいて、3つのことを要約できると思います。
開発者には、利用可能なさまざまなリファクタリングをすべて試す時間はありません。そして、彼らはそれらを試すことができないので、彼らはコードに何をするか（すべての隅のケース）に疑いを持っています。この疑いは、（チェックするテストがある場合でも）時間的なプレッシャーのもとでの製品コードに対して保証されます。おそらくより良いUIツールはこれを軽減することができます。
開発者は、特にメタプログラミング/リフレクションを使用する場合や外部ファイル（xml、構成、プロパティ）を使用する場合に、リファクタリングツールの制限にも不満を感じています。自動リファクタリングツールは改善を続けていますが、常に制限があります。制限が受け入れられる場合と受け入れられない場合があります。私は他の何人かの同僚と話をしました、そしてそれらの何人かは限界にもっと寛容です。たとえば、名前変更リファクタリングですべてのファイルの名前が変更されず、90％の名前が変更された場合、ツールを使用して残りの10％を手動で修正できます時間と労力を節約します。
[私が収集したものから私の意見では]、開発者はリファクタリングツールがNice-to-have機能であるため、初めて機能しない場合（または許容できない何かを行う場合） ）、彼らはそれらを放棄し、手動で変更を加える傾向があります。これを、コンパイラーやデバッガーなど、制限と bugs がある他のツールと比較してください。開発者は、重要な機能であり、ワークフローで放棄することができないため、制限にもかかわらず、それらに固執する可能性があります。
すべての応答をありがとう。このトピックがより多くの人に関心がある場合は、コミュニティWikiに変えることをお勧めします。
プロジェクトのサイズ、テストの可用性、IDEの成熟度が、自動リファクタリングツールを使用するという人々の決定に影響を与えるかどうかを調べることは興味深いでしょう。
彼らはできることには限界があり、多くの場合、結果は満足のいくものではありません。また、大部分のユーザーにとってあまり役に立たないようなあいまいなコーナーケースもカバーしています。
IntelliJでは、リファクタリングツールの一部を定期的に使用しています（名前の変更、パラメーターリストの変更、メソッドの抽出など）。静的にする???ペストのような静電気を避けようとします。コンストラクタをファクトリに変更しますか？必要なかった。
Eclipseでは、IMOが不格好であるため、それらを使用することはめったにありません（ただし、IntelliJを使用すればするほど、全体としてEclipseを嫌うので、それほど驚くことではありません）。
あなたのポイントに直接対処するには：1）信頼。確かにそれは問題になる可能性があります。私は、コードベースでこれらのツールを使用することを知らないため、コードベースで使用しないので、結果をある程度事前に予測できます。コードベースが大きくなると、それが難しくなります（そして、作業中にツールがバグを導入する可能性が高まると、私はそれを経験しました）。 2）発見可能性。まさにその通り。多くの場合、それらはコンテキストメニューの複数のレイヤーに隠されているか、非常にあいまいな名前を持っています。 3）柔軟性。柔軟性が高すぎるよりも、柔軟性が高すぎて使いにくい場合があります。時間のプレッシャーの下で作業しているときは（そして時間のプレッシャーの下で常に作業しているのではないのですか？）、何をしているのか推測しやすくなる頻繁に不十分なドキュメントと組み合わせます。
したがって、本番環境のコードでツールを使用する前に、時間をかけてツールを試してみる必要がありますが、ほとんどの人（確かに会社の上級者）は、すでに十分に機能しているため、そのような実験を行う時間はほとんどありません。生産コードの時間。
他のツールと同様に、リファクタリングツールにも制限があります。
それらが実行する環境の制限。
- コマンドラインリファクタリングツールについて教えてください。
リファクタリングできるコードの種類の制限。
- 多くの場合、メタプログラミングコードはリファクタリングツールで実行できません。
さまざまな言語のサポート量の制限
- PerlとPython=数年前のリファクタリングの品質は良くありませんでした。今のところはわかりません。
また、自動リファクタリングツールで実行できるいくつかのことがわかりました。インラインemacsマクロを使用すると、より上手に実行できます。それは私の経験です。
私はあなたが話している男なので、私はこれに答えることができます。つまりね。より高品質のコードを生成するためにリファクタリングが行われます。それを正しく行うには、かなりの思考が必要です。しかし、リファクタリングツールを使用すると、非常に簡単に何かを行うことができます。それで何が起こりますか？人々は、コードを残すことを考えずにリファクタリングしますが、それはもともとあったコードよりも悪いものです。しかし、リファクタリングツールの知識を決して納得させることはできません。誰もが知っているリファクタリングが優れているため、IDEウィザードは実際にリファクタリングを行いました（Eclipseはそう言っています）。これは、リファクタリングツール自体が悪いと言っているわけではありませんが、それらを好む傾向があるプログラマーのタイプのために悪い名前。
MS VisualStudioの潜在的なリファクタリングの問題（2005、2008、2010）
注：より建設的になるために、私はあなたの質問を「Refractoringtoolsを使用するときに潜在的な問題に注意する必要がある場所」と再解釈します
ある種のリフレクションを使用している場合、名前の変更がconfiguration/xml/gui-Filesに反映されない可能性があるため、プロパティ/メソッドの名前の変更は悪夢になる可能性があります。
残念ながら、これらのIssuseは実行時にのみ発生し、コンパイル時には発生しません。
この問題は
- xml/xaml/guiファイルにプロパティ名への参照があるwpf/mvvm
- xml/xamlファイルにワークフローを制御するプロパティ名への参照があるワークフロー。
リフレクションベースのプログラミング（つまり、Winforms）がない限り、VS（またはVsExpress）での名前の変更は魅力的なように機能します。これは、単純な検索と置換の場合とは異なり、複数のサブプロジェクトで識別子スコープに従うためです。
IDEはユーザーから十分なフィードバックを得ることなく新機能を追加し続けるため、これは興味深い質問だと思います。このような質問は、プログラマーからのフィードバックを提供する良い方法です。以下は、リファクタリングツールに関する私の個人的な経験です。
私はEclipseのほとんどのリファクタリングツールを使用していますが、それらがすべて機能しているわけではありません。それらがどのように機能するか、そしてリファクタリングするコードに対する要件は何なのかわかりません。