يمكن لأدوات البرمجة المعتمدة على الذكاء الاصطناعي توليد الأكواد بسرعة، ولكن السرعة وحدها لا تحل أصعب مشكلات هندسة البرمجيات. لا يزال على المطورين تقديم السياق والتحقق من النتائج وحماية قابلية الصيانة والبقاء مسؤولين عمّا يتم إطلاقه.
لتعلّم كيف يحقق المطورون ذوو الخبرة هذا التوازن، تحدثنا مع ثلاثة من أبطال Java، وكلهم يتمتعون بخبرة تزيد عن عشر سنوات في استخدام Java. شاركوا أمثلة ملموسة على استخدام GitHub Copilot في الإنتاج والمصادر المفتوحة، بالإضافة إلى الممارسات التي يتبعونها لتحويل المخرجات المولّدة بالذكاء الاصطناعي إلى برمجيات موثوقة.
فيما يلي النصائح التي شاركوها معنا.
Vlad Mihalcea
الملف الشخصي على GitHub: @vladmihalcea
كيف ساعدك GitHub Copilot مؤخرًا؟
كنت أستخدمه لتحليل وتصميم وتنفيذ ميزات متنوعة في كل من Hypersistence Utils و Hypersistence Optimizer.
على سبيل المثال، كنت أرغب منذ وقت طويل في تطوير تطبيق ويب يوفر سجل أحداث Optimizer حتى نتمكن من رؤية كيف تتجسد جهود تحسين الأداء في أداء التطبيق. قبل الذكاء الاصطناعي، كنت أؤجل هذه المهمة باستمرار لأن تطويرها كان سيستغرق مني أسابيع. ولكن استخدام Copilot يشبه وجود عضو جديد في الفريق، لذا استخدمته لإنشاء تطبيق سيتم طرحه في الإصدار القادم من Hypersistence Optimizer. وبدلاً من أسابيع، استغرقت هذه المهمة يومين فقط لتنفيذها.
ما هو استخدامك المعتاد؟ هل تستخدم GitHub Copilot كإضافة لبيئة التطوير المتكاملة أم تطبيق GitHub Copilot؟
أستخدم GitHub Copilot في IntelliJ IDEA لأنه من الملائم تشغيله أثناء مراجعة الكود المصدري أو أثناء جلسة تصحيح الأخطاء.
إنه مفيد جدًا كمساعد برمجي، ويساعدني على تسريع كل من عمليات الاستقصاء وبناء النماذج الأولية للميزات التي تحتاج إلى تحقق.
لا أزال أراجع الخطط والأكواد التي يولّدها الذكاء الاصطناعي لأن هدفها هو تحسين إنتاجيتي، وليس استبدالي بالكامل. وعلى الرغم من أن الذكاء الاصطناعي يقدم الإجابة الصحيحة في كثير من المواقف، إلا أن هناك أوقاتًا لا تكون فيها الاستجابة مرضية وتتطلب تدخلي.
هل يمكنك مشاركة بعض النصائح وأفضل الممارسات؟ على سبيل المثال، ما المهارات التي تستخدمها؟
أنشأت مهاراتي الخاصة بحيث يبدو أي نص يولّده Copilot وكأنه شيء كتبته بنفسي.
تلتقط هذه المهارة أسلوبي من 65 من مقالاتي المنشورة، بحيث تعود المسودة الأولية بصوت مدونتي بدلاً من أن تبدو وكأنها من نموذج لغوي. وهذا مفيد جدًا عند توليد الوثائق لهذا المشروع، لأنه يتيح للنموذج اللغوي الكبير التعلم من 12 عامًا من التدوين وتقديم أمثلة تتبع نفس المبادئ، مثل التعبيرية وقابلية الاختبار والبساطة.
على مدار مسيرتي كمهندس برمجيات، تعلمت أننا نقضي وقتًا أطول بكثير في صيانة الأكواد مما نقضيه في إنشائها. لذلك، ولأن الصيانة والاستقرار أمران حاسمان للمنتجات القائمة، طورت مهارات تساعد الذكاء الاصطناعي على محاكاة ممارسات الأكواد القائمة تماشياً مع مبدأ أقل قدر من المفاجآت.
من النصائح أن تغيّر نوع النموذج بناءً على نوع العملية. للتفكير المتعمق، أستخدم Opus بنافذة سياق تبلغ 1 مليون مع مستوى استدلال Extra High أو Max. أما بالنسبة للمهام الأبسط، مثل توليد التقارير أو ملاحظات الإصدار أو التحقق من الوثائق، فأستخدم نماذج أخف تستهلك رموزًا (tokens) أقل.
Patrick Baumgartner
الملف الشخصي على GitHub: @patbaumgartner
يتضمن عملك تدريب الفرق. ما هو نهجك؟
يحدث الكثير من عملي بينما لا يزال العمل الطبيعي يتعين عليه الاستمرار. لا يمكنك إيقاف كل شيء لمدة ستة أشهر من أجل "التحول". نبدأ عادةً بحل المشكلات الفورية معًا، وفهم موقع الفريق الحالي، وتحديد وجهة التي نريد الوصول إليها وكيف سنعرف أننا نتحسن، ثم نتحرك نحوها خطوة بخطوة.
اعتمادًا على الموقف، قد يعني ذلك ممارسات Software Craft مثل TDD وإعادة الهيكلة والتسليم المستمر وXP؛ أو الهندسة المعمارية والتقسيم إلى وحدات باستخدام Spring Boot و Spring Modulith؛ أو Spring Security؛ أو تحسين تطبيقات Java و Spring Boot للحاويات؛ أو على نحو متزايد، الهندسة الوكيلة (agentic engineering).
الجزء المهم بالنسبة لي هو أنني أعمل مع الفريق. نتخذ القرارات معًا. لا أريد أن يصبح الفريق معتمدًا عليّ. وبشكل مثالي، بعد فترة من الوقت لن يحتاجون إليّ بعد الآن، إلا ربما كشريك تدريب.
وربما يفسر ذلك سبب اهتمامي بهذا الجيل الجديد من أدوات الذكاء الاصطناعي: أحب العمل مع الناس، والتعلم، والتجريب، وحل المشكلات. الذكاء الاصطناعي يمنحنا أداة أخرى قوية جدًا للقيام بذلك بالضبط.
هل يمكنك مشاركة قصة جيدة حول كيف ساعدك GitHub Copilot مؤخرًا؟
هناك في الواقع ثلاثة أمثلة مختلفة جدًا غيّرت طريقة تفكيري في العمل مع GitHub Copilot.
لنبدأ بالمثال الأول.
كان أحدها ترحيل نحو 900 شريحة تعليمية موزعة على 15 عرضاً تقديمياً من Reveal.js إلى Marp. لم تكن شرائح بسيطة. فكثير منها يحتوي على شيفرة برمجية وحركات تفاعلية بل وأمثلة تفاعلية يمكنني فيها تغيير JavaScript مباشرة أثناء التدريس. والأهم من ذلك أن العروض التقديمية كانت قد اختُبرت فعلياً مع الطلاب سابقاً. كان التسلسل يعمل بنجاح. وفقدان أي قطعة صغيرة قد يفسد القصة التي أستخدمها في الصف.
لو قمت بذلك الترحيل يدوياً لاستغرق الأمر على الأرجح أسبوعاً أو أكثر — وواقعياً، ربما كنت سأتجنّبه ببساطة لأنه عمل ممل للغاية.
مع Copilot تعاملت مع الأمر بشكل مختلف. حللنا أولاً المحتوى الحالي، وحددنا الهدف، وأعددنا خطة ترحيل، ووضعنا قيوداً، وقدمنا أمثلة، وحددنا ما يجب أن يبقى دون تغيير. ثم عملنا من التغييرات الهيكلية الكبرى نزولاً إلى التفاصيل.
كان الجزء المهم فعلاً هو التحقق.
أنشأنا لقطات شاشة لإصداري Reveal.js وMarp وقارنّاها بصرياً وخوارزمياً. بنينا تطبيقاً صغيراً يمكنني من خلاله تشغيل مجموعتي الشرائح جنباً إلى جنب للتحقق من الحركات يدوياً. بل قارنّا حتى ملفات PDF الناتجة.
كان ذلك يعني أن الوكيل لم يكتفي بالقول: «اكتمل الترحيل». كان لدينا دليل.
استغرق الترحيل بأكمله مني نحو ثماني إلى عشر ساعات. ظللت أملك المحتوى، والهدف التعليمي، وكل تغيير ذي معنى. كان بإمكان Copilot تصحيح خطأ إملائي تلقائياً، لكن إذا تغير المحتوى أو الإصدارات أو التواريخ أو المعنى، فكان ذلك شيئاً نناقشه.
بالنسبة لي، عززت تلك التجربة مبدأً مهماً: فوّض التنفيذ، لا المسؤولية. أنا من يملك النتيجة.
هل يمكنك مشاركة المثال الثاني؟
جاء المثال الثاني من بناء تطبيق واجهة طرفية (terminal UI) باستخدام Tamboui. عمل في البداية بشكل مثالي على Linux ضمن WSL، وكنت قد نسيت تماماً أن أحدهم قد يشغّله مباشرة في Windows CMD أو PowerShell.
ثم فعل مستخدم حقيقي ذلك.
اكتشف أن مفتاح Enter كان يتم تجاهله ببساطة في بعض النماذج. وهذا مبدأ آخر أؤمن به بقوة: أطلق البرنامج مبكراً، لأنك تتعلم من الطريقة التي يستخدمه بها الناس فعلاً.
استخدمنا Copilot لتحويل تلك الملاحظات إلى اختبارات واجهة قابلة للتكرار. على Linux، كان Copilot يتنقل في التطبيق باستخدام tmux. ومن خلال العمل معه، تعرفت على psmux وتمكنت من تنفيذ مسارات مماثلة في PowerShell. أعدنا إنتاج المشكلة، وأنشأنا إصلاحاً محلياً، وتتبعنا المشكلة الحقيقية إلى Tamboui، وقدّمت الإصلاح إلى المشروع الأصلي وتم دمجه.
أثناء هذا العمل، أصبحت أوصاف الاختبارات نفسها أكبر من أن تتسع في السياق المتاح. لذا طلبت من Copilot مساعدتي في إعادة تصميم طريقة تمثيل الاختبارات. وبدلاً من الجداول المطوّلة التي تحتوي على معرّفات وأسماء وأوصاف متكررة، اقترح ترميزاً سهمياً أكثر إيجازاً بكثير: خطوة → خطوة → إدخال، مع معلومات إضافية فقط حيث يكون ذلك حاسماً.
أدهشني ذلك. لم نكن فقط نستخدم الذكاء الاصطناعي لتنفيذ المعلومات؛ بل كنا نعمل معاً على كيفية تمثيل المعلومات لأغراض التنفيذ. لم يكن لزاماً أن تكون سهلة الاستخدام للإنسان إلى أقصى حد. كان عليها أن تحافظ على الدلالات مع أن تكون فعالة للوكيل.
وماذا عن المثال الثالث؟
المثال الثالث مختلف تماماً مرة أخرى.
أحدهم قريب مني كان بحاجة إلى التدرب على الرياضيات، ففكرت: لماذا لا نبني تطبيقاً تعليمياً صغيراً؟
يغطي التطبيق الجمع والطرح والضرب والقسمة والقسمة مع الباقي للصفوف من الأول إلى الرابع. لكنني لم أرغب في بناء تطبيق اختبارات بسيط آخر. مع Copilot، بحثنا في مناهج تعلم مثل التكرار المتباعد، والتغذية الراجعة الفورية، والصعوبة التكيفية، والتحفيز، والتعلم التعاوني، وأسلوب الألعاب (gamification) دون أنماط مظلمة.
واللافت أن Copilot تحدى خلال ذلك البحث أحد افتراضاتي الأصلية. كنت أرغب في البداية في أن يكون التطبيق عاماً للأطفال في كل مكان. وأدى البحث بنا إلى النظر في منهج المدارس الفعلي بدلاً من ذلك. أدركت أن الترتيب الذي تُقدَّم فيه الموضوعات، والعمليات ونطاقات الأرقام تختلف اختلافاً كافياً بحيث لم يكن جعله «شاملاً» فوراً ضرورياً.
لذا ركزنا على سويسرا أولاً وموّفنا التقدم وفق ذلك. ولأن سويسرا متعددة اللغات، فالتطبيق متاح بالألمانية والفرنسية والإيطالية والإنجليزية.
يحتوي التطبيق أيضاً على وضعين تعاوني وتنافسي للاعبَين، وعندما يجيب أحدهم إجابة خاطئة، يشرح التطبيق طريقة واحدة لحلها ويعيد طرح أسئلة مشابهة عبر التكرار المتباعد.
اخترت عمداً بنية لا تتضمن خادماً خلفياً (backend). فلا داعي لي لجمع البيانات الشخصية للأطفال على خادم، لذا تبقى البيانات على الجهاز ويمكن استضافة التطبيق ببساطة على GitHub Pages.
ما بدأ كتجربة صغيرة أصبح الآن مستخدماً ومشتركاً بين الأصدقاء. أصبح عرضاً لخطأ منتجاً صغيراً.
أراني ذلك التجربة جانباً آخر من Copilot: لا تستخدمه فقط لتنفيذ حلّك. استخدمه كشريك تدريب (sparring partner) من أجل توسيع مساحة الحلول وتحديها قبل أن تبدأ البناء.
كيف تستخدم Copilot عادةً؟
في الواقع، لم أعد أستخدم تجربة الإكمال التلقائي الكلاسيكية في Copilot.
لقد تحول عملي تقريبًا بالكامل نحو سير عمل الوكلاء الذكية.
أستخدم VS Code عندما أحتاج إلى حلقة تغذية راجعة بصرية محكمة—حين أرغب في النظر عن قرب في المستندات أو الكود أو العروض التقديمية أو النتائج الوسيطة وتكييف العملية أثناء العمل.
أما بالنسبة للمهام الأكبر الموجهة نحو التنفيذ، فغالبًا ما أعمل مع وكيل البرمجة من الطرفية (terminal). هناك أشعر براحة أكبر في تفويض جزء من العمل، وتركه ينفَّذ، ثم فحص النتيجة الكاملة. الواجهة التي أختارها تعتمد في الغالب على حلقة التغذية الراجعة التي أحتاجها.
لقد مررت أيضًا بتجربة رائعة في استخدام سير عمل وكيل البرمجة عبر GitHub أثناء سفري إلى JavaLand. كنت قد بدأت باستكشاف فكرة عن إضافة Maven (Maven plugin) تعمل على تحسين أي إعدادات تلقائية من Spring Boot يتم تحميلها. خلال رحلة استغرقت نحو أربع ساعات تقريبًا، كنت أقود الوكيل من هاتفي: أعطيه مهمة، ثم أراجع ما أنجزه، ثم أفكر في الخطوة التالية، ثم أرسل التعليمة التالية.
بحلول وصولي، كان لدي إضافة Maven عاملة، وخط أنابيب CI، واختبارات أداء مقابل تطبيق نموذجي، وتقارير يمكنها إثبات ما إذا كان التحسين يعمل فعلًا.
كانت هذه أول مرة أعمل بهذه الطريقة، وقد أذهلتني الحقيقة أن الأمر نجح فعلًا. لم أكن أحاول كتابة Java على هاتفي؛ كنت أراجع وأقرّر وأوجّه بينما كان الوكيل ينفّذ.
أستخدم أيضًا خوادم MCP عندما تمنحني قدرات أو سياقًا مفيدًا. على سبيل المثال، استخدمت Context7 للتوثيق، وتكاملات مع قاعدة معرفتي في Logseq، وقد جرّبت تكامل MCP مع Adobe Premiere Pro.
لكنني لا أستخدم MCP لمجرد أنني أستطيع. إذا وُجدت واجهة سطر أوامر (CLI) جيدة، فأنا غالبًا أفضّل CLI لأنها تبدو لي أكثر مباشرة وسرعة.
الوكيل أيضًا ليس "مطوّرًا مبتدئًا" في تصوري الذهني. أراه أقرب بكثير إلى شريك تدريب (sparring partner). لكن تمامًا مثل أي شخص ينضم إلى مشروع، يحتاج أولًا إلى التعرف على السياق والتأقلم معه.
السياق هو الملك.
هل يمكنك مشاركة بعض النصائح وأفضل الممارسات؟
أهم ما أوصي به هو: التوقف عن تقديم التعليمات بضربة واحدة (one-shot prompting).
بالنسبة لأي أمر غير بسيط، أريد أن أفهم المشكلة قبل بدء التنفيذ. في كثير من الأحيان أطلب من الوكيل صراحةً أن يُجري مقابلة معي أولًا. والغرض من تلك المقابلة هو الكشف عن الافتراضات والتوقعات التي ما زالت ضمنية.
الوكيل الجيد يمكنه تنفيذ الفكرة الخاطئة بسرعة مذهلة. وهذا لا يجعل الطريق الملتف أرخص.
عشت هذا بنفسي أثناء عملي على مُحسِّن الإعدادات التلقائية في Spring Boot. في البداية أردت دعم كل من Spring Boot 3.5 و4.x. كانت هناك اختلافات معمارية، لذا نفّذنا النهجين معًا. ولاحقًا أدركت أنني لم أعد بحاجة إلى مسار 3.5، وكانت إزالته مؤلمة.
كان الدرس بسيطًا: الالتفافات مكلفة. اضبط المتطلبات بشكل صحيح قبل أن تُسرّع.
بمجرد أن يصبح القصد واضحًا، أريد خطة. وعندما أراجع تلك الخطة، هناك أربعة أمور تهمّني بشكل خاص: هل الافتراضات مرئية، وهل بوابات التحقق محددة، وهل النهج يتناسب مع المعمارية، وهل يتجنب العمل غير الضروري؟
المبدأ الثاني هو تحديد بوابات تحقق خاصة بالمهمة.
لا ينبغي أن يعني "الانتهاء" أن النموذج يقول إنه انتهى.
في عملية إعادة هيكلة، قد تشمل البوابات نجاح الاختبارات، وإثبات معالجة جميع الملفات المقصودة، وتحديث التوثيق، وعدم ترك أي TODOs خلفها. وفي ترحيل الشرائح، شملت البوابات لقطات الشاشة، والفروقات البصرية، والحركات (animations)، ومخرجات PDF، واكتمال المحتوى.
البوابات تعتمد على المهمة. أما المبدأ فلا: يجب أن يكون الوكيل قادرًا على تقديم دليل على أن العمل يلبي تعريف الانتهاء.
عثرت مؤخرًا على مهارة تُدعى unlazy تتبع فكرة مشابهة: أنشئ بوابات صريحة، واعمل عليها بعناية، وأثبت أنها اكتملت بدلًا من اتخاذ اختصارات.
المبدأ الثالث هو تحويل دروسك إلى مهارات قابلة لإعادة الاستخدام.
بدأت أكتب وأصون مهارات الوكلاء الخاصة بي. عندما أتعلم شيئًا من تنفيذ ما—ربما أساء الوكيل فهم اصطلاح ما، أو كان فحص مفيد مفقودًا، أو وجدت طريقة أفضل للتعامل مع مهمة—أقوم بتحديث المهارة.
في المرة القادمة التي أؤدّي فيها تلك المهمة، يكون الدرس موجودًا بالفعل.
مثال واحد هو مهارة أسميها maintainer-audit، مستوحاة من عمل مجتمع مهارات الوكلاء المفتوحة. أستخدمها عبر مستودعاتي الخاصة. فهي تفحص، وحيثما كان ذلك مناسبًا، تُصلح الأمور التي أتوقع أن يملكها مشروع مُعتنى به جيدًا: توثيق المستودع، وخطوط أنابيب CI، وإعداد Dependabot، وCodeQL، والتنظيف المتسق ومعايير المشروع الأخرى.
الهدف ليس توليد تقرير تدقيق آخر أقرؤه. بل تعيد المستودع تلقائيًا نحو خط الأساس الذي أريده. هذا يجعل مشاريعي أكثر اتساقًا وأسهل في الصيانة.
أرى هذه المهارات معرفة هندسية حيّة بدلاً من مطالبات ثابتة.
المبدأ الرابع هو وضع أدوات هندسية حتمية حول النموذج الاحتمالي.
لديّ منظومة جودة خاصة بي تُغلّف أدوات مثل فحوصات Checkstyle وPMD وفحوصات بنية Spring Modulith وتنتج تقريراً موحّداً يمكن للوكيل استهلاكه. يمكنني تشغيلها من خلال الـ hooks والسماح للوكيل بالتكرار:
تغيير → تنفيذ الفحوصات → قراءة النتائج → الإصلاح → التنفيذ مرة أخرى.
ويستمر هذا حتى لا تبقى أي نتائج.
لا يعني ذلك أنني أتوقف عن فحص البرنامج. ما زلت أشغّل التطبيق، وأتفاعل معه، وأقرر ما إذا كان يتصرف ويبدو بالطريقة التي أتوقعها. أحياناً أنفذ الميزة تلو الأخرى عمداً لأن حلقة التغذية الراجعة تكون أضيق بكثير.
تعلمت أن طلب كل شيء دفعة واحدة بحجة أن "الذكاء الاصطناعي يستطيع ذلك" فكرة سيئة في العادة. المواصفات الكبيرة العامة تؤدي إلى تنفيذات كبيرة عامة—وقد يكون تنظيفها لاحقاً أصعب من بناء زيادات أصغر بشكل صحيح.
وبمفهوم أوسع، أعتقد أننا كمطورين نحتاج إلى التحدث كثيراً أكثر عن كيفية استخدامنا لهذه الأدوات. شاركوا التجارب التي نجحت. شاركوا تلك التي لم تنجح. اقترضوا الأفكار من بعضكم وبأوفوا بها على سياقكم الخاص بدلاً من البحث عن عملية تطوير بالذكاء الاصطناعي واحدة عالمية.
لهذا السبب أيضاً أحب فكرة الذكاء الاصطناعي كشريك تدريب. في ليلة جمعة، عندما أريد تجربة شيء ما ولا يتوفر شريك بشري، أجد فجأة شخصاً—أو شيئاً—يمكنني تحدي فكرة معه، أو مراجعة منهج معه، أو استخدامه كبطة مطاطية متطورة جداً.
لكنني ما زلت أعيد تلك الأفكار إلى أشخاص حقيقيين. التغذية الراجعة البشرية، وفهم المنتج، والسياق الواقعي تبقى أساسية.
كيف ترى أن الذكاء الاصطناعي يغيّر مهنتنا؟
لا أعتقد أن طلاب هندسة البرمجيات ينبغي أن يطمحوا بالدرجة الأولى ليصبحوا آلات منتجة للأكواد. إنهم بحاجة إلى أن يصبحوا حلّالين أقوياء للمشكلات. يحتاجون إلى فهم المستخدمين وأصحاب المصلحة، واكتشاف المشكلة الحقيقية وراء المتطلب، وتحدّي الافتراضات، وفهم المنتجات والأسواق، واتخاذ مقايضات معمارية، والتفكير النقدي، والعمل بطريقة منظمة، ونقل الحلول المفيدة من سياق إلى آخر.
النموذج بارع بشكل استثنائي في توليد الاحتمالات وتنفيذ الأمور. لكن كبشر، أعرف عادةً الكثير من السياق الفعلي—بما في ذلك الأشياء التي لم يوثّقها أحد أبداً.
لذا أريد أن أبقى مسؤولاً عن تشكيل الحل وأترك للوكيل تولي المزيد من التنفيذ.
بهذا المعنى، أعتقد أن الذكاء الاصطناعي يعيد الهندسة إلى هندسة البرمجيات.
وهذا ما يعجبني.
Frank Delporte
ملف GitHub الشخصي: @FDelporte
كيف بدأت مسيرتك في التقنية؟
كنت مفتوناً بالحواسيب منذ حصلت على جهاز Commodore 64 عندما كان عمري 11 عاماً. خُضت بعض الانحرافات إلى إنتاج الفيديو والعمل التلفزيوني بعد المدرسة، لكنني عدت إلى البرمجة لأن ذلك الفيديو احتاج إلى وضعها على قرص DVD وبسبب أولى المواقع الإلكترونية… نعم، أنا بهذا القدم ;-).
كيف ساعدك GitHub Copilot مؤخراً؟
إنه رفيق مثالي لتقييم طلبات السحب والتحقيق في تقارير الأخطاء.
إحدى القصص اللافتة تتعلق بمكتبة Pi4J التي تتيح لك بناء تطبيقات Java للتفاعل مع المكونات الإلكترونية على Raspberry Pi. في فبراير 2026، أطلقنا الإصدار V4 الذي يتضمن إضافة جديدة تستخدم واجهة Foreign Function & Memory API. اختبرناها بعناية قبل الإطلاق، ولكن مع ذلك، بعد وقت قصير من الإطلاق أبلغ أحدهم أن استخدام 5 أزرار إدخال لا يعمل كما هو متوقع. الضغط على أحد الأزرار الأربعة الأولى المُهيأة يُفعّل تنفيذ كود كما هو متوقع، بينما لا يحدث شيء مع الزر الخامس.
هذا هو نوع التقارير التي لا تريد تلقيها. لا شيء كان معطوباً بشكل ظاهر. لا استثناء، ولا تحذير في السجلات، كان الزر الخامس صامتاً ببساطة. وسوء الأمر ازداد: مع إضافة gpiod الأقدم، وبنفس العتاد بالضبط ونفس التطبيق بالضبط، كان كل شيء يعمل جيداً. إذن كانت المشكلة في كود FFM الجديد لدينا، الذي يقع فوق جهاز حروف GPIO في نواة Linux ويتخاطب معه عبر استدعاءات أصلية. وليست تلك الجزء من قاعدة الكود الذي تتوقع أن تجد فيه إجابة سريعة.
لذا أسندت المشكلة إلى وكيل البرمجة Copilot و给了ه مسارَي ملفين كنقطة بداية، الفئة المزودة للخدمة وFFMDigitalInput. بعد حوالي نصف ساعة كان هناك طلب سحب، مع تفسير لم أتوقعه حقاً.
كل مدخل يشغّل مراقب أحداث يتعطل داخل استدعاء poll() أصلي بانتظار أن تُبلغ النواة عن تغيير على خط GPIO الخاص به. كانت تلك المراقبات تعمل في خيوط افتراضية. والخيط الافتراضي الذي يتعطل داخل استدعاء أصلي لا يمكن فك تثبيته من خيطه الحامل. يبقى مثبتاً هناك طوال مدة الاستدعاء. جهاز Raspberry Pi 4 له أربعة أنوية، فجدول الخيوط الافتراضية لديه أربعة خيوط حاملة. تسجيل أربعة مدخلات يجعل الحاملات الأربع كلها متوقفة في poll() إلى الأبد. يُنشأ المراقب الخامس، لكنه لا يُجدول أبداً. هذه هي بالضبط المشكلة التي أُبلغ عنها. ليس "الأحداث متقطعة"، بل "الخامس لا يفعل شيئاً."
أكثر ما أعجبني لم يكن التعديل البرمجي، بل المحادثة التي تلت ذلك في المراجعة. تركت تعليقاً أطلب فيه من Copilot شرح هذا بمزيد من التفصيل:
ظننت أن هدف الخيوط الافتراضية هو بالضبط الابتعاد عن حد الخيوط الفيزيائية؟ إذن كيف تكون هذه مشكلة أن أربعة خيوط افتراضية تتعطل وتشغل الخيوط الأربعة على معالج رباعي الأنوية مثل Raspberry Pi؟
اطلع على طلب السحب للمحادثة الكاملة. تمكّن Copilot من ربط استخدام Raspberry Pi الذي له أربعة أنوية معالجة بمشكلة مُبلَّغ عنها. وتمكن من اقتراح إصلاح بسيط للمشكلة، بالإضافة إلى بعض التحسينات الإضافية التي وجدها أثناء تحقيقه.
هل يمكنك مشاركة بعض النصائح والممارسات الفضلى؟
- أخبره أين يبحث: في مشكلة Pi4J رقم 622، أضفت مسارين للملفات. هذا مجهود ضئيل يوفّر قدرًا هائلًا من البحث في قاعدة كود كبيرة. عادةً ما يكون لديك حدس عن المنطقة حتى عندما لا تعرف شيئًا عن الخلل. أعطِ هذه المعلومة للأداة كي لا تحتاج إلى فحص الكود بالكامل.
- اطلب الدليل والاختبارات: «أضف اختبار وحدة للتحقق من التغيير» هو ما أطلبه كثيرًا هذه الأيام. حسنًا، كنت أطلبه، لأنه أصبح الآن قاعدة في ملف التعليمات الخاص بي. وهذا يمنع أيضًا الحالات التي يكون فيها التشخيص خاطئًا، لأن الاختبار لن يفشل مع الكود القديم.
- اسأل عن السبب: إذا لم تفهم إصلاحًا ما، قل ذلك واسأل. الشرح هو مخرَج أيضًا وينبغي إضافته إلى توثيق مشروعك أو داخل التذكرة أو طلب السحب. فهو يعلّم كل من يقرأ هذه المعلومات لاحقًا. على سبيل المثال، أدى هذا أيضًا إلى مزيد من الأسئلة داخل فريق Pi4J حول التصاق الخيوط الافتراضية في الاستدعاءات الأصلية.
- ابقَ مسيطرًا: جميع طلبات السحب هذه في Pi4J تمت مراجعتها والموافقة عليها من قبل المشرفين قبل دمجها. هذا هو النموذج الذي يعمل بأفضل شكل في هذا المشروع: يقوم الوكيل بالتحقيق، ويبقى البشر مسؤولين عمّا يتم إصداره. لكن أيضًا في مشاريعي الأخرى أقوم دائمًا بمراجعة الكود الذي تم توليده بواسطة الأداة. أريد دائمًا أن يظل الكود مقروءًا وقابلًا للصيانة. في كثير من الأحيان، تنشئ الأداة دوالًا مكررة أو تعيد إنشاء شيء موجود بالفعل في مكان آخر ويجب دمجه. هذه مسؤوليتك أنت. يمكنك المضي بسرعة كبيرة هذه الأيام في البرمجة بمساعدة الذكاء الاصطناعي، مما يعني أيضًا أنه يمكنك إنشاء فوضى بسرعة كبيرة. لا تفعل ذلك، حافظ على كودك قابلًا للإدارة، وسيعتذر لك زملاؤك وأنت في المستقبل إذا كانوا مضطرين للتحقيق في الأخطاء أو إجراء تحسينات لاحقًا.
الوسوم:
كتبه
مدافع رئيسي عن السحابة
مقالات ذات صلة
AI & MLكيفية متابعة جلسة تطبيق GitHub Copilot في VS Code
تعرّف على كيفية نقل جلسة وكيل من تطبيق GitHub Copilot إلى VS Code دون فقدان المحادثة أو تغييرات الكود أو سياق العمل.
AI & MLنموذج GitHub لكشف الأسرار: العثور على أسرار أكثر بضوضاء أقل
مصنّف الأسرار المدرك للسياق في GitHub يحسّن جودة الكشف، ويرفع القبول الموزون بنسبة 11.5%، ويقلل الوقت الوسيط لتنفيذ الفحص بنسبة 86%.
AI & MLتطبيق GitHub Copilot للمبتدئين: كيف تُعلّم Copilot عن قاعدة الكود الخاصة بك
تعرّف على كيفية إضافة تعليمات ومهارات مخصصة إلى مستودعك، واستخدام وكلاء مخصصين، وربط خوادم MCP مثل Playwright.