لذلك ، أعمل على بحثي حول صعوبات دعم Legacy ، وقد لاحظت نقطة واحدة واضحة فقدت البصر عنها تمامًا.
يواجه مستخدمو IDE ومطورو IDE مشاكل في فهم أدواتهم. تستخدم بشكل حدسي وعلى أي حال. من المثير للدهشة (لطيف) أن هذا الاستخدام لا يتعارض مع الجهل ، على الرغم من أنه يؤدي إلى ظهور holivars في المنتديات.
سنقوم الآن بتحليل كيفية تطور الأشياء باستخدام الأدوات ، وما الخطأ في مفهوم "IDE" ، وأي الأدوات كان يجب أن تظهر ، ولكن لم يتم تطويرها بعد.
E
لن يكون الاكتشاف أن البيئة مختلفة بالنسبة للمشاريع المختلفة. حتى لو كانوا يعملون على كومة واحدة. يمكن استخدامها:
- طرق مختلفة للتفاعل مع المستخدم ، مما يعطي تباينًا كبيرًا حول كيفية بدء المشروع وكيفية اختباره. (CLI ، TUI ، كمامة الويب ، واجهة المستخدم الرسومية بمعنى Qt ، GTK ، إلخ.)
- أطر اختبار مختلفة (unittest في مشروع واحد ، pytest في مشروع مجاور ، في سياق بيثون). روابط الاختبارات متعددة المستويات (على سبيل المثال ، الجمع بين استنتاجات الاختبارات المستقلة والتكامل من خلال TAP) تقع هنا أيضًا.
- VCS مختلفة ، ولكن في مكان ما قد يكون هناك الهجينة (Git ، كعميل للتخريب في حالة خاصة).
- ضمن نفس المشروع يمكن استخدامها ، بما في ذلك مختلف المحررين. على سبيل المثال ، Vim أو nano لتحرير برنامج نصي rebase تفاعلي في Git ، لتحرير القطع مع التسجيل الجزئي للتغييرات. أو لتحرير التكوينات من تحت الجذر.
وهذه بعيدة كل البعد عن جميع الخيارات ، وأعتقد أن أي مطور لديه خبرة في مشروعين أو أكثر يمكنه طرح المزيد من الأمثلة المشابهة. غالبًا ما أسمعهم في شكل قصة "كيف أمضيت يومين لإنشاء مشروع لوظيفة جديدة".
من هذا يمكننا أن نستنتج أن تخطيط وتكوين بيئة التطوير في أي حال يقع على عاتق المستخدم.
المتكاملة؟
بالنظر إلى ما تقدم ، من المنطقي مراعاة البيئات "المتكاملة" ، ولكن "القابلة للتكامل" .
ثم ، من وجهة نظر المستخدم ، تكون أداة تكامل جيدة عندما:
- تم إعداد البيئة بسرعة.
- تكوينه يمكن تخزينها ونقلها.
- القدرة على إعادة رفع بيئة العمل "زر واحد".
على سبيل المثال ، غالبًا ما تقلل Unixoids من ذوي الخبرة من "الانتقال إلى وضع العمل" لفريق واحد.
"سريع" هنا لا يعني "سهل للمبتدئين" . شخصيا ، موقفي من هذه المسألة هو: الاعتماد على تعقيد حل المشكلة على تعقيد المهمة نفسها يجب أن يكون خطيا على الأقل.
نقطة أخرى غير واضحة: قد لا تكون الواجهة موحدة.
المثال الأكثر شيوعًا هو استخدام كل من واجهة المستخدم الرسومية و CLI في المشروع.
تحدثت عن استخدام العديد من المحررين عند العمل في نفس البيئة في مشروع واحد.
تنمية
الآن يمكننا أن ننتقل مباشرة إلى الأدوات نفسها.
مفاعلات المتصفحات
من المستحيل إنشاء مفاعل تفاعلي قوي وعالمي للمتصفح ببساطة لأن إعادة التوطين غير موجودة الآن ، كما هو مشروط ، الانضباط الأكاديمي.
بعد كل شيء ، تم تصميم كتاب فاولر حول جافا مع الحد الأدنى من الخطوات إلى الجانب. بالإضافة إلى ذلك ، يتم إرفاق تقنيات إعادة إنشاء المباني بسياق "مكتبة لغة النمط" بحيث يتم إنشاؤها في الحال بواسطة كل مبرمج واحد.
أعتقد أنه يمكن وصف المبادئ الأساسية لإعادة البناء من وجهة نظر اجتياز شجرة البيانات في أقسام التعليمات البرمجية ، ويمكن بالفعل استنباط تقنيات محددة منها . للقيام بذلك ، يجب أن يكون تطبيق refactor المستعرض:
- واجهة قابلة للمد بسهولة (لعرض التقنيات التي أنشأها المطور لتلبية احتياجاته الخاصة)
- يجب إخفاء المحللون والقاعدة (المبادئ المذكورة أعلاه) ونظام التحرير من أجل ترك المطور فرصة لتوسيع مجموعة التقنيات دون الحاجة إلى الدخول في أحشاء محرره. وهذا هو ، DSL لوصف تقنيات إعادة البناء.
- نظرًا لأن القابلية للتوسعة ستتبعها زيادة حادة في عدد الاستقبالات ، للعرض ، من الضروري مراعاة نطاق السياق من أجل عرض العمليات المنطبقة في موقف معين فقط في قائمة الاختيار.
وقت التشغيل شجرة تحليل البيانات.
هذا الجانب يدور حول دمج تصحيح الأخطاء وتحرير النص. في الواقع ، بالنسبة للغالبية العظمى من اللغات ، من أجل التحقق من مدى تأثير التغييرات على البرنامج ، من الضروري إعادة تشغيل البرنامج بشكل صريح. أسهل بكثير وأكثر مرئيًا (ونتيجة لذلك ، مع وجود عدد أقل من الأخطاء المحتملة) ، سيكون من الممكن أن نرى في مساحة واحدة كيف يتغير صفيف البيانات بالكامل في القسم الذي تم تصحيحه من الشفرة فور تحرير الشفرة.
يختلف تطوير مثل هذه الأداة للغات المختلفة بدرجة كبيرة من التعقيد ، وهذا ليس فقط مسألة بناء جملة وميزات النظام والأداء ، ولكن في جوهر كل لغة على حدة. بالنسبة للغة المعتمدة على البيانات ، فإن بناء هذا أسهل كثيرًا. مثال: مُنشئو التعبير العادي ، حيث يمكنك في هذه العملية أن ترى على الفور أجزاء النص التي يغطيها النص العادي.
الأكثر ، في رأيي ، العنصر الأكثر أهمية في هذه القائمة غير المكتملة.
نقسم جميع المعلومات التي يحتاجها المطور ، مباشرة ، إلى مجموعتين كبيرتين
- الوثائق.
- الاستقبالات \ تطوير الاستدلال.
أولاً ، لتبسيط عمل المبرمج ، يجب أن يكون الوصول إلى الوثائق مباشرة من نافذة المحرر.
تعمل IDEs والمحررين المتعددين على حل هذه المشكلة جيدًا: IDEs الخاصة بلغة معينة من Microsoft و Emacs باستخدام Info-mode و Frescobaldi و Sunny Builder؛ سواء لدمجها في المصدر ، وللخارجي. ومع ذلك ، فإن العديد من المكتبات والأطر تقوم الآن بتحميل وثائقها فقط على الشبكة و / أو استخدام تنسيقات مختلفة لتخزينها ، مما يعقد التكامل المحتمل في واجهة واحدة.
المجموعة الثانية هي أكثر إثارة للاهتمام.
ويغطي المعرفة ، البرمجة والتطوير على حد سواء ، والأساليب الخاصة بلغة / مكدس معين. في الوقت الحالي ، يتم التقاط هذا المكان بشكل كامل تقريبًا بواسطة Stack Overflow ، وحتى أنه يتم دمجه في IDE ، لكن جودة الخبرة هناك غالبًا ما تكون منخفضة . من أجل الخير ، سيكون اختيار القرارات والأخطاء والحيل الجيدة أكثر كفاءة بكثير وتقليلها إلى قاعدة معينة يمكن للمستخدم الاتصال بها عندما يحتاج إلى حل مشكلته.
بالإضافة إلى ذلك ، يسمح لك المحللون الحديثون بالتحذير من الأخطاء المحتملة التي لم ترتكب بعد . هذا هو ، في الواقع ، لدينا ، من وجهة نظر تقنية ، كل ما نحتاج إليه لإنشاء أنظمة متخصصة للمطورين الذين يقدمون حلولًا أثناء قيامنا بكتابة / تحرير التعليمات البرمجية. ما هو مفقود هو فقط قواعد القرار / الأساليب / الأخطاء أنفسهم.
استنتاج
لذلك ، ملخص:
- يجب أن يستند تطوير متصفحات refactor إلى العمليات على شجرة البيانات وأن يتم تقليلها إلى وصف يشبه DSL للنصوص البرمجية لتحرير الكود الآلي.
- يجب أن يأتي محللو وقت التشغيل إلى عرض فوري لتغييرات البيانات أثناء تحرير البرنامج وكتابته. وهذا يعني أن نهج JAI يمكن تطبيقه على لغات البرمجة الأخرى.
- قم بإزالة متصفح الويب من حالات المستخدم كوسيلة للبحث وقراءة الوثائق.
- نحتاج إلى تطوير مكون إضافي (نظرًا لحقيقة أن البيئة متنوعة) أنظمة متخصصة تساعد المطور في اتخاذ القرارات في هذه العملية.