Hoje, gostaríamos de falar sobre alguns dos projetos atuais da equipe da plataforma IntelliJ que afetarão o IntelliJ IDEA e outros IDEs baseados em nossa plataforma. Os resultados desses projetos serão divulgados no próximo ano; Alguns deles já estarão na versão 2020.1, que será lançada na primavera. Os projetos sobre os quais gostaríamos de falar referem-se a duas grandes áreas: produtividade e suporte a cenários de desenvolvimento modernos.
Desempenho
Velocidade de indexação
A indexação no momento é um dos lugares mais problemáticos com o desempenho de nossos IDEs. Planejamos abordar sua solução de várias direções.
Primeiro, planejamos oferecer suporte a
fragmentos de índice prontos . Agora, em vez de cada cópia do IntelliJ IDEA voltar a indexar a classe java.lang.String, podemos fornecer um fragmento de índice pronto para o JDK para download, que pode ser reutilizado sem custos adicionais de CPU. Além do JDK, estamos explorando a possibilidade de fornecer fragmentos de índice prontos para bibliotecas do Maven Central, bem como para intérpretes e pacotes em outros IDEs. Também gostaríamos de permitir que equipes e organizações usassem fragmentos de índice prontos para o código de seus projetos, mas ainda não temos planos concretos para isso.
Em segundo lugar, planejamos tornar a indexação
menos prejudicial ao trabalho , disponibilizando uma ampla gama de ações durante a indexação.
Em terceiro lugar, planejamos detectar
anomalias de indexação e notificar os usuários sobre elas. Anomalias incluem arquivos indexados por muito tempo ou com muita freqüência, bem como reconstruções de índice causadas por exceções. Nosso objetivo é propor etapas concretas para resolver o problema e melhorar o desempenho do IDE.
E, finalmente, continuamos a lidar com a boa e velha otimização - para garantir que os índices não obtenham dados desnecessários, e o processo de indexação use os recursos mínimos possíveis.
Novo acesso multithread às estruturas de dados IDE
Outro ponto problemático no desempenho é o congelamento da interface do usuário. Este ano, construímos uma infraestrutura para coletar informações sobre esses problemas. Isso nos permitiu resolver muitos deles (por exemplo, criamos e usamos um mecanismo padrão para processamento assíncrono de eventos do sistema de arquivos). No próximo ano, planejamos avançar e executar
operações que modificam as estruturas de dados do fluxo da interface do usuário.
No início do IntelliJ IDEA, foi tomada uma decisão de arquitetura que exigia que todas as modificações das estruturas de dados IDE do fluxo da UI fossem realizadas. Isso inclui ações básicas (inserir um caractere em um documento) e operações demoradas (renomear um método chamado de muitos lugares). Essa arquitetura simplifica bastante o modelo de programação, mas obviamente degrada a capacidade de resposta da interface.
Nos últimos anos, aprendemos de alguma forma a contornar as limitações desse modelo, principalmente devido ao fato de dividirmos as operações demoradas no cálculo em segundo plano das alterações necessárias e, se possível, aplicar rapidamente essas alterações no fluxo da interface do usuário. A solução ideal seria remover completamente o requisito de fazer algo no encadeamento da interface do usuário, mas até agora não entendemos como isso pode ser alcançado sem reescrever todo o código IDE e plug-ins de terceiros. Agora, temos uma opção de arquitetura que nos permite migrar gradualmente o código para um novo modelo de multithreading, e estamos começando a trabalhar na sua implementação.
No próximo ano, planejamos adicionar suporte ao novo modelo de multithreading aos principais componentes da interface do usuário e APIs da plataforma. Quando percebermos que o novo modelo funciona de maneira estável e oferece as melhorias esperadas, mudaremos para ele e, assim, nos livraremos da principal fonte de problemas com o congelamento da interface do usuário.
Baixe e descarregue plugins sem reiniciar
Os primeiros resultados do trabalho nessa direção já estavam na
versão 2019.3 , que permite instalar plug-ins para temas de cores e layouts de teclado sem precisar reiniciar. Na próxima versão, planejamos expandir esse suporte para todos os tipos de plugins. Daremos suporte ao carregamento e descarregamento sem reinicialização para a maioria de nossos próprios plug-ins e publicamos
instruções de suporte para gravadores de plug-ins de terceiros.
Nesta fase, a principal vantagem será uma atualização de plug-in indolor que não requer reinicialização. No futuro, planejamos atingir um objetivo mais interessante: um IDE que baixe automaticamente apenas o conjunto necessário de plug-ins para cada projeto que você abrir nele. Use o Spring - o plug-in do Spring está sendo carregado, você precisa do Angular - o plug-in está ao seu dispor. Os plugins não utilizados serão automaticamente desativados e não consumirão recursos e ocuparão espaço na interface.
Suporte ao Script de Desenvolvimento
Edição colaborativa
A solicitação de suporte de co-edição obteve o maior número de votos em nosso rastreador de problemas e temos o prazer de anunciar que estamos trabalhando nessa funcionalidade. Em nossa abordagem atual, o IDE “principal” em execução na máquina em que o código-fonte editado está armazenado e os “thin clients” que podem se conectar ao IDE principal e não precisam ter sua própria cópia do código-fonte são distinguidos. Cada um dos clientes conectados possui seu próprio estado (um conjunto de arquivos abertos, uma posição de carro, uma lista de opções de preenchimento automático etc.), mas também pode "seguir" outro usuário, se desejar.
Os Thin Clients terão acesso às funcionalidades básicas do IDE, como navegação, preenchimento automático e depuração, mas não suportarão 100% das funções disponíveis. (Por exemplo, trabalhar com sistemas de controle de versão não está incluído no plano atual para o release inicial.) O conjunto exato de funções suportadas ainda não está definido e não estamos prontos para responder perguntas sobre o que será suportado e quando.
O suporte para co-edição é baseado no protocolo
Rider , portanto, o mais provável é que apareça inicialmente neste produto e depois se espalhe para outros IDEs. De qualquer forma, nada disso aparecerá na versão IntelliJ IDEA 2020.1 - este é um plano por um período mais longo.
Além disso, deve-se notar que, como a atual implementação de co-edição usa nosso próprio protocolo, ela não será compatível com ferramentas que não são do JetBrains.
A abordagem do thin client também pode ser útil para outros cenários, como mover o back-end do IDE para a nuvem, mas não estamos prontos para anunciar nenhum plano nessa área.
Suporte de lançamento na nuvem
Já há algum tempo, muitos de nossos produtos suportam código de execução e depuração em computadores remotos e em contêineres. Infelizmente, esse suporte é praticamente implementado em todos os lugares à sua maneira, e até mesmo recursos universais como o suporte do Docker parecem diferentes em diferentes IDEs.
Agora, estamos adicionando no nível da plataforma o conceito de "ambiente para execução", que fornece uma maneira de copiar arquivos de ou para ele, bem como iniciar processos nele. No IntelliJ IDEA 2020.1, oferecemos suporte à execução na máquina local, no contêiner do Docker e por meio de uma conexão ssh. Você pode escolher o ambiente a ser executado nas configurações de ativação para Java e Go.
Em versões futuras, planejamos unificar o suporte ao Docker e aos intérpretes remotos com base na nova arquitetura. Além disso, ofereceremos uma integração aprimorada com as nuvens, para que você possa iniciar o processo em uma nova máquina virtual na nuvem sem especificar o endereço específico da máquina à qual deseja se conectar.
Novo modelo de design
O modelo do projeto é como o IDE representa a estrutura do seu projeto: quais arquivos se relacionam com ele, como eles dependem um do outro, quais bibliotecas são usadas etc. O modelo de design do IntelliJ IDEA nos serviu bem ao longo dos anos, mas começamos a enfrentar suas limitações. Em primeiro lugar, não permite misturar aleatoriamente projetos de diferentes tipos. Você pode abrir um projeto Xcode nas soluções AppCode ou Visual Studio no Rider, mas não existe um IDE no qual você possa abrir os projetos Gradle e Xcode em uma janela. Em segundo lugar, ele funciona no nível do diretório e não permite que arquivos diferentes no mesmo diretório tenham dependências diferentes. Isso complica a integração com sistemas de construção como o Bazel e cria problemas em outros cenários.
O novo modelo de design, que chamamos de modelo de espaço de trabalho, remove essas limitações. Ele oferece outros benefícios, como uma abertura mais rápida do projeto, sincronização mais suave com o Maven e Gradle e um modelo de programação mais conveniente.
Começaremos transferindo a implementação das funções existentes para um novo modelo de projeto e, quando tudo funcionar de forma estável, começaremos a adicionar novas funções, como abrir um conjunto de projetos de diferentes tipos em uma janela do IDE.
Sumário
O que acabamos de falar é apenas uma pequena parte do trabalho da equipe, e planejamos contar mais sobre nossos planos após as férias. É claro que todos esses planos podem mudar, e pode muito bem ser que parte dessa história nunca seja divulgada, mas faremos outras melhorias legais para você.
Estamos ansiosos para ouvir de você. Além disso, convidamos você a participar do nosso Programa de acesso antecipado, que lhe dará a oportunidade de experimentar alguns desses recursos antes que eles cheguem ao lançamento oficial.