多年来，我观察到了从Eclipse到IntelliJIDEA的不可避免的转变。去年我觉得事情更倾向于想法。
IDEA就像IDES的iPhone--它的用户告诉你，“一旦你习惯了它，你会觉得它有多好”，“你还在使用Eclipse吗？”，“想法好多了，我以为每个人都已经切换了”等等。
过去12年来，我主要使用Eclipse，但在某些情况下，我确实使用了IDEA--当我编写Scala、编写Android时，以及最近一次--Eclipse未能为Java 9版本做好准备，因此，经过半天的努力，我切换到了IDEA，直到Eclipse最终获得了一个正常工作的Java 9版本(包括Maven和其他内容)。
但我很快就会再回到Eclipse。我还是比较喜欢。不仅仅是因为我已经内化了所有的关键组合(你可以在思想中重用这些组合)，还因为我仍然发现一些想法更糟糕的东西。当然，IDEA还有很多很酷的特性，比如代码改进建议，以及所有的插件。但至少我看到的一些问题与更基本的开发流程和经验有关。你不能补偿那些有糖衣的人。所以他们在这里：
https://www.bilibili.com/medialist/detail/ml1349706699
- 项目不会自动生成(默认情况下)，因此，在打开非编译文件或运行生成之前，您可能不会看到编译错误。把汽车人打开让我的机器爬行。我知道我需要一个升级，但这不是重点-没有“基于改变”是一个巨大的惊喜，我第一次尝试的想法。我最结果是“这是个特征”。理由似乎是，如果您使用重构，这是不应该发生的。有很多这样的情况发生。通过添加方法参数、更改参数的类型、删除参数(IDE无法根据类型推断删除哪个参数)、通过更改返回类型进行重构。此外，Maven/Gradle依赖项中的更改可能会带来您看不到的编译问题。这根本不是一个合理的默认，我认为性能问题是它仍然是默认的唯一原因。我认为这会让这段经历变得更糟。
- 每个屏幕只能有一个项目。也许有些小公司的绿地项目，你只需要一个。但我从来没有遇到过这样的情况，你至少偶尔不需要一个单独的项目。不管是“实验”还是“工具”，还是别的什么。而不是，多模块maven项目(其中的想法处理得很好)是不够的。因此，每次您需要走出您的主要项目，您启动另一个屏幕。除了糟糕的可用性，它还有一些内存开销。
- 说到内存，它似乎占用了比Eclipse更多的内存。我没有有代表性的基准测试，我知道我的8GB内存家庭机器现在是小规模的开发，但仍然。
- 它让人感觉反应迟钝，笨重。有一些小的延迟，我不能很好地定义，但是“我感觉到了”。我在某个地方读到他们过度地重新绘制屏幕元素，所以这可能是解释。Eclipse感觉更流畅(我知道这不是一个恰当的论点，但我不能再精确了)
- 由于一些额外的聪明，我有“未使用的方法”和“从未分配的字段”围绕着项目。它使用了Spring，因此这些方法和字段都是控制器方法和自动字段。也许一些Spring插件会解决这个问题，但是Spring并不是唯一使用反射的框架。即使是POJO上的getter和setter也会得到未使用的警告。这些警告有什么问题？警告被贬值了。他们现在什么都没有了。类中也没有“黄色”指示符，因此实际上看不到警告的数量。Eclipse更好地显示警告，而假阳性则要少得多。
- 调用层次结构稍微差一些。但是，因为这是我最重要的IDE特性(与重构一起)，所以这很重要。它不会为您提供未显式定义的默认构造函数的调用层次结构。而且，据我所见，IDEA用户并不经常使用调用层次结构特性。“查找使用”我认为早在调用层次结构之前，而且在UI中也更明显，因此一些想法用户甚至不知道调用层次结构是什么。反复做“查找用法”。这只是IDE的一部分错。
- 输出控制台中没有搜索。来吧，为什么我有一个IDE，我必须复制输出并将其粘贴到文本编辑器中才能进行搜索。现在，为了澄清，控制台确实有搜索。但是，当我运行我的(Spring-boot)应用程序时，它会在底部的面板中输出不是控制台的内容(它被称为没有搜索。
- 默认情况下，Ctrl+箭头跳过整个单词，而不是骆驼大写单词。这是可配置的，但这是另一个奇怪的默认。您几乎总是希望能够逐字遍历变量(在CAMEL情况下)，而不是跳过整个变量(方法/类)名称。https://www.bilibili.com/medialist/detail/ml1349706699
- 几年前，当我将它用于Scala时，这个项目从未真正编译过。但我想这更多是Scala的错，而不是IDE的错
https://zhuanlan.zhihu.com/p/410211718
除了前两个问题外，其余都不是主要问题，我同意。但它们加起来了。最终，你是否能对这些问题视而不见，这是个人选择的问题。但我又要回Eclipse了。在某些时候，我将提议改进IntelliJ的IDEA待办事项，并将在几年后再次检查，我想。
优秀的开发人员是很好的问题解决者。他们把每一项任务转化成一系列他们必须解决的问题。他们不一定知道如何提前解决问题，但他们有他们的工具箱的方法，快捷方式和其他技巧，导致解决方识别问题，但您不能轻松地将解决问题的方法正式化。
但是，把一项任务变成一组问题真的是个好主意吗？编程可以被看作是一个创造性的练习，而不是一个解决问题的练习--你思考，你思考，你深思熟虑，然后你从无到有地做些什么，而且它很漂亮，因为它很有用。有时候编程是这样的，但这几乎总是被一系列的问题所打断，这些问题阻碍了你完成任务。这个过程最好用以下短片来表现：
https://www.itangyuan.com/book/16337053.html
时问题不多，发展也很顺利。然后，好的问题解决程序主动地识别问题--这个实现很慢，这太消耗内存，这太复杂了，应该重新分解。这些步骤可以(而且应该)是不干扰开发过程的小步骤，让您在没有明显原因的情况下进行2天的深度重构。技巧是知道在问题发生之前逐步改进和发现问题之间的界限，以及在不存在或永远不会遇到的问题上浪费时间。
最后，解决问题不是一个单独的练习。事实上，我认为解决问题最重要的方面之一就是回答问题。如果你想成为一个好的开发人员，你必须回答别人的问题。你的同事在大多数情况下，但有时-完全陌生的堆叠溢出。我自己发现，回答堆叠溢出问题实际上把我变成了一个更好的问题解决者--我可以在有限的时间内用有限的信息解决其他问题。因此，在很多情况下，当出现问题时，我是团队中的一员，即使我不是*的，也不是最熟悉这个项目的。但人们可以合理地预期，我将能够迅速找到一个适当的解决方案。然后循环继续--回答更多的问题，更好地解决问题，诸如此类。顺便说一句，我们不应该认为我们是好的，除非我们能够解决别人的问题，除了我们的