文章主要介绍了当前JetBrains 在改进 IntelliJ IDEA 和基于 IntelliJ 平台的 IDE 方面所做的一些工作，主要包括性能和对现代开发工作流的支持两个方面。
性能
索引性能
与IDE 性能有关的两个主要痛点是启动性能，索引耗时较长的工具被认为是重量级的。JetBrains 表示，明年关注点将转向索引性能方面。
针对此问题官方采取了多管齐下的方法。首先，支持使用预建的索引块，这样每个用户IntelliJ 实例都不必执行索引java.lang.String类的工作。
计划明年逐步提供支持，从JDK 开始，然后涵盖 Maven Central 的库以及其它 IDE 中的解释器和包。同时还在研究支持团队或企业内项目源代码的索引块共享的方法，虽然这一块目前还没有任何具体计划。
其次，计划通过在索引时提供更多的IDE 操作来减少索引的破坏性。
第三，将检测并通知用户有关索引异常的信息，包括索引花费时间太长的文件、索引重新建立频率太高的文件以及异常导致的索引重建，目的是提供解决这些问题并提高IDE 在项目上的性能的清晰步骤。
同时也计划支持进行旧性能优化，以确保索引系统不会执行任何不必要的工作并且不会产生可避免的开销。
读/写锁线程模型重新设计
UI 卡死（freeze，冻结）是一个很大的问题。今年虽然已经构建了用于报告此类卡死问题的基础，并进行了架构更改以修复许多相关问题，比如文件系统事件的异步侦听器，但是接下来的一年中，计划迈出更大的一步：将需要写锁定的操作移出 UI 线程。
早在IntelliJ IDEA 早期就做出了一项架构决定，该决定要求大多数操作需要修改 IDE 的内部数据结构才能在 UI 线程上运行，也就是包括基本操作（将字符插入文档中）和大规模操作（重新命名具有数千种用法的方法）。
这种架构的好处是简单的编程模型，但是明显的缺点是UI 响应能力在许多情况下都会受到影响。
多年以来，官方一直在寻找方法来解决此架构的局限性，主要是将大型操作拆分为在后台运行并应用于UI 线程的部分。一个更基本的解决方案是完全摆脱 UI 线程的要求，但是直到最近，还不知道如何在不对自己的代码和第三方插件进行重大重写的情况下做到这一点。
不过现在，JetBrains 已经有了一个允许逐步迁移的架构解决方案，并且正在开始实施。明年将重构 IntelliJ 平台的基本 UI 组件和 API，以采用新的线程模型。一旦新模型稳定并且可以看到改进，将在所有 IDE 中切换到新模型，从而使 UI 平滑且没有滞后。
无需重启即可加载和卸载插件
该特性已经在IntelliJ IDEA 2019.3 中预览，它使开发者不用重新启动就可以安装主题和键盘映射插件，无缝升级。2020.1 版本中会将此支持扩展到所有类型的插件。
计划将为大部分捆绑的插件提供支持，并且会为第三方插件开发人员提供支持说明。
这项工作更有意义的地方在于，它的最终目标是IDE 可以根据开发者打开的每个项目的大小自行调整大小，比如仅针对使用 Spring 的项目加载 Spring 插件，仅针对 Angular 项目加载 Angular 插件。
这样如果不使用某项技术，那么就不会看到与此相关的任何UI 元素，也不会看到支持该技术的插件对性能或内存使用量产生任何影响。
工作流支持
协同编辑
协同编辑是问题跟踪器中投票最高的请求，目前JetBrains 也在跟进这一功能。在目前采用的方法中，将有一个主 IDE 在运行源代码的计算机上运行，其他用户能够将其 IDE 作为“瘦客户机”连接到主 IDE，而无需直接进行源代码访问。
每个连接的用户都将具有自己的状态，包括打开文件集与插入号位置等，并且可以根据需要选择“跟随”另一个用户。
瘦客户机用户将有权访问核心IDE 功能，例如导航、补全和调试，但不能访问完整的功能集，例如，在初始版本中，瘦客户端可能无法执行版本控制操作。
协同编辑支持基于Rider 协议，因此很可能首先在 Rider 中发布，然后扩展到其它 IDE。不过这是一项长期工作，IntelliJ IDEA 2020.1 版本中暂时还是看不是相关成果的。
支持云执行
相当长一段时间以来，许多JetBrains 产品都支持在容器内运行和调试代码，但是，在不同产品中这些功能的实现之间并没有太多相关性，甚至基本功能（如 Docker 支持）的 UI 也不一致。
现在JetBrains 引入了目标环境的概念，该概念提供了一种可双向复制文件并在目标环境中启动进程的方法。在 IntelliJ IDEA 2020.1 中，受支持的环境将包括本地计算机、Docker 容器和通过 ssh 连接的计算机。
在后续发行版中，计划统一支持围绕新架构的现有Docker 和远程解释器。除此之外，还将提供更深入的云集成。
重新设计项目模型
项目模型是IDE 表示项目结构的方式：哪些文件属于该项目、它们如何相互依赖、使用哪些库……项目模型有一定的局限性，首先，它不支持任意混合不同类型的项目。
例如，AppCode 可以打开 Xcode 项目，Rider 可以打开 Visual Studio 解决方案，但是无法在同一 IDE 框架中打开 Gradle 项目和 Xcode 项目。
其次，项目模型在目录级别上工作，而不在文件级别上，并且它不能表示同一目录中具有不同依赖项的不同文件，这使得很难将诸如Bazel 之类的构建系统集成到 IDE 中，同时也给其它场景带来了问题。
重新设计的项目模型（内部称为“工作区模型”）将消除这些限制。同时它还带来了其它好处，例如在项目打开期间提高性能、与 Maven 和 Gradle 进行更顺畅的同步以及更好的编程模型。
所谓技多不压身，我们所读过的每一本书，所学过的每一门语言，在未来指不定都能给我们意想不到的回馈呢。其实做为一个开发者，有一个学习的氛围跟一个交流圈子特别重要这里我推荐一个Java学习交流群342016322，不管你是小白还是大牛欢迎入驻，大家一起交流成长。