Hari ini kami ingin berbicara tentang beberapa proyek saat ini dari tim Platform IntelliJ yang akan memengaruhi IntelliJ IDEA dan IDE lain berdasarkan platform kami. Hasil dari proyek-proyek ini akan dirilis pada tahun berikutnya; Beberapa dari mereka sudah ada dalam rilis 2020.1, yang akan dirilis pada musim semi. Proyek-proyek yang ingin kami bicarakan berhubungan dengan dua bidang besar: produktivitas dan dukungan untuk skenario pembangunan modern.
Performa
Kecepatan pengindeksan
Pengindeksan saat ini adalah salah satu tempat paling bermasalah dengan kinerja IDE kami. Kami berencana untuk mendekati solusinya dari beberapa arah.
Pertama, kami berencana untuk mendukung
fragmen indeks yang sudah jadi . Sekarang, alih-alih setiap salinan IntelliJ IDEA mengindeks ulang kelas java.lang.String, kami dapat menyediakan fragmen indeks yang sudah jadi untuk JDK untuk diunduh, yang dapat digunakan kembali tanpa biaya CPU tambahan. Selain JDK, kami sedang menjajaki kemungkinan menyediakan fragmen indeks siap pakai untuk perpustakaan dari Maven Central, serta untuk juru bahasa dan paket dalam IDE lain. Kami juga ingin mengizinkan tim dan organisasi untuk menggunakan fragmen indeks yang sudah jadi untuk kode proyek mereka, tetapi kami belum memiliki rencana konkret untuk ini.
Kedua, kami berencana untuk membuat pengindeksan
kurang menghambat pekerjaan dengan membuat berbagai tindakan yang lebih luas selama pengindeksan.
Ketiga, kami berencana mendeteksi
anomali pengindeksan dan memberi tahu pengguna tentang mereka. Anomali termasuk file yang diindeks terlalu lama atau terlalu sering, serta indeks membangun kembali yang disebabkan oleh pengecualian. Tujuan kami adalah mengusulkan langkah konkret untuk menyelesaikan masalah dan meningkatkan kinerja IDE.
Dan akhirnya, kami terus berurusan dengan optimasi lama yang baik - untuk memastikan bahwa indeks tidak mendapatkan data yang tidak perlu, dan proses pengindeksan menggunakan sumber daya seminimal mungkin.
Akses multi-utas baru ke struktur data IDE
Masalah lain dalam kinerja adalah pembekuan antarmuka pengguna. Tahun ini kami membangun infrastruktur untuk mengumpulkan informasi tentang masalah seperti itu. Ini memungkinkan kami untuk memecahkan banyak di antaranya (misalnya, kami membuat dan menggunakan mekanisme standar untuk pemrosesan peristiwa yang tidak sinkron dari sistem file). Tahun depan kami berencana untuk melangkah lebih jauh dan melakukan
operasi yang mengubah struktur data dari aliran UI.
Pada awal IntelliJ IDEA, keputusan arsitektur dibuat yang mengharuskan semua modifikasi struktur data IDE dari aliran UI harus dilakukan. Ini termasuk tindakan dasar (memasukkan karakter ke dalam dokumen) dan operasi yang panjang (mengganti nama metode yang dipanggil dari banyak tempat). Arsitektur ini sangat menyederhanakan model pemrograman, tetapi jelas menurunkan respons antarmuka.
Selama beberapa tahun terakhir, kami telah entah bagaimana belajar bagaimana menghindari keterbatasan model ini, terutama karena fakta bahwa kami membagi operasi yang panjang ke dalam perhitungan latar belakang dari perubahan yang diperlukan dan, sesegera mungkin, menerapkan perubahan ini dalam aliran UI. Solusi yang ideal adalah dengan sepenuhnya menghapus persyaratan untuk melakukan sesuatu di utas UI, tetapi sejauh ini kami belum mengerti bagaimana ini dapat dicapai tanpa menulis ulang seluruh kode IDE dan plugin pihak ketiga. Sekarang kami memiliki opsi arsitektur yang memungkinkan kami untuk secara bertahap memigrasi kode ke model multithreading baru, dan kami mulai bekerja pada implementasinya.
Selama tahun berikutnya, kami berencana untuk menambahkan dukungan untuk model multithreading baru ke komponen UI utama dan API platform. Ketika kita melihat bahwa model baru bekerja secara stabil dan memberikan perbaikan yang diharapkan, kita akan beralih ke sana dan dengan demikian menyingkirkan sumber masalah utama dengan pembekuan UI.
Unduh dan keluarkan plugin tanpa memulai ulang
Hasil pertama dari pekerjaan ke arah ini sudah ada di
rilis 2019.3 , yang memungkinkan Anda untuk menginstal plugin untuk tema warna dan tata letak keyboard tanpa me-reboot. Dalam versi berikutnya, kami berencana untuk memperluas dukungan ini ke semua jenis plugin. Kami akan mendukung pemuatan dan pembongkaran tanpa memulai ulang untuk sebagian besar plugin kami sendiri, dan kami telah menerbitkan
instruksi dukungan untuk penulis plugin pihak ketiga.
Pada tahap ini, keuntungan utama adalah pembaruan plug-in tanpa rasa sakit yang tidak memerlukan reboot. Di masa depan, kami berencana untuk mencapai tujuan yang lebih menarik: sebuah IDE yang secara otomatis mengunduh hanya set plug-in yang diperlukan untuk setiap proyek yang Anda buka di dalamnya. Gunakan Spring - plugin Spring memuat, Anda perlu Angular - plugin siap melayani Anda. Plugin yang tidak digunakan akan dinonaktifkan secara otomatis dan tidak akan menggunakan sumber daya dan menghabiskan ruang di antarmuka.
Dukungan Script Pengembangan
Pengeditan kolaboratif
Permintaan untuk dukungan pengeditan bersama mengumpulkan suara terbanyak dalam pelacak masalah kami, dan kami dengan senang hati mengumumkan bahwa kami sedang mengerjakan fungsi ini. Dalam pendekatan kami saat ini, IDE "utama" yang berjalan pada mesin tempat kode sumber yang diedit disimpan dan "thin client" yang dapat terhubung ke IDE utama dan tidak perlu memiliki salinan sendiri dari kode sumber dibedakan. Setiap klien yang terhubung memiliki status sendiri (satu set file terbuka, posisi carriage, daftar opsi penyelesaian otomatis, dll.), Tetapi juga dapat "mengikuti" pengguna lain jika diinginkan.
Thin Client akan memiliki akses ke fungsionalitas dasar IDE, seperti navigasi, penyelesaian otomatis dan debugging, tetapi tidak akan mendukung 100% dari fungsi yang tersedia. (Misalnya, bekerja dengan sistem kontrol versi tidak termasuk dalam rencana saat ini untuk rilis awal.) Kumpulan fungsi yang didukung saat ini tidak didefinisikan, dan kami tidak siap untuk menjawab pertanyaan tentang apa yang akan didukung dan kapan.
Dukungan untuk pengeditan bersama didasarkan pada protokol
Rider , jadi kemungkinan besar awalnya akan muncul di produk ini dan kemudian menyebar ke IDE lain. Bagaimanapun, semua ini tidak akan muncul dalam rilis IntelliJ IDEA 2020.1 - ini adalah rencana untuk periode yang lebih lama.
Selain itu, perlu dicatat bahwa karena implementasi penyuntingan bersama saat ini menggunakan protokol kami sendiri, itu tidak akan kompatibel dengan alat non-JetBrains.
Pendekatan thin client mungkin berguna untuk skenario lain, seperti memindahkan backend IDE ke cloud, tetapi kami tidak siap mengumumkan rencana apa pun di area ini.
Dukungan Peluncuran Cloud
Untuk beberapa waktu sekarang, banyak dari produk kami mendukung menjalankan dan men-debug kode pada komputer jarak jauh dan dalam wadah. Sayangnya, dukungan ini hampir di semua tempat diimplementasikan dengan caranya sendiri, dan bahkan fitur universal seperti dukungan Docker terlihat berbeda di berbagai IDE.
Sekarang kami menambahkan pada platform platform konsep "lingkungan untuk dieksekusi", yang menyediakan cara untuk menyalin file ke atau dari itu, serta memulai proses di dalamnya. Dalam IntelliJ IDEA 2020.1, kami mendukung eksekusi pada mesin lokal, dalam wadah Docker, dan melalui koneksi ssh. Anda dapat memilih lingkungan yang akan dijalankan dalam konfigurasi peluncuran untuk Java dan Go.
Dalam rilis mendatang, kami berencana untuk menyatukan dukungan untuk Docker dan interpreter jarak jauh berdasarkan arsitektur baru. Selain itu, kami akan menawarkan peningkatan integrasi dengan cloud sehingga Anda dapat memulai proses pada mesin virtual baru di cloud tanpa menentukan alamat spesifik mesin yang ingin Anda sambungkan.
Desain model desain baru
Model proyek adalah bagaimana IDE merepresentasikan struktur proyek Anda: file mana yang berhubungan dengannya, bagaimana mereka saling bergantung, perpustakaan mana yang digunakan, dll. Model desain IntelliJ IDEA telah melayani kami dengan baik selama bertahun-tahun, tetapi kami telah mulai mengalami keterbatasan. Pertama, itu tidak memungkinkan pencampuran proyek secara acak dari berbagai jenis. Anda dapat membuka proyek Xcode di AppCode atau solusi Visual Studio di Rider, tetapi tidak ada IDE di mana Anda bisa membuka proyek Gradle dan Xcode dalam satu jendela. Kedua, ini berfungsi pada level direktori dan tidak memungkinkan file yang berbeda dalam direktori yang sama memiliki dependensi yang berbeda. Ini mempersulit integrasi dengan sistem build seperti Bazel dan menciptakan masalah dalam skenario lain.
Model desain baru, yang kami sebut model ruang kerja, menghilangkan keterbatasan ini. Ini memberikan manfaat lain, seperti pembukaan proyek yang lebih cepat, sinkronisasi yang lebih lancar dengan Maven dan Gradle, dan model pemrograman yang lebih nyaman.
Kami akan mulai dengan mentransfer implementasi fungsi yang ada ke model proyek baru, dan kemudian, ketika semuanya akan bekerja secara stabil, kami akan mulai menambahkan fungsi baru, seperti membuka serangkaian proyek dari berbagai jenis dalam satu jendela IDE.
Ringkasan
Apa yang baru saja kita bicarakan hanyalah sebagian kecil dari apa yang sedang dikerjakan tim, dan kami berencana untuk memberi tahu lebih banyak tentang rencana kami setelah liburan. Tentu saja, semua rencana ini dapat berubah, dan mungkin sebagian cerita ini tidak akan pernah dirilis, tetapi kami akan membuat perbaikan keren lainnya untuk Anda.
Kami berharap dapat mendengar dari Anda. Selain itu, kami mengundang Anda untuk berpartisipasi dalam Program Akses Dini kami, yang akan memberi Anda kesempatan untuk mencoba beberapa fitur ini sebelum masuk ke rilis resmi.