使用ide的一个很好的理由是，它们是生产现代软件的公认方式。如果您不使用，那么您可能会使用“老式”的东西，如vi和emacs。这可能会导致人们得出结论——可能是错误的——你被困在自己的方式中，无法适应新的工作方式。在软件开发这样的行业——创意可能在短短几个月内就会过时——这是一种危险的状态。这可能会严重损害你未来的工作前景。

IDE处理繁重的工作，节省了您的时间。

它将所有相关的项目文件保存在一起，使协作变得容易。

您通常可以将源代码控制集成到IDE中，从而节省更多的繁重工作，并进一步增强协作。

如果它有自动完成功能，它可以帮助你探索你所选择的语言，还可以节省一些输入。

基本上，IDE减少了程序员的非编程工作。

我从相反的方向来回答这个问题。我从小就在Makefile+Emacs的环境中编程。从我最早的DOS编译器，微软的Quick C，我有一个IDE自动化的事情。我在Visual c++ 6.0上工作了很多年，当我毕业到Enterprise Java时，我使用Borland JBuilder，然后决定使用Eclipse，这对我来说已经变得非常高效。

Throughout my initial self-teaching, college, and now professional career, I have come to learn that any major software development done solely within the IDE becomes counterproductive. I say this because most IDE's wants you to work in their peculiar I-control-how-the-world-works style. You have to slice and dice your projects along their lines. You have manage your project builds using their odd dialog boxes. Most IDE's manage complex build dependencies between projects poorly, and dependencies can be difficult to get working 100%. I have been in situations where IDE's would not produce a working build of my code unless I did a Clean/Rebuild All. Finally, there's rarely a clean way to move your software out of development and into other environments like QA or Production from an IDE. It's usually a clicky fest to get all your deployment units built, or you've got some awkward tool that the IDE vendor gives you to bundle stuff up. But again, that tool usually demands that your project and build structure absolutely conforms to their rules - and sometimes that just won't work for your projects' requirements.

我了解到，要与团队一起进行大规模开发，如果我们使用IDE开发代码，并使用手动编写的命令行脚本进行所有构建，那么我们可以获得最高的效率。(我们喜欢用Apache Ant进行Java开发。)我们发现在IDE中运行我们的脚本对于复杂的构建来说只是一个点击或者自动化的噩梦，用alt+tab到一个shell并在那里运行脚本要容易得多(而且破坏性更小)。

Manual builds requires us to miss out on some of the niceties in the modern IDE like background compilation, but what we gain is much more critical: clean and easy builds that can live in multiple environments. The "one click build" all those agile guys talk about? We have it. Our build scripts can be directly invoked by continuous integration systems as well. Having builds managed through continuous integration allows us to more formally stage and migrate your code deployments to different environments, and lets us know almost immediately when someone checks in bad code that breaks the build or unit tests.

In truth, my taking the role of build away from the IDE hasn't hurt us too badly. The intellisense and refactoring tools in Eclipse are still completely useful and valid - the background compilation simply serves to support those tools. And, Eclipse's peculiar slicing of projects has served as a very nice way to mentally break down our problem sets in a way everyone can understand (still a tad bit verbose for my tastes though). I think one of the most important things about Eclipse is the excellent SCM integrations, that's what makes team development so enjoyable. We use Subversion+Eclipse, and that has been very productive and very easy to train our people to become experts at.

我不明白你在问什么。你问“我应该使用IDE而不是……”，但我不明白替代方案是什么——Vim和Emacs实现了任何IDE都能提供的许多功能。它们唯一不能处理的方面是，一个更大的IDE可能是像UI设计器。然后，您的问题可以归结为“我应该使用哪种IDE”，并为更简单的Vim和Emacs领域提供了论据。

不要认为这是排他性的。使用IDE来获得它所提供的好处，当需要集中精力时切换到vim/首选的文本编辑器。

我发现IDE更适合重构、浏览、调试以及找出要做的事情。然后在IDE中完成小的事情，大的事情我切换到vim来完成。

I'm not sure there's a clear dividing line between a text editor and an IDE. You have the likes of Notepad at one end of the scale, and the best modern IDEs at the other, but there are a lot of thing in between. Most text editors have syntax highlighting; editors aimed at programmers often have various other features such as easy code navigation and auto complete. Emacs even lets you integrate a debugger. The IDEs of even ten years ago had far less features to help programmers than you'd expect of a serious text editor these days.