التوافق في المنظومة المتكاملة لإطار عمل JavaScript
في مشاركة المدونة التمهيدية، تناولنا كيف تعلمنا الكثير أثناء إنشاء واستخدام أُطر العمل والأدوات لتطوير تطبيقات الويب الواسعة النطاق وصيانتها، مثل "بحث Google" و"خرائط Google" و"صور Google" وغيرها. ومن خلال حماية المطوّرين من كتابة الرموز البرمجية التي يمكن أن تؤثّر سلبًا في تجربة المستخدم، أثبتنا أنّ أُطر العمل يمكن أن تؤدي دورًا رئيسيًا في تغيير النتائج المتعلّقة بالأداء وجودة التطبيقات.
استخدمنا على المستوى الداخلي في Google مصطلح "التوافق" لوصف هذه المنهجية، وتتناول هذه المقالة كيف نخطط لإتاحة هذا المفهوم كمصدر مفتوح للمنظومة المتكاملة لإطار عمل JavaScript.
ما المقصود بالمطابقة؟
في Google، شهدَت المطابقة تطورًا. واعتمدت الفِرق على مجموعة صغيرة من خبراء الصيانة ذوي الخبرة الكبيرة الذين أجروا مراجعات شاملة للرموز، وأبلغوا عن الأشياء التي أثرت على جودة التطبيق والمحافظة على خدمته بشكل يتجاوز مشاكل الصحة. ولتوسيع نطاق ذلك ليشمل الفِرق المتنامية من مطوّري التطبيقات، تم تطوير نظام مطابقة لتنظيم أفضل الممارسات بطريقة مبرمَجة وقابلة للتنفيذ. وقد ضمن ذلك تحقيق مستوى عالٍ بشكل متّسق بشأن جودة التطبيق وإمكانية صيانة قاعدة الرموز بغض النظر عن عدد المساهمين في الرموز.
المطابقة هو نظام يضمن بقاء المطورين على المسار الصحيح. وهو يبني الثقة ويضمن الحصول على نتائج يمكن التنبؤ بها. فهو يجعل الفِرق منتجة، ويصبح أمرًا بالغ الأهمية للتوسع، مع نمو الفرق وتطوير المزيد من الميزات في الوقت نفسه. ويمكّن هذا الإصدار المطوّرين من التركيز على إنشاء ميزات المنتج وتحريرها من التفاصيل المصغّرة والبيئة المتغيّرة في مختلف المجالات، مثل الأداء وتسهيل الاستخدام والأمان وما إلى ذلك.
ويرتكز التوافق على إعدادات تلقائية قوية، ويوفّر قواعد قابلة للتنفيذ يمكن فرضها في وقت صياغة الرسالة. ينقسم هذا إلى المبادئ الثلاثة التالية.
1- الإعدادات التلقائية القوية
يتمثل أحد الجوانب الأساسية للمطابقة في التأكد من أن الأدوات التي يستخدمها المطورون لديها إعدادات افتراضية قوية. هذا يعني أن الحلول لا تكون مدمجة في أطر عمل فحسب، ولكن أيضًا أن أنماط تصميم إطار العمل تجعل من السهل فعل الشيء الصحيح ويصعب اتباع الأنماط المناهضة. يدعم إطار العمل المطورين من خلال تصميم التطبيق وبنية التعليمات البرمجية.
لتحسين أداء التحميل، يجب تحسين كل مورد (الخطوط وCSS وJavaScript والصور وغيرها). يمثّل هذا الأمر تحديًا معقّدًا يتضمّن قطع وحدات البايت وتقليل عمليات الإرسال والاستقبال وفصل ما هو مطلوب للعرض الأول والاستعداد المرئي وتفاعل المستخدم. على سبيل المثال، استخراج محتوى CSS المهم وتحديد الأولوية للصور المهمة.
2. قواعد قابلة للتنفيذ
حتى مع تطبيق التحسينات الأساسية، لا يزال يتعين على المطورين اتخاذ خيارات. هناك مجموعة متنوعة من إمكانيات التحسينات عندما يتعلق الأمر بالمقدار الذي يحتاجه المطوّرون من ملاحظات:
- إعدادات تلقائية لا تتطلّب أي بيانات من المطوّر، مثل تضمين محتوى CSS المهم
- يجب الحصول على موافقة مطوّر البرامج. على سبيل المثال، استخدام مكوِّن صورة يوفّره إطار العمل لضبط حجم الصور وقياسها.
- عليك طلب موافقة المطوّر وتخصيصه. على سبيل المثال، وضع علامات على الصور المهمة لتحميلها في وقت مبكر.
- هذه الميزات ليست محدّدة، ولكن يجب أن يتّخذ المطوّر قرارًا بشأنها. على سبيل المثال، يؤدي ذلك إلى تجنّب الخطوط أو النصوص البرمجية المتزامنة التي تؤدي إلى تأخير العرض المبكر.
إنّ التحسينات التي تتطلب اتخاذ أي قرار من جانب المطوّرين تشكِّل خطرًا على أداء التطبيق. مع إضافة الميزات وتوسيع نطاق فريقك، لا يمكن حتى للمطوّرين الأكثر خبرة مواكبة أفضل الممارسات المتغيّرة باستمرار، وكذلك ليس من الأفضل استغلال وقتهم. بالنسبة إلى التوافق، فإن القواعد الملائمة القابلة للتنفيذ لا تقل أهمية عن الإعدادات التلقائية القوية لضمان استمرار التطبيق في استيفاء معيار معين حتى عندما يواصل المطورون إجراء التغييرات.
3- وقت الكتابة
ومن المهم اكتشاف مشاكل الأداء ومنعها في وقت مبكر من دورة حياة التطوير. يعد وقت الكتابة، قبل تطبيق التعليمة البرمجية، مناسبًا بشكل مثالي لاكتشاف المشكلات ومعالجتها. عندما يتم اكتشاف المشكلة لاحقًا في دورة حياة التطوير، تصبح معالجتها أكثر صعوبة وأكثر تكلفة. وينطبق ذلك أيضًا على مشاكل الدقة، إلا أنّه ينطبق أيضًا على مشاكل الأداء، لأنّه لن تتم معالجة العديد من هذه المشاكل بمفعول رجعي بعد الالتزام بقاعدة الرموز البرمجية.
في الوقت الحالي، تكون معظم ملاحظات الأداء خارج الإطار من خلال التوثيق أو عمليات التدقيق لمرة واحدة أو ظهرت متأخرًا جدًا عن طريق انحدار المقاييس بعد النشر إلى الإنتاج. نريد أن نجلب ذلك إلى وقت الكتابة.
التوافق في الأطر
وللحفاظ على مستوى عالٍ من تجربة المستخدم في ما يتعلّق بأداء التحميل، يجب الإجابة عن الأسئلة التالية:
- ما الذي يشكِّل التحميل الأمثل، وما المشاكل الشائعة التي يمكن أن تؤثر سلبًا عليه؟
- ما هي الحلول التي يمكن ابتكارها والتي لا تحتاج إلى أي معلومات من المطوّرين؟
- كيف يمكننا التأكد من أن المطور يستخدم هذه الحلول ويستفيد منها على النحو الأمثل؟
- ما هي الخيارات الأخرى التي يمكن أن يتخذها المطوّر تؤثر في أداء التحميل؟
- ما أنماط التعليمات البرمجية التي يمكن أن تخبرنا عن هذه الخيارات (رقم 3 و4 أعلاه) في وقت مبكر من تأليف؟
- ما هي القواعد التي يمكننا صياغتها لتقييم أنماط التعليمات البرمجية هذه؟ كيف يمكن عرضها للمطوّر في وقت كتابتها مع دمجها بسلاسة في سير عمله؟
لتطبيق نموذج المطابقة الذي نستخدمه داخليًا في Google في أطر العمل المفتوحة المصدر، أجرى فريقنا تجارب كثيرة في Next.js ويسرّنا مشاركة رؤيتنا وخططنا المحسّنة. وقد أدركنا أنّ أفضل مجموعة من القواعد التي يمكنها تقييم أنماط الرموز يجب أن تكون مزيجًا من تحليل الرموز الثابتة والفحوصات الديناميكية. ويمكن أن تشمل هذه القواعد مساحات عرض متعدّدة، بما في ذلك:
- ESLint
- TypeScript
- عمليات التحقّق الديناميكية في خادم تطوير المستخدم (بعد إنشاء نموذج العناصر في المستند (DOM))
- حزمة الوحدة (حزمة الويب)
- أدوات CSS (لا تزال استكشافية)
ومن خلال الاستفادة من توفير قواعد من خلال أدوات مختلفة، يمكننا ضمان اتساقها مع استيعاب أي مشاكل تتعلق بتجربة المستخدم وتؤثر بشكل مباشر في أداء التحميل. بالإضافة إلى ذلك، يمكن أيضًا عرض هذه القواعد للمطوّرين في أوقات مختلفة:
- أثناء التطوير المحلي في خادم التطوير، سيعرض IDE للمتصفّح والمستخدم تحذيرات، مطالبًا المطوّرين بإجراء تغييرات طفيفة على الرموز.
- في وقت الإصدار، ستتم إعادة عرض المشاكل التي لم يتم حلّها في الوحدة الطرفية للمستخدم.
باختصار، ستختار الفِرق النتائج التي تهمُّهم، مثل "مؤشرات أداء الويب الأساسية" أو أداء التحميل، وستفعّل مجموعات القواعد ذات الصلة لكي يتّبعها جميع المساهمين في الرموز البرمجية.
إنّ هذا الإجراء مناسب للمشروعات الجديدة، لكن ليس من السهل ترقية قواعد الرموز الكبيرة للامتثال لمجموعات القواعد الكاملة. لدينا في Google نظام شامل للإيقاف على مستويات مختلفة مثل السطور الفردية لرمز المصدر أو الأدلة الكاملة أو قواعد الرموز القديمة أو أجزاء التطبيق التي لا تخضع للتطوير النشط. نحن نستكشف بنشاط استراتيجيات فعالة لتقديم ذلك إلى الفرق باستخدام أطر عمل مفتوحة المصدر.
المطابقة في Next.js
يُستخدم ESLint على نطاق واسع بين مطوري JavaScript، حيث يستخدم أكثر من 50% من تطبيقات Next.js ESLint في جزء من سير عمل الإنشاء. قدّم الإصدار 11 من Next.js دعمًا مبتكرًا من ESLint، فيتضمن مكوّنًا إضافيًا مخصصًا وإعدادات قابلة للمشاركة لتسهيل اكتشاف المشكلات الشائعة المتعلقة بإطار العمل أثناء التطوير وفي وقت الإصدار. وهذا يمكن أن يساعد المطورين في حل المشكلات الكبيرة في وقت الكتابة. وتشمل الأمثلة عند استخدام مكوِّن معيّن أو عدم استخدامه بطريقة قد تضر بالأداء، كما هو الحال في عدم توفُّر رابط HTML للصفحة). أو إذا كان بإمكان خط أو ورقة أنماط أو نص برمجي معين أن يؤثر سلبًا في تحميل الموارد على إحدى الصفحات. على سبيل المثال، ما مِن نص برمجي متزامن.
بالإضافة إلى ESLint، تمت إتاحة فحص النوع المتكامل في كل من التطوير والإنتاج في Next.js منذ الإصدار التاسع مع دعم TypeScript. تم إنشاء عدة مكونات يوفّرها إطار العمل (الصورة، النص البرمجي، الرابط) كإضافة لعناصر HTML (<img> و<script> و<a>) لتزويد المطوّرين بأسلوب فعّال لإضافة المحتوى إلى صفحة ويب. يدعم فحص النوع الاستخدام المناسب لهذه الميزات من خلال التأكد من أن الخصائص والخيارات المعينة تقع في النطاق المقبول للقيم والأنواع المتاحة. راجِع القسم عرض وارتفاع الصورة المطلوبَين للاطّلاع على مثال.
عرض الأخطاء مع الخبز المحمّص والتراكبات
كما ذكرنا سابقًا، يمكن أن تظهر قواعد المطابقة في جوانب متعدّدة. يتم حاليًا استكشاف الخبز المحمّص والتراكبات كوسيلة لعرض الأخطاء مباشرةً في المتصفح ضمن بيئة التطوير المحلية للمستخدم.
العديد من أدوات فحص الأخطاء والتدقيق التي يعتمد عليها المطوّرون (مثل Lighthouse وعلامة التبويب "مشاكل أدوات مطوري البرامج في Chrome") تكون سلبية وتتطلب شكلاً من أشكال تفاعل المستخدم لاسترداد المعلومات. من المرجح أن يتصرف المطوّرون عند ظهور الأخطاء مباشرةً ضمن أدواتهم الحالية، وعندما يقدّمون إجراءات ملموسة ومحددة يجب اتخاذها لإصلاح المشكلة.
التوافق في الأطر الأخرى
يتم استكشاف المطابقة في Next.js أولاً بهدف التوسّع إلى أطر عمل أخرى (Nuxt وAngular وما إلى ذلك). يجري استخدام ESLint وTypeScript في عدة أطر عمل بعدة طرق مختلفة، ولكن يجري استكشاف مفهوم نظام تشغيل متسق على مستوى المتصفح بشكل نشط.
الخلاصة
ينظم التوافق أفضل الممارسات في مجموعات قواعد قابلة للتنفيذ للمطورين كأنماط تعليمة برمجية بسيطة. ركّز فريق Aurora على أداء التحميل، إلا أنّ أفضل الممارسات الأخرى، مثل تسهيل الاستخدام والأمان، تنطبق على الموقع الإلكتروني أيضًا.
من المفترض أن يؤدي اتّباع قواعد المطابقة إلى نتائج يمكن توقّعها، ويؤدي تحقيق مستوى عالٍ لتجربة المستخدم إلى تأثير سلبي لاستخدام حزمة التكنولوجيا. يجعل التوافق الفرق منتجًا، ويضمن توفير شريط عالي الجودة للتطبيق، حتى مع زيادة الفرق وقواعد التعليمات البرمجية بمرور الوقت.