طلبات سحب الرمز البرمجي هي بمثابة شريان الحياة للمستودع. تحافظ هذه الأدوات على سلامة المحتوى واستمراريته. توضّح هذه الصفحة بالتفصيل كيفية إنشاء طلب إصلاح كامل وسهل المراجعة، ما يزيد من احتمالية دمج طلب الإصلاح.
في ما يلي الخطوات التي يمكنك اتّخاذها لضمان إنشاء أفضل حملة علاقات عامة ممكنة.
التواصل
قبل البدء في كتابة الرموز البرمجية، من المفيد التواصل مع الفريق الأساسي حتى يعرف ما يهمّك.
إذا كانت هناك مشكلة تهمّك، أضِف تعليقًا على المشكلة تشير فيه إلى أنّك ستبدأ العمل عليها. ويضمن ذلك عدم توفّر عدة أشخاص يعملون على الأمر نفسه. سيردّ أحد أعضاء الفريق لتأكيد أنّه الحساب الخاص بك.
إذا كانت لديك فكرة لا تتناولها أي مشكلة، يُرجى كتابة مشكلة قبل بدء العمل. يمنح ذلك الفريق فرصة لمناقشة أفضل طريقة لتنفيذ التغيير قبل بدء التنفيذ، ما يوفر عليك العمل على المدى الطويل.
الاستعداد
إذا كانت هذه هي المرة الأولى التي تساهم فيها في Blockly أو blockly-samples، ابدأ من صفحة إعداد التطوير.
يجب أن تكون الرسائل قصيرة.
حاوِل دائمًا إبقاء التغييرات صغيرة ومركزة. نفضّل مراجعة طلبات متعددة لتغييرات بسيطة بدلاً من مراجعة طلب واحد كبير. في ما يلي بعض القواعد الجيدة التي يمكنك اتّباعها:
- حلّ مشكلة واحدة: لا تحاول معالجة مشاكل متعددة في آنٍ واحد.
- الحد من النطاق: من المفترض أن تستغرق عادةً عملية إرسال طلب إعادة نظر أقل من 8 ساعات (حسب معرفة بقاعدة الرمز البرمجي).
- استخدام عمليات الإضافة والحذف إذا كان طلب إعادة النظر كبيرًا بعض الشيء، يمكنك تقسيم التغييرات إلى مجموعات منطقية باستخدام عمليات تسجيل git.
الحفاظ على محتوى صافٍ
ما أهمية أسلوب الترميز؟ نحن نسعى إلى تحقيق النجاح على المدى الطويل، ويسهّل الحفاظ على الأسلوب المتّسق. يشير الأسلوب إلى كيفية تسمية المتغيّرات، ولكنه يغطي أيضًا كيفية تنظيم الرمز البرمجي وكتابة التعليقات وغير ذلك. نستخدم كلما أمكن أدوات مثل eslint لأتمتة عمليات التحقّق من الأنماط.
بالإضافة إلى eslint، يُرجى اتّباع الأدلة التالية:
- دليل أسلوب JavaScript في Google
- دليل رسائل التعليقات
- مستوى الوصول إلى واجهة برمجة التطبيقات
- دليل أسلوب Codelab
اختبار التغيير
قبل نشر طلب إعادة النظر، يجب دائمًا اختبار التغييرات للتأكّد من أنّها تعمل بشكل صحيح، وبالتالي عدم الحاجة إلى الرجوع وإصلاح المشاكل لاحقًا. في ما يلي بعض الأفكار لاختبار الفئات المختلفة من المشاريع:
- بالنسبة إلى الإضافات: اكتب اختبارات mocha مبرمَجة تغطي التغييرات التي أجريتها.
- أمثلة: اختبار جميع الوظائف التي تم توضيحها يدويًا
- بالنسبة إلى codelabs: اطّلِع على البرنامج التعليمي بالكامل في بيئة نظيفة و اختبِر أي رمز برمجي نموذجي تقدّمه.
التواصل
هذا هو الجزء الأخير والأهم على الأرجح من إنشاء طلب الدعم: كتابة الملخّص.
تساعد كتابة ملخّص رائع للعلاقات العامة المطوّرين الآخرين في مراجعة التغييرات التي أجريتها، ما يزيد من احتمالية قبولها بشكل أسرع.
يجب أن يتضمّن الملخّص عناصر مثل:
- المشكلة التي تتعلّق بها طلبك
- التغيير الذي يُحدثه فريق العلاقات العامة
- كيفية اختبار التغيير
- أيّ شيء تريد من المراجعين التدقيق فيه
- أي معلومات أخرى تعتقد أنّها مفيدة للمراجعين
إذا اتّبعت نموذج طلب التغيير عند إنشاء طلبك، من المفترض أن يكون الطلب جاهزًا للاستخدام. ما عليك سوى الحرص على أن يكون موجزًا وشاملاً قدر الإمكان.
مع أطيب التحيّات،