يمكنك اختيار أدوات الإصدار وضبطها بالاستناد إلى أفضل الممارسات.
يطرح موقع web.dev اليوم مبادرة جديدة باسم tooling.report. إنه موقع ويب يمنح مطوري الويب نظرة عامة على الميزات المدعومة عبر مجموعة من أدوات الإنشاء الشائعة. لقد أنشأنا هذا الموقع الإلكتروني لمساعدتك في اختيار أداة الإنشاء المناسبة لمشروعك القادم، أو تحديد ما إذا كان الانتقال من أداة إلى أخرى يستحق العناء، أو التعرّف على كيفية دمج أفضل الممارسات في إعدادات الأدوات وقاعدة الرموز البرمجية. الأدوات لها مجالات تركيز مختلفة وتلبي مجموعة مختلفة من الاحتياجات، مما يعني اختيار وتكوين الأدوات التي تتضمن إجراء مقايضات. من خلال Tooling.report، نهدف إلى شرح هذه المفاضلات وتوثيق كيفية اتّباع أفضل الممارسات باستخدام أي أداة إنشاء معيّنة.
هل يبدو هذا مثيرًا؟ انتقل إلى Toolsing.report لبدء الاستكشاف، أو تابع القراءة لمعرفة المزيد حول سبب وكيفية تطوير هذا الموقع.
غالبًا ما تقف أدوات الإنشاء في طريقنا
وفي GoogleChromeLabs، صمّمنا تطبيقات ويب مثل Squoosh وProxx، بالإضافة إلى مواقع إلكترونية مثل مؤتمر Chrome Dev Summit لعام 2019. كما هو الحال مع أي مشروع لتطوير الويب، نبدأ بشكل عام بمناقشة البنية الأساسية للمشروع مثل بيئة الاستضافة وأطر العمل وإعداد أداة الإنشاء. يتم تحديث تلك البنية الأساسية مع تقدم المشروع: تتم إضافة مكونات إضافية جديدة لتلائم أطر العمل أو التقنيات التي نستخدمها، أو يتم تغيير الطريقة التي نكتب بها التعليمات البرمجية حتى تتمكن أدوات الإنشاء من فهم ما نحاول تحقيقه بشكل أفضل. خلال هذه العملية، وجدنا غالبًا أن الأدوات التي نختارها تعيق طريقنا.
يركّز فريقنا على توفير أفضل تجربة استخدام على الإنترنت للمستخدمين، ما يؤدي غالبًا إلى تحسين طريقة تجميع أصول الواجهة الأمامية وتقديمها. على سبيل المثال، إذا كان النص البرمجي لسلسلة التعليمات الرئيسية والنص البرمجي لعامل الويب يتضمّنان تبعيات مشترَكة، نرغب في تنزيل التبعيات مرة واحدة بدلاً من تجميعها مرتين لكل نص برمجي. تدعم بعض الأدوات هذا الأمر بطريقة غير تقليدية، فيما تحتاج بعضها إلى مجهود كبير في التخصيص لتغيير السلوكيات التلقائية، والبعض الآخر مستحيل تمامًا.
قادتنا هذه التجربة إلى دراسة ما يمكن وما لا يمكن أن تفعله أدوات الإنشاء المختلفة. كنا نأمل في إنشاء قائمة تحقق للميزات حتى نتمكن في المرة القادمة التي نبدأ فيها مشروع جديد من تقييم واختيار الأداة الأنسب لمشروعنا.
الأسلوب الذي نتّبعه
كيف يمكننا تقييم أدوات الإنشاء المختلفة ومقارنتها في مكان واحد؟ لقد تعاملنا معه من خلال كتابة حالات الاختبار.
ناقش فريقنا وصمّم معايير الاختبار التي نعتقد أنّها تمثّل أفضل الممارسات لتطوير الويب. ركّزنا بشكل خاص على كيفية تقديم تجارب سريعة وسريعة الاستجابة وسلس للمستخدمين، مع استثناء عمدًا الاختبارات المرتبطة بتجربة المطوّرين لتجنّب قياس نتيجتين غير قابلتين للمقارنة.
بمجرد إنشاء قائمة الاختبار، تقدمنا وكتبنا نصًا لإنشاء كل أداة للتحقق مما إذا كانت الأداة يمكنها أن تفي بمعايير نجاح الاختبار. كمجموعة أولية، قررنا استكشاف الإصدار 4 من حزمة الويب والإصدار 2 من حزمة البيانات والإصدار الثاني من حزمة البيانات. واختبرنا أيضًا Browserify + Gulp لأن عددًا كبيرًا من المشاريع لا يزال يستخدم هذا الإعداد. لاجتياز الاختبار، لا يمكن استخدام سوى ميزات الأداة الموثَّقة علنًا أو مكوّنًا إضافيًا للأداة. بعد كتابة المجموعة الأولية من الاختبارات، عملنا مع مؤلفي أداة الإنشاء للتأكد من أننا استخدمنا أدواتهم بشكل صحيح وتمثيلهم بشكل عادل.
نحن نستخدم ${tool_name} فقط، فهل ما زال عليّ تقديم المساعدة في هذا الشأن؟
في العديد من الفرق، يوجد أشخاص مخصصون للحفاظ على البنية التحتية للبناء، وقد لا يضطر أعضاء الفريق الآخرون مطلقًا إلى اتخاذ أي خيار عندما يتعلق الأمر بإنشاء الأدوات. نأمل أن يكون هذا الموقع الإلكتروني لا يزال مفيدًا لك أيضًا، كطريقة لتحديد التوقعات للأدوات التي تعتمد عليها. بالنسبة لكل اختبار، قمنا بتضمين شرح لسبب أهمية الاختبار إلى جانب موارد إضافية. وإذا كنت تريد تطبيق أفضل الممارسات باستخدام الأداة التي تختارها، يتضمّن إعداد الاختبار في مستودعنا ملفات الضبط اللازمة لإجراء ذلك.
هل يمكنني المساهمة في الموقع؟
إذا كنت تعتقد أنه يجب اختبار ميزة معينة غير موجودة حاليًا، يُرجى اقتراحها في مشكلة GitHub لبدء المناقشة. ونحن نهدف إلى تلخيص حالات الاستخدام في العالم الفعلي، ونرحب بأي اختبارات إضافية تقيِّم هذه النتائج بشكلٍ أفضل.
وإذا أردت كتابة اختبارات لأدوات لم يتم تضمينها في المجموعة الأولية، نرحب بذلك أيضًا. يُرجى مراجعة CONTRIBUTING.md للاطّلاع على مزيد من المعلومات.