لقد بدأ تطوير البرمجيات دائمًا بمحادثة: ما هي المشكلة التي نحلها ، ولماذا يهم ، وكيف تبدو “الانتهاء”؟

على github ، تتبلور تلك المحادثة في مشكلة. بغض النظر عن الأدوات التي تستخدمها أو من تعمل معها ، لا تزال هناك مشكلة مصممة جيدًا في تعيين جدول الأعمال لطلبات السحب (PR) ، والمراجعات ، والاختبارات ، والنشر.

لم يتغير هذا المبدأ – ولكن كيف نتحصل من فكرة إلى PR يتغير بسرعة ، مع مساعدة Copilot على تسريع الأمور. من خلال طلب CoPilot إلى صياغة قضية، يمكنك تصميم خطة واضحة للمضي قدمًا بسرعة. ثم (وهنا الجزء الممتع) يمكنك قم بتعيين هذه المشكلة مباشرة إلى وكيل ترميز Github Copilot الجديد، والتي ستعمل بشكل غير متزامن على التنفيذ في المهمة في متناول اليد ويمنحك العلاقات العامة.

هذه طريقة جديدة للعمل. لكن تجربة المطور الأساسية بسيطة ومألوفة و – قلت –جيثوبي.

في هذه المدونة ، سنتحدث عن:

• لماذا تظل المشكلات العمود الفقري للعمل على جيثب – سواء كتبت بواسطتك أو صاغتها Copilot.
• أفضل الممارسات لبناء مشكلات رائعة عند العمل مع فريقك أو Copilot.
• كيف يساعدك سير عمل موجه نحو Copilot على التحرك بشكل أسرع ، وفرض الاتساق ، ويحمل عامل ترميز Copilot لإصلاحات اليدين.

لنقفز.

لماذا القضايا الرائعة وطلبات السحب أمر بالغ الأهمية

تعد مشكلات GitHub وطلبات السحب بعضًا من اللبنات الأساسية على Github. تصف كل قضية عمل منفصل ، ويقدم تفاصيل ومتطلبات مفيدة وأكثر لمن يلتقط هذا العمل. PRS حزمة العمل المكتمل لمراجعات التعليمات البرمجية ودمجها.

حتى في سير العمل المدمر من الذكاء الاصطناعى ، فإن هاتين القطع الأثريتين هما كيف تفهم الفرق الحالية والمستقبلية ما حدث ولماذا.

بغض النظر عمن (أو ماذا) مؤلفيهم ، فإن القضايا المنظمة جيدًا وطلبات السحب تقدم أربع فوائد رئيسية:

• سياق مشترك: عنوان URL واحد يلتقط بيان المشكلة ، وخطوات التكاثر ، وتعريف القيام به. يمكن لأي شخص ينضم الأسبوع المقبل – أو العام المقبل – اللحاق بالمناصب. وكما نقول في جيثب ، إذا لم يكن لديه عنوان URL ، فلن يحدث ذلك.
• التنسيق غير المتزامن: ما إذا كانت الفرق تعمل عبر المناطق الزمنية ، أو تتطلع ببساطة إلى البقاء على رأسها ، وغالبًا ما تضيف الاجتماعات التعقيد والنفقات العامة. مشكلات مجانية من الوقت من خلال السماح للمطورين بالعمل بشكل غير متزامن ، والاجتماع فقط عندما يضيف قيمة.
• التدقيق والتحليلات: الملصقات ، المعالم ، والقوالب تغذية لوحات المعلومات ، SLAs ، وتقارير الامتثال.
• السنانير الأتمتة: تصرفات سير العمل ، ولوحات المشروع ، والأدوات الوكيل تعتمد على البيانات الوصفية التي يمكن التنبؤ بها المرتبطة بكل قضية.

تفوت الهيكل وكل خطوة في اتجاه مجرى النهر – البشر أو الذكاء الاصطناعي – تنخفض. هل تحتاج إلى مثال؟ هذه قضية كنت أبحث عنها اليوم (ولا ، لن أذكر أي شخص وأعاره):

العدد رقم 12609: تم العثور على رابط مكسور. الرجاء إصلاح!

… وهذا كل شيء! مجرد عنوان بدون تفسير في الجسم ، ولا يوجد رابط فعلي ، ولا سياق ، أو أي بيئة أو معلومات الإصدار ، ولا مثال قابل للتكرار أو إصلاح مقترح.

كمطورين ، نحتاج إلى مشكلات جيدة الصنع من أجل الغوص في أي مشروع نطلب منه القيام به ، ونحن بحاجة إلى كتابة مشكلات جيدة لمساعدة زملاء الفريق على العمل بفعالية. منظمة العفو الدولية ليست استثناء: نماذج اللغة الكبيرة تؤدي بشكل أفضل عندما تكون الأهداف والقيود ومعايير النجاح واضحة. تؤدي المطالبة الغامضة إلى إنتاج غامض ، سواء تم إنشاؤه بواسطة إنسان أو آلة.

إليك الشيء: من خلال السماح لـ CoPilot بالمساعدة في إنشاء المشكلات ، يمكنك التركيز على الوضوح ، وليس نسخ لصق ، حيث يحدد Copilot المراجع ذات الصلة ، وتبني بنية المشكلة الأولية ، وحتى تضيف ملصقات أو مهام للمشروع.

تشريح قضية جيثب العظيمة

استخدم قائمة المراجعة هذه عند إنشاء – أو مراجعة – مشكلة (نعم ، يكتب Copilot هذه نيابة عنك ، لكنك ما زلت مسؤولاً):

• الإجراء – العنوان: الرصاص مع الاسم واتبع مع الفعل: “زر تسجيل الدخول – تعطيل على Safari 17 Beta” يتفوق على “بعض تسجيلات تسجيل الدخول؟”
• مشكلة أو قصة المستخدم: تأطير الألم: “بصفتي متسوقًا ، لا يمكنني النقر فوق الشراء على Safari المحمول ، لذلك أتخلى عن العربة وأبكي.”
• السلوك المتوقع مقابل السلوك الفعلي: رصاصتان سريعتان: “يجب تقديم زر أساسي” مقابل “زر لا يمكن أن يكون قابلاً للتطبيق ، لا يوجد مؤشر CSS.”
• خطوات التكاثر أو الأدلة البصرية: صور GIF أو لقطات الشاشة أو تفاصيل سطر الأوامر-كل ما يساعد زميله في الفريق (أو Copilot) على فهم المشكلة بسرعة.
• معايير القبول / تعريف القيام به: معايير التمرير/الفشل المباشر ، مثل “جميع الاختبارات تمرير” ، “Lighthouse Score> 90” ، “تم إزالة علم الميزة”.
• النطاق والقيود: الدرابزين لمنع روعة الياك: ميزانيات Perf ، قائمة المتصفح ، لا تبعيات جديدة.
• البيانات الوصفية (الملصقات ، المحدد ، معلم ، مشروع): إنها الصلصة السرية التي تعمل على تشغيل لوحات ، مرشحات ، وإخطارات الركود.

تفوت أي شيء ويتزامن ينهار. مسمار هذا التنسيق و copilot – وفريقك – يمكن أن يتحرك بسرعة.

كيفية صياغة المشكلات على github بشكل أسرع مع Copilot

تشترك المشكلات الرائعة في سمتين: إنها سريعة للكتابة والغنية بالسياق. Github Copilot’s إنشاء قضية يمنحك التدفق كلاهما. بدلاً من التنقل بين الحقول أو قصاصات الطبقات ، يمكنك فتح دردشة Copilot وصف المشكلة بلغة واضحة:

"Create a bug report about a 500 error on the login form in octo-org/octo‑web."

يقوم CoPilot بتطبيق العنوان والجسم وحتى يقترح الملصقات والمحالة – المراجعة على القالب المفضل لمستودعك ، بحيث تهبط المشكلة بالتنسيق الصحيح في كل مرة.

هذا هو الدليل خطوة بخطوة:

• افتح منظر الدردشة الغامرة في github.com/copilot.
• صف ما تحتاجه. اذكر الريبو (org/repo) أو دع CoPilot يستنتج من المكان الذي قدمت فيه آخر مشكلة.
• إسقاط لقطة شاشة إذا كانت الصورة تحكي القصة بشكل أسرع ؛ سيقوم Copilot بتضمينه في المسودة والرجوع إليه في الوصف.
• مراجعة المسودة. اطرح مطالبات متابعة (“إضافة خطوات Repro” أو “التبديل إلى قالب الأخطاء”) أو تعديل عملية التخفيض مباشرة. تحتفظ مفاتيح القالب بمحتوىك – لا توجد إعادة كتابة مطلوبة.
• انقر فوق “إنشاء” عندما تبدو جيدة.

نصائح لبناء مشكلات رائعة مع Github Copilot

ماذا تفعل	كيف يساعد Copilot	لماذا يهم
يؤدي مع السياق (المتوقع مقابل الخطوات الفعلية ، REPRO)	توفي صياغتك في أقسام القالب الصحيح.	زملاء الفريق (أو copilot) يحصلون على الوضوح.
نعلق الأدلة (شاشات ، سجلات)	لا يزال “الصورة إلى القضية” الملف في هيئة القضية.	يرى أصحاب الأخطاء في المستقبل ما رأيته بالضبط.
علامة الإجراءات التالية (“تعيين إلى Copilot” ، “Label Frontend”)	يضيف المحالفين ، الملصقات ، المعالم البارزة في واحدة.	يبقي لوحات مرتبة وسير العمل الآلي.
حشرات ذات صلة دفعة في موجه واحد	يولد مسودات متعددة يمكنك الموافقة عليها بشكل فردي.	تبديل علامة التبويب صفر عندما تكون في وضع الفرز.

كيفية تحويل مشكلة إلى مسودة العلاقات العامة مع وكيل الترميز في Github Copilot

حسنًا – الآن لديك مشكلة واضحة في متناول اليد بفضل Copilot ، يمكنك تعيينها CoPilot عبر وكيل الترميز (نعم ، يظهر مثل أي زميل في الفريق) أو اسأل:

"Assign this to Copilot."

عندما تضغط يخلق، يأخذ CoPilot الملكية ويبدأ العمل على إصلاح – Look for 👀 رد فعل على مؤشر ترابط المشكلة. وراء الكواليس ، إليك ما يحدث:

• يدور Copilot في مساحة عمل إجراءات GitHub آمنة.
• يستنسخ الريبو ، ويقوم بالبحث عن الكود الدلالي (على غرار الخرقة) ، ويؤسس خطة إصلاح.
• يرتكب لفة في مسودة العلاقات العامة يمكنك المشاهدة في الوقت الفعلي – لا توجد قوة مفاجئة.
• لا تزال حماية الفروع القياسية وبوابات CI تعمل ، لأننا cho -who – Who – – اختبارات الممرات.

هذا هو السبب في أن هذا مفيد:

• التوازي: يمكنك المراجعة بينما يكتب Copilot ، لذلك تتداخل دورات DEV بشكل جيد.
• التدقيق: كل ​​الالتزام ، والفزع ، والتعليق موجود هناك ، لذلك لا يوجد لغز سوداء من الذكاء الاصطناعي.
• الدرابزين: نفس كود ، نفس قواعد التوقيع. السرعة بدون الكورتيزول.

أسئلة شائعة ، إجابات سريعة

• “ألن يغمر CoPilot معززتي بقضايا منخفضة الجودة؟”
  • انها المسودات ، أنت صقل وضغط إنشاء. حدود المعدل نفسه ، نفس القوالب – مجرد كتابة أقل.
• “هل يمكن أن تحديث المشكلات الحالية؟”
  • ليس بعد. اليوم هو شبكة جديدة فقط ؛ تحديث مشكلة على خريطة الطريق.
• “هل يفهم القوالب المخصصة؟”
  • نعم! Copilot ينفجر من الريبو الخاص بك ، ويمكنك تبديل القوالب في منتصف السحب دون أن تفقد سياقك السريع.
• “دعم الهاتف المحمول؟”
  • سطح المكتب الآن ؛ الهاتف المحمول في الأفق (لأن الهواتف موجودة).

الآن حان دورك

في المرة القادمة التي يصرخ فيها عقلك “لاف ، سيستغرق تقديم هذا الخطأ وقتًا أطول من إصلاحه” ، فتح دردشة Copilot ودع الروبوت يتعامل مع حقول النموذج أثناء التقاط القصد. كلما زاد عدد الفكر الذي تترجم إلى إصداره إلى العلاقات العامة ، كلما حصل المستخدمون على الميزات – وكلما عدت إلى البتات الممتعة.

الآن اخرج ، قم بإصدار بحكمة ، وقد تحصل PRS الخاصة بك على GreenLit.

ترميز سعيد!

---