IDEを使用する必要があるのはなぜですか？[閉まっている]

別の質問では、マークはIDEを高く評価し、「なぜ「なぜ」使用する必要があるのか​​をまだ知らない人もいます...」と述べています。プログラミングにvimを使用し、ほとんど/すべての同僚がすべての作業にvimまたはemacsを使用する環境で働いている人として、IDEの利点は何ですか？なぜ使用する必要があるのですか？

これは一部の人にとっては問題となる問題であり、炎上戦争の開始には興味がないので、IDEベースのアプローチの方が優れていると思う理由でのみ返信してください。IDEを使用してはいけない理由については知りたくありません。もう使っていません。いわば「フェンスの向こう側」から聞いてみたいです。

IDEが特定の種類の作業には適しているが、他の種類の作業には適していないと思われる場合は、その理由も聞きたいと思います。

それは本当にあなたが使用している言語に依存しますが、C＃とJavaではIDEが有益であると私は思います：

• 名前空間やプロジェクトなどを気にすることなく、すばやくタイプに移動する
• ハイパーリンクとして扱うことによるメンバーへのナビゲート
• すべてのメンバーの名前を暗記できない場合のオートコンプリート
• 自動コード生成
• リファクタリング（大規模なもの）
• インポートを整理する（C＃のディレクティブを使用して、Javaに適切なインポートを自動的に追加する）
• 入力時の警告（つまり、一部のエラーはコンパイルサイクルを必要としません）
• ドキュメントにカーソルを合わせるとドキュメントが表示されます
• ファイル、エラー/警告/コンソール/単体テストなどのソースビューとソースコードをすべて便利な方法で同時に画面に表示する
• 同じウィンドウからユニットテストを簡単に実行
• 統合デバッグ
• 統合されたソース管理
• エラーの詳細から直接、コンパイル時エラーまたは実行時例外が発生した場所に移動します。
• 等！

これらのすべてが時間を節約します。それらは私が手動でできることですが、もっと苦労して：私はむしろコーディングしたいと思います。

コード補完。コードの探索に役立ちます。

IDEを使用する理由についての短い答えは、怠惰です。

私は怠惰な魂で、代わりに簡単な方法があるのに難しいことをしたくないのです。IDEは生活を楽にし、怠惰な人々にアピールします。

コードを入力すると、IDEがコードの有効性を自動的にチェックし、メソッドを強調表示してF1キーを押してヘルプを表示し、右クリックして[定義に移動]を選択して、定義されている場所に直接ジャンプします。ボタンを1つ押すと、デバッガーが自動的に接続されたアプリケーションが起動します。そして、リストは続きます。開発者が日常的に行うことはすべて1つの屋根の下に集められます。

IDEを使用する必要はありません。それはしないほうがはるかに難しい仕事です。

「テキストエディター」が本当にemacsであるときに、クラシックな「テキストエディターとコンソールウィンドウvs IDE」を実行するのは公平ではないと思います。IDEに典型的なほとんどの機能はemacsにもあります。あるいは、おそらくそこから生まれたものであり、最新のIDE：は主にインターフェースの改善/簡素化です。

つまり、元の質問の答えはそれほど明確ではありません。問題のサイトのユーザーがemacs をどのように使用するか、主にテキストエディターとして使用するか、またはすべてのユーザーがカスタムスクリプトを使用するか、関連するモードのコマンドを学ぶ、コードのタグ付けなどを知るかによって異なります。

私はこの質問に反対の方向から来ます。私は、Makefile + Emacsでのピットストップがほとんどないプログラミングで育ちました。DOS上の最も初期のコンパイラであるMicrosoft Quick Cから、自動化するIDEがありました。私は長年Visual C ++ 6.0で働いており、Enterprise Javaを卒業しているときにBorland JBuilderと一緒に働いた後、Eclipseに落ち着きました。

私の最初の自己教育、大学、そして現在の専門職のキャリアを通じて、IDE内でのみ行われる主要なソフトウェア開発はいずれも逆効果になることを学びました。ほとんどのIDEはあなたに働くことを望んでいるので、私はこれを言います彼らで独特のI-control-how-the-world-worksスタイル。あなたは彼らの線に沿ってあなたのプロジェクトをスライスしてさいの目に切る必要があります。奇妙なダイアログボックスを使用してプロジェクトビルドを管理します。ほとんどのIDEは、プロジェクト間の複雑なビルドの依存関係を適切に管理しておらず、依存関係を100％機能させるのが難しい場合があります。Clean / Rebuild Allを実行しない限り、IDEが私のコードの動作するビルドを生成しない状況にありました。最後に、開発からソフトウェアを移動して、IDEからQAやプロダクションなどの他の環境に移動するクリーンな方法はめったにありません。通常、すべてのデプロイメントユニットを構築するのは面倒ですが、IDEベンダーからバンドルするための厄介なツールがあります。しかし、再び、

チームで大規模な開発を行う場合、IDEを使用してコードを開発し、手動で作成したコマンドラインスクリプトを使用してすべてのビルドを行うと、最も生産性が高くなることを学びました。（Java開発用のApache Antが気に入っています。）IDEからスクリプトを実行することは、クリックフェストまたは複雑なビルドの自動化の悪夢であり、Alt + Tabキーを押して、シェルでスクリプトを実行します。

手動ビルドでは、バックグラウンドコンパイルなどの最新のIDEのいくつかの機能を逃す必要がありますが、得られるものははるかに重要です。つまり、複数の環境で使用できるクリーンで簡単なビルドです。これらのアジャイルな連中が語る「ワンクリックビルド」？私たちはそれを持っている。ビルドスクリプトは、継続的インテグレーションシステムから直接呼び出すこともできます。継続的な統合によってビルドを管理することで、コードデプロイメントをより正式にステージングしてさまざまな環境に移行することができ、誰かがビルドまたはユニットテストに違反する不良コードをチェックインすると、ほぼ即座にそれを知ることができます。

実際、私がIDEからビルドの役割を引き受けても、それほど害はありません。Eclipseのインテリセンスとリファクタリングツールはまだ完全に有用であり、有効です-バックグラウンドコンパイルは単にこれらのツールをサポートするために役立ちます。そして、Eclipseの独特なプロジェクトのスライスは、誰でも理解できる方法で問題セットを精神的に分解するための非常に良い方法として役立っています（ただし、私の好みについては少し冗長ですが）。Eclipseで最も重要なことの1つは、優れたSCM統合であり、それがチーム開発をとても楽しいものにしていると思います。私たちはSubversion + Eclipseを使用しています。これは非常に生産的で、専門家になるための人材育成が非常に簡単です。

あなたの質問であなたが強調する応答の作者であり、確かにこれに少し遅れて来ているので、私はリストされている多くの理由の中で、プロの開発者の生産性が最も高いものの1つであると言わざるを得ません高い評価を得ているスキル。

生産性とは、可能な限り最高の結果を出して効率的に仕事を行う能力を意味します。IDEはこれを多くのレベルで有効にします。私はEmacsの専門家ではありませんが、主要なIDEの機能が不足しているとは思いません。

設計、文書化、追跡、開発、構築、分析、展開、およびメンテナンス、エンタープライズアプリケーションの主要なステップストーンはすべてIDE内で実行できます。

選択肢があれば、なぜそれほど強力なものを使用しないのですか？

実験として、たとえば30日間IDEを使用することを約束し、自分の気持ちを確認してください。その経験についてのあなたの考えを読んでみたいです。

IDEには次の利点があります。

• コンパイルは通常「オンザフライ」です。つまり、コンパイルするためにコマンドラインに切り替える必要はありません。
• デバッグが統合されており、それをIDEで使用することは、ステップデバッガーが実際にインプレースエディターを使用して、実行されるコードを視覚的に示すことを意味します
• IDEは通常、作業している言語に関するより意味論的な知識を持っているため、入力中に起こりうる問題を示すことができます。リファクタリングは「検索置換」よりもはるかに強力です。

まだまだあります。試してみてください。

IDEは基本的に：

• コード補完、リファクタリング、文書化機能を備えたエディター
• デバッガ
• ファイルシステムエクスプローラー
• SCMSクライアント
• ビルドツール

すべて1つのパッケージに含まれています。

個別のツールを使用するか、Emacsなどの優れたプログラム可能なエディターと追加のツール（Vimだけでなく、少しIDE性が低いIMO）を使用して、これらすべて（およびいくつか）を使用できます。

環境に統合される可能性のあるユーティリティと次のユーティリティを頻繁に切り替える場合、またはここに記載されている機能の一部（さらに詳しくは他の投稿に記載）がない場合は、IDEに移行するときです（またはマクロなどを追加して、環境のIDE機能を向上させます。複数のプログラムを使用して（上記の意味で）自分で「IDE」を構築した場合、実際のIDEに移行する必要はありません。

日食：

コードのハイライト表示、バックグラウンドでのコンパイル、進行中のエラーの指摘。

javadocとの統合。ctrl-Spaceを使用して変数名を提案します。

コンパイルすると、エラーが発生します。エラーをダブルクリックすると、適切な行が表示されます。

JUnitと本当にうまく統合されたctrl-F11はテストを実行し、テストが失敗したことを通知します。出力ウィンドウに例外がある場合、行をダブルクリックすると、失敗した行に移動します。それだけでなく、ctrl-F11は、テストを実行する前にすべてがコンパイルされていることを確認します（つまり、忘れないでください）。

アリとの統合。アプリケーションをビルドおよびデプロイするための1つのコマンド。

デバッガーとの統合（Webサーバーのリモートデバッグを含む）。

コードのセクションへの参照を検索する、素晴らしいリファクタリングツール。変更の影響を知るのに役立ちます。

全体として、それは私をより生産的にします。

Emacsを開発とメール/ニュースの両方の主要環境として約10年間（1994年から2004年）使用しました。2004年にJavaを学ぶように強いられたとき、IDEの力を発見しました。驚いたことに、IDE（IntelliJ IDEA）。

それらの多くはすでにここで言及されているので、私は特定の理由には入りません-異なる人々が異なる機能を愛していることを覚えておいてください。私と同僚は同じIDEを使用しましたが、どちらも使用可能な機能のほんの一部しか使用していませんでした。また、IDEの使用方法はお互いに嫌いでした（ただし、どちらもIDE自体が好きでした）。

しかし、Emacs / Vim関連の環境よりもIDEに焦点を当てたいという利点が1つあります。つまり、必要な機能をインストール/構成する時間を短縮できます。

ウイングIDE（Python用）私は、インストール後15〜20分の開発を開始する準備ができています。Emacs / Vimで使用して機能を実行するのに何時間かかるかわからない。:)

それは間違いなく私にとって生産性の向上につながります。VistaのVisual StudioでLinuxアプリケーションをコーディングし、Linux仮想マシンを使用してそれらを構築するところまでです。

関数やメソッドの呼び出しのすべての引数を覚えておく必要はありません。入力を始めると、IDEは必要な引数を表示します。プロジェクトのプロパティやコンパイラオプションなどを設定するためのウィザードが表示されます。現在のドキュメントやフォルダ内のファイルだけでなく、プロジェクト全体を通して検索することができます。コンパイラエラーが発生した場合は、それをダブルクリックすると、問題の行に移動します。

モデルエディター、外部データベースへの接続と閲覧、コード「スニペット」のコレクションの管理、GUIモデリングツールなどのツールの統合。これらすべてを個別に持つこともできますが、同じ開発環境内にすべてを置くと、多くの節約になります。時間を節約し、開発プロセスの流れを効率化します。

人によって理由はさまざまです。私にとってこれらは利点です。

1. プロジェクトに統合された感覚を提供します。たとえば、関連するすべてのプロジェクトファイルが1つのビューに表示されます。
2. 以下のようなコード生産性の向上を提供します
   1. 構文の強調表示
   2. アセンブリの参照
   3. Intellisense
   4. データベースと関連するUIファイルの集中管理されたビュー。
   5. デバッグ機能

結局のところ、メモ帳やワードパッドで行うよりも速くコーディングすることができます。それが私がIDEを好むかなり良い理由です。

IDE は、開発者が何を達成しようとしているのかに応じて、「優れた」選択になることがあります。

テキストエディターはIDEは通常、言語の1つ（または小さな選択）を対象としているため、「優れている」性があります。

開発者がほとんどの時間を1つのOSで単一の言語または関連言語（C＃やT-SQLなど）の「クラスター」に費やしている場合、GUI設計、デバッグ、インテリセンス、リファクタリングなどのツールが提供します。優れたIDEは非常に魅力的です。たとえば、ほとんどの時間をVB.NETで作業していて、たぶん少しT-SQLを使用していて、Windows環境では、Visual Studioや同等のIDEを見ないのはばかげているでしょう。 。

IDEやテキストエディタを好む人に偏見はありません。どちらも、よく学べば非常に生産的で便利です。

私はそれは主に開発者の意識の範囲に関係していると思います。IDEは、開発者の作業コンテキストの巨視的なビューを提供します。クラス階層、参照されるリソース、データベーススキーマ、SDKヘルプ参照などを同時に確認できます。また、キーストロークの影響や影響、およびアーキテクチャとアーキテクチャの共通部分の拡大により、ますます困難になります。一度に1つのコードアイランドからのみ作業します。

OTOH、「私とvimとmanページだけ」は、私の作品をより細かく、しかし強烈かつ正確に見ています。これは、1つの言語で構築された適切に設計され、適切にパーティション分割され、疎結合された非常にまとまりのあるコードベースと、動作する静的ライブラリのセットが1つである場合は問題ありません。時間、距離、および個人的な好みに応じて。

現在、Flexと.NETでプロジェクトに取り組んでいます。Flexの優れた点の1つは、データベースからデータをプルする、ファイルを開く/閉じる/読み取る/書き込むなど、標準的なことを実行するためのさまざまな方法がいくつかあることです（まだFlex Builder / Eclipse IDEを使用しています）。 -VSのような典型的なヘビーウェイトの例です。まだ基礎を学習していて、トレーニングホイールが必要です。自分のパターンに自信が持てたら、vimに戻ることを期待しています。）このビューでは、次のことができます。私はいくつかのことを本当によく知って、専門的に行う必要があります。

OTOH、私が.NETでその時点に到達することを想像することはできません。私が維持することを期待されているビューは、拡大とシフトを続けているためです。概念の整合性ははるかに低く、プロジェクトの数か月以上の開発者では一貫性がはるかに低くなりますが、IDEはそれをサポートしているため、推奨されています。したがって、開発者は本当にもっと多くのことを適切に知る必要があります（もっと簡単にできる）。これには、StackOverflowに関する質問の回答率が非常に高くなる（または理解される）のに役立つという利点もあります。つまり、より深い知識スタックを持つことができます。また、ヘルプに必要なさまざまな広告に対応できます。

物事は両方向に行き過ぎることがあります。おそらく「エディターのみ」のスコープでは、「ハンマーしかない場合、すべてが釘のように見えます」のようなものです。IDEのアプローチでは、一緒に固定したいものは何でも、ファスナーと関連するツールの幅広い選択肢から選択できます-ナル/ハンマー、ネジ/ドライバー、ボルト/レンチ、接着剤/グルーガン/クランプ、マグネット、そして次々と-すべてをあなたの指先で（あなたが始めるのに役立つウィザードを使って）。

それを排他的だと考えないでください。IDEを使用して、それが提供する利点を活用し、重要な焦点が必要な場合は、vim / preferredテキストエディターに切り替えます。

IDEは、リファクタリング、参照、デバッグ、および何をすべきかを理解するのに適しています。その後、小さなことはIDEで正しく行われ、大きなことは仕事を完了するためにvimに切り替えます。

他の回答に加えて、ViPlugin for Eclipseのようなものを使用して、IDEの開発力とVim の編集力を組み合わせることが大好きです。

IntelliSense、統合デバッガー、および即時ウィンドウにより、生産性が大幅に向上します（Visual Studio 2008）。コードを書いている間、すべてを手元に置いておけば、巨大なプロジェクトの大部分を頭の中に留めることができます。マイクロソフトはOSにボールを落とし続けるかもしれませんが、Visual Studioはこれまでに開発された最高の製品の1つです。

私はあなたが何を求めているのか理解できません。あなたは、「万一、私がIDEを使用する代わりに...」頼むが、私は選択肢が何であるかを理解していない- のVimとEmacsは任意のIDEはあなたを与える多くの機能を果たします。大規模なIDEで処理できない唯一の側面は、UIデザイナーなどです。次に、VimとEmacsのより単純な領域のために作成する引数を付けて、「どのIDEを使用すべきか」という質問に要約します。

私にとって、IDEはコード内でのより高速なナビゲーションを可能にするのでより優れています。実装する何かを考えている場合に重要です。IDEを使用しない場合、目的地に到達するまでに時間がかかります。あなたの考えはもっと頻繁に邪魔されるかもしれません。これは、より多くのクリック/より多くのキーを押す必要があることを意味します。物事をどのように実装するかという考えにもっと集中する必要があります。もちろん、書き留めることもできますが、設計と実装の間を行き来する必要があります。また、GUIデザイナーは大きな違いをもたらします。手作業で行うと、さらに時間がかかる場合があります。

Visual StudioやEclipseなどのGUIベースのIDEには、EmacsやvimなどのテキストベースのIDEに比べて、表示機能がいくつかあるため、いくつかの利点があります。

• GUI設計のためのWYSIWYGプレビューとライブ編集
• 効率的なプロパティエディター（たとえば、グラデーションストップの配置など、GUIパレットを使用した色の選択）
• コードの概要、ファイルの相互関係などのグラフィカルな描写
• 画面の不動産をより効率的に使用して、ブレークポイント、ブックマーク、エラーなどを表示する
• OSおよびその他のアプリケーションでのドラッグアンドドロップサポートの向上
• 図面、画像、3Dモデルなどの統合編集
• データベースモデルの表示と編集

基本的に、GUIベースのIDEを使用すると、画面上でより有用な情報を一度に取得でき、アプリケーションのグラフィック部分をテキスト部分と同じくらい簡単に表示/編集できます。

開発者が体験する最もクールなことの1つは、データを計算するメソッドを編集し、アプリの実行時にユーザーに表示されるのと同じように、コードのライブ出力を別のウィンドウにグラフィカルに表示することです。これがWYSIWYG編集です。

EmacsやvimのようなテキストベースのIDEは、時間の経過とともにコード補完やリファクタリングなどの機能を追加できるため、長期的には、主な制限はテキストベースの表示モデルです。

また、ほとんどすべての開発にVimを使用しています（ほとんどが今、emacsを習得しようとしているためです）。（もちろんGUIからの）完全な直感性が、人々がIDEを使いたい主な理由だと思います。直感的であるため、ツールの学習オーバーヘッドはほとんどまたはまったく必要ありません。学習のオーバーヘッドが少ないほど、より多くの作業を実行できます。

アンIDE速く仕事に1を可能にし、より簡単に...私は、単純なテキストエディタでコード内のナビゲートに多くの時間を費やして気づきました...

優れたIDEでは、IDEが関数、前の編集位置、変数へのジャンプをサポートしている場合、時間が短縮されます。また、優れたIDEは、起動時間として、さまざまな言語機能やプロジェクトを試す時間を短縮します。小さくすることができます。

IDEを使用するために考えられるいくつかの理由：

• 統合ヘルプがお気に入りです。
• Visual Studioのプレビューを備えた組み込みのリファクタリング
• IntelliSense、構文の強調表示、大規模プロジェクトのナビゲーションの容易さ、統合されたデバッグなど（ただし、アドインを使用すると、EmacsとVimでこれを多く利用できると思います）。
• また、最近のIDEはユーザーベースが広く、おそらくそのためのアドインを開発する人が多いと思いますが、私は間違っているかもしれません。

率直に言って、私はマウスが好きです。純粋なテキストベースのエディターを使用すると、寂しくなります。

開発にかかる時間を節約
統合されたデバッグ、インテリセンスなどの機能を提供することで節約し、生活を楽にします。

多くありますが、1つを使用することをお勧めします。

テキストエディタとIDEの間に明確な境界線があるかどうかはわかりません。あなたはスケールの片端にメモ帳のようなものを、もう片方には最新の最高のIDEを持っていますが、その間にはたくさんのものがあります。ほとんどのテキストエディタには構文の強調表示があります。プログラマー向けのエディターには、簡単なコードナビゲーションやオートコンプリートなど、他にもさまざまな機能があります。Emacsでは、デバッガーを統合することもできます。10年前のIDEでも、最近の本格的なテキストエディターに期待するよりも、プログラマーを支援する機能がはるかに少なかった。

1つを使用する主な理由は、コードが100ファイルを超える場合です。

ctagsはこの作業を実行できますが、一部のIDEには、ファイルを超高速で簡単にナビゲートするための非常に優れた方法があります。

やらなければならないことがたくさんあるときに時間を節約できます。

私にとってそれは、端末の古き良き時代に行ったすべてのGUIバージョンにすぎません。IDEは、特にリンクに関するものなど、多くのものを隠すため、IDEはそれほど優れていないことに常に同意しますが、Qtなどの特定の開発プラットフォームでは、顕著な利点があります。

他のビジュアルのような一部のIDEは、入力時にコードを解析し、コンパイルする前にエラーを検出しているように見えます。IDEだけがコンパイラーと緊密に連携して、入力したソースの問題をすぐに検出できるロジックのようです。

IDE /コマンドラインの炎上戦争が存在するという私の大胆な答えは、C言語とC ++の実行可能なビルドが、D言語とは異なり、標準化された観点からはあまりうまく処理されないためです。すべてのプラットフォームがコンパイル/リンクなどを独自の方法で処理するため、混乱を少なくするためにIDEを作成します。

あなたの観点から見ると、コマンドラインを使用する方が簡単かもしれません。標準オプションを備えたコンパイラが1つしかなかった場合、それは簡単だったでしょうが、C / C ++は柔軟性があるため、結局、すべてのプラットフォーム独自の方法で行うため、IDEはその方法の説明を無駄にしないでください。

実行可能ファイルがカーネルと通信する方法を学ぶことができる場合、またはコンパイラの設計について何か知っている場合は、適切なコマンドラインを使用する方法があるかもしれませんが、私はあなたが持っているとは思いません。

MicrosoftやAppleは、すべての悪のように、詳細を入力せずにアプリケーションを構築する簡単な方法を提案する必要があります。アプリケーションの構築はOSのアーキテクチャに直接依存するため、「標準」にはなりません。コマンドラインです。

シンプルで大きくて複雑なアプリケーションを、それが何をするのか深く掘り下げたくない場所に置くには-> IDE、ソフトウェアの小さな断片または単純なシステムソフトウェアデザイン->コマンドライン。もちろん、Makefileを組み込んだ気の利いたライブラリを除いて、それはまた別の話です。

また、IDEは、提供されたアプリケーションが皮肉なことにGUIまたはインターフェイスを持つか、OSに直接バインドされているものと関係がある場合に使用されると思います。繰り返しになりますが、知らないうちにUI / GUIを使用する人にも適しています。それがどのように機能するか、システムをプログラムする人々はそれをすべて必要としないでしょう。

IDEは単なる最新のたわごとですが、100年経ってもコマンドラインは存在し続けると思います。

私はIDEが好きです。それは多くの機能を指先で操作できるからです。プロジェクト内のファイルの編集/コンパイル/可視性は、すべてIDEで重視しています。現在はVisual Studioを使用していますが、以前の人生ではSlickEditを使用していたため、使用していないときよりも開発プロセスが合理化されました。

IDEを使用するかどうかを決定する際に考慮すべきことは1つだけです。それは、それによって生産性が向上するかどうかです。

短い質問なので短い答え:)

何をしているのか、何をしているのかによって大きく異なります。個人的には、IDEを使用しない傾向があります（または、「私のIDEは、vimを実行する3つのxterm、データベースクライアントを実行するxterm、およびほとんどの作業で「IDE」をどの程度広く定義したかに応じて、「bashプロンプトまたはテーリングログ」ですが、プラットフォームネイティブのGUIを開発していることに気づいた場合、言語に適したIDEに到達します。インスタント-IMO、IDE、およびグラフィックフォームの編集が明確に相互に行われます。