نود اليوم التحدث عن بعض المشاريع الحالية لفريق IntelliJ Platform والتي ستؤثر على IntelliJ IDEA و IDEs الأخرى بناءً على نظامنا الأساسي. ستصدر نتائج هذه المشاريع خلال العام المقبل ؛ سيكون بعضها بالفعل في إصدار 2020.1 ، الذي سيتم إصداره في الربيع. المشاريع التي نود التحدث عنها تتعلق بمجالين كبيرين: الإنتاجية ودعم سيناريوهات التنمية الحديثة.
إنتاجية
سرعة الفهرسة
الفهرسة في الوقت الحالي هي واحدة من أكثر الأماكن إشكالية مع أداء IDEs لدينا. نحن نخطط للوصول إلى حل من عدة اتجاهات.
أولاً ، نخطط لدعم
أجزاء المؤشر الجاهزة . الآن ، بدلاً من كل نسخة من IntelliJ IDEA تعيد فهرسة فئة java.lang.String ، يمكننا توفير جزء فهرس جاهز لـ JDK للتنزيل ، والذي يمكن إعادة استخدامه دون تكاليف وحدة المعالجة المركزية الإضافية. بالإضافة إلى JDK ، نحن نستكشف إمكانية توفير شظايا فهرس جاهزة للمكتبات من Maven Central ، وكذلك للمترجمين الفوريين والحزم في IDEs الأخرى. نود أيضًا السماح للفرق والمؤسسات باستخدام شظايا الفهرس الجاهزة لرمز مشاريعهم ، لكن ليس لدينا خطط محددة لذلك.
ثانياً ، نخطط لجعل الفهرسة
أقل عائقًا أمام العمل من خلال إتاحة نطاق أوسع من الإجراءات أثناء الفهرسة.
ثالثًا ، نعتزم اكتشاف
فهرسة الحالات الشاذة وإبلاغ المستخدمين عنها. تتضمن الحالات الشاذة الملفات التي تم فهرستها لفترة طويلة جدًا أو كثيرًا ، بالإضافة إلى عمليات إعادة إنشاء الفهرس التي تسببها الاستثناءات. هدفنا هو اقتراح خطوات ملموسة لحل المشكلة وتحسين أداء IDE.
وأخيرًا ، نواصل التعامل مع التحسين القديم الجيد - لضمان عدم حصول الفهارس على بيانات غير ضرورية ، وتستخدم عملية الفهرسة الحد الأدنى من الموارد الممكنة.
وصول جديد متعدد الخيوط إلى هياكل البيانات IDE
مشكلة أخرى في الأداء هي تجميد واجهة المستخدم. هذا العام قمنا ببناء بنية تحتية لجمع المعلومات حول هذه المشاكل. سمح لنا ذلك بحل العديد منها (على سبيل المثال ، أنشأنا واستخدمنا آلية قياسية للمعالجة غير المتزامنة للأحداث من نظام الملفات). في العام المقبل ، نخطط للمضي قدمًا وإخراج
العمليات التي تعدل هياكل البيانات من دفق واجهة المستخدم.
في فجر IntelliJ IDEA ، تم اتخاذ قرار معماري يتطلب إجراء جميع التعديلات على هياكل بيانات IDE من دفق واجهة المستخدم. يتضمن هذا كلاً من الإجراءات الأساسية (إدراج حرف في مستند) وعمليات طويلة (إعادة تسمية طريقة تسمى من العديد من الأماكن). تعمل هذه البنية على تبسيط نموذج البرمجة إلى حد كبير ، لكن من الواضح أن هذا يقلل من استجابة الواجهة.
خلال السنوات الماضية ، تعلمنا بطريقة ما التحايل على قيود هذا النموذج ، ويرجع ذلك أساسًا إلى حقيقة أننا نقسم العمليات الطويلة إلى حساب الخلفية للتغييرات الضرورية ، وفي أقرب وقت ممكن ، تطبيق هذه التغييرات في دفق واجهة المستخدم. سيكون الحل المثالي هو إزالة متطلبات القيام بشيء ما في مؤشر ترابط واجهة المستخدم بالكامل ، ولكن حتى الآن لم نفهم كيف يمكن تحقيق ذلك دون إعادة كتابة رمز IDE بالكامل والإضافات الخارجية. الآن لدينا خيار هندسة يسمح لنا بترحيل الكود تدريجيًا إلى نموذج متعدد مؤشرات ترابط جديد ، وبدأنا العمل على تنفيذه.
خلال العام المقبل ، نخطط لإضافة دعم لنموذج تعدد العمليات الجديد لمكونات واجهة المستخدم الرئيسية وواجهة برمجة التطبيقات للنظام الأساسي. عندما نرى أن النموذج الجديد يعمل بشكل مستقر ويعطي التحسينات المتوقعة ، فإننا سنتحول إليه وبالتالي نتخلص من المصدر الرئيسي لمشاكل تجميد واجهة المستخدم.
قم بتنزيل وتفريغ المكونات الإضافية دون إعادة التشغيل
كانت النتائج الأولى للعمل في هذا الاتجاه موجودة بالفعل في
إصدار 2019.3 ، والذي يسمح لك بتثبيت مكونات
إضافية للسمات اللونية وتخطيطات لوحة المفاتيح دون إعادة التشغيل. في الإصدار التالي ، نخطط لتوسيع هذا الدعم ليشمل جميع أنواع المكونات الإضافية. سوف ندعم التحميل والتفريغ دون إعادة التشغيل لمعظم المكونات الإضافية الخاصة بنا ، وقد نشرنا
تعليمات الدعم لكتاب إضافات الجهات الخارجية.
في هذه المرحلة ، ستكون الميزة الرئيسية هي تحديث مكون غير مؤلم لا يتطلب إعادة تشغيل الكمبيوتر. في المستقبل ، نخطط لتحقيق هدف أكثر إثارة للاهتمام: IDE الذي يقوم تلقائيًا بتنزيل المجموعة الإضافية فقط من المكونات الإضافية لكل مشروع تقوم بفتحه فيه. استخدم Spring - يتم تحميل المكون الإضافي Spring ، ستحتاج إلى Angular - المكون الإضافي في خدمتك. سيتم تعطيل المكونات الإضافية غير المستخدمة تلقائيًا ولن تستهلك الموارد وستشغل مساحة في الواجهة.
دعم سيناريو التنمية
التحرير التعاوني
حصل طلب دعم التحرير المشترك على أكبر عدد من الأصوات في برنامج تتبع المشكلات ، ويسرنا أن نعلن أننا نعمل على هذه الوظيفة. في نهجنا الحالي ، يتم تشغيل IDE "الرئيسي" الذي يعمل على الجهاز حيث يتم تخزين شفرة المصدر المحرر ويتم تمييز "العملاء النحيفين" الذين يمكنهم الاتصال بـ IDE الرئيسي ولا يحتاجون إلى الحصول على نسخة خاصة بهم من الكود المصدري. كل من العملاء المتصلين له حالته الخاصة (مجموعة من الملفات المفتوحة ، وموقف النقل ، وقائمة خيارات الإكمال التلقائي ، وما إلى ذلك) ، ولكن يمكنه أيضًا "متابعة" مستخدم آخر عند الرغبة.
سيكون بإمكان عملاء Thin Client الوصول إلى الوظائف الأساسية لـ IDE ، مثل التنقل والإكمال التلقائي والتصحيح ، لكن لن يدعموا 100٪ من الوظائف المتاحة. (على سبيل المثال ، لا يتم تضمين العمل مع أنظمة التحكم في الإصدار في الخطة الحالية للإصدار الأولي.) لم يتم تعريف المجموعة الدقيقة للوظائف المدعومة حاليًا ، ونحن لسنا مستعدين للإجابة على أسئلة حول ما سيتم دعمه ومتى.
يعتمد دعم التحرير المشترك على بروتوكول
Rider ، لذلك على الأرجح سيظهر في البداية في هذا المنتج ثم ينتشر إلى IDEs الأخرى. على أي حال ، لن يظهر أي من هذا في إصدار IntelliJ IDEA 2020.1 - هذه خطة لفترة أطول.
بالإضافة إلى ذلك ، تجدر الإشارة إلى أنه نظرًا لأن تطبيق التحرير المشترك الحالي يستخدم بروتوكولنا الخاص به ، فلن يكون متوافقًا مع الأدوات غير الخاصة بـ JetBrains.
قد يكون نهج العميل الرفيع مفيدًا أيضًا للسيناريوهات الأخرى ، مثل نقل واجهة IDE الخلفية إلى السحابة ، لكننا لسنا مستعدين للإعلان عن أي خطط في هذا المجال.
سحابة إطلاق الدعم
لبعض الوقت الآن ، العديد من منتجاتنا تدعم تشغيل ورمز التصحيح على أجهزة الكمبيوتر البعيدة وفي حاويات. لسوء الحظ ، يتم تطبيق هذا الدعم في كل مكان تقريبًا بطريقته الخاصة ، وحتى الميزات العالمية مثل دعم Docker تبدو مختلفة في بيئات IDE مختلفة.
الآن نقوم بإضافة مستوى "بيئة للتنفيذ" على مستوى المنصة ، والذي يوفر وسيلة لنسخ الملفات منه أو منه ، وكذلك بدء العمليات فيه. في IntelliJ IDEA 2020.1 ، ندعم التنفيذ على الجهاز المحلي ، في حاوية Docker ، ومن خلال اتصال ssh. يمكنك اختيار البيئة لتشغيلها في تكوينات التشغيل لـ Java و Go.
في الإصدارات المستقبلية ، نخطط لتوحيد دعم Docker والمترجمين الفوريين عن بُعد استنادًا إلى البنية الجديدة. بالإضافة إلى ذلك ، سوف نقدم تكاملًا محسّنًا مع السحب بحيث يمكنك بدء العملية على جهاز افتراضي جديد في السحابة دون تحديد عنوان الجهاز المحدد الذي تريد الاتصال به.
تصميم نموذج تصميم جديد
نموذج المشروع هو كيف يمثل IDE هيكل مشروعك: أي الملفات مرتبطة به ، وكيف يعتمدون على بعضهم البعض ، وما هي المكتبات المستخدمة ، وما إلى ذلك. لقد خدمنا نموذج تصميم IntelliJ IDEA جيدًا على مر السنين ، لكننا بدأنا نواجه قيوده. أولاً ، لا يسمح بالخلط العشوائي للمشاريع من أنواع مختلفة. يمكنك فتح مشروع Xcode في حلول AppCode أو Visual Studio في Rider ، لكن لا يوجد IDE من هذا القبيل يمكنك فتح مشروعات Gradle و Xcode به في نافذة واحدة. ثانياً ، إنه يعمل على مستوى الدليل ولا يسمح للملفات المختلفة في نفس الدليل أن يكون لها تبعيات مختلفة. هذا يعقد التكامل مع أنظمة البناء مثل Bazel ويخلق مشاكل في السيناريوهات الأخرى.
يزيل نموذج التصميم الجديد ، الذي نسميه نموذج مساحة العمل ، هذه القيود. يوفر مزايا أخرى ، مثل فتح المشروع بشكل أسرع وتزامن أكثر سلاسة مع Maven و Gradle ، ونموذج برمجة أكثر ملاءمة.
سنبدأ بنقل تنفيذ الوظائف الحالية إلى نموذج مشروع جديد ، وبعد ذلك ، عندما يعمل كل شيء بشكل مستقر ، سنبدأ في إضافة وظائف جديدة ، مثل فتح مجموعة من المشاريع من أنواع مختلفة في نافذة IDE واحدة.
ملخص
ما تحدثنا عنه للتو ليس سوى جزء صغير من ما يعمل عليه الفريق ، ونخطط لمعرفة المزيد حول خططنا بعد العطلة. بالطبع ، كل هذه الخطط يمكن أن تتغير ، وقد يكون من الجيد جدًا ألا يتم إطلاق بعض هذه القصة ، لكننا سنجري تحسينات رائعة أخرى لك.
نحن نتطلع الى الاستماع منك. بالإضافة إلى ذلك ، ندعوك للمشاركة في برنامج الوصول المبكر الخاص بنا ، والذي سيتيح لك الفرصة لتجربة بعض هذه الميزات قبل بدء الإصدار الرسمي.