GOOSE GAME KATA ، التي تم في زوج مع Github CoPilot ، لتشويش مهاراتي الهندسية الفوري والتفكير في أنماط الاتصال التي يجب تبنيها عند الاقتران مع أداة ترميز بمساعدة AI؟
بدأ كل شيء بالمطالبة التالية:
أرغب في القيام بترميز كاتا معك ، لممارسة TDD معًا ، إعادة التجديد وتصميم البرامج. سنحاول متابعة TDD وخطواتها بدقة تامة. نحن نذهب إلى رمز Kata في Kotlin ، باستخدام إعداد مشروع بسيط في Gradle. Kata هي ما يلي: https://github.com/xpeppers/goos-game-kata. سنبدأ بالميزة الأولى ، مع دورة TDD لإضافة اختبار ، وجعلها تمر ، وإعادة تشكيل الكود ، والتكرار. سنعمل في خطوات صغيرة ، بشكل متكرر.
الميزة الأولى هي ما يلي:
1. إضافة اللاعبين
كلاعب ، أريد أن أضيفني إلى اللعبة حتى أتمكن من اللعب.
سيناريوهات:
- أضف لاعب
If there is no participant
the user writes: "add player Pippo"
the system responds: "players: Pippo"
the user writes: "add player Pluto"
the system responds: "players: Pippo, Pluto"
- لاعب مكرر
If there is already a participant "Pippo"
the user writes: "add player Pippo"
the system responds: "Pippo: already existing player"
سوف تكتب الاختبار الأول ، ثم سأقدم لك تعليقات حول جودته. إذا كان الاختبار على ما يرام بالنسبة لي ، فسوف ننتقل إلى تنفيذ رمز التطبيق الذي سنقوم بإجراء تمرير الاختبار. بعد ذلك ، سوف نبحث عن أي فرصة لجعل الكود أكثر وضوحًا ، وأسهل لفهمه عن طريق إعادة تمثيله.
جنبا إلى جنب مع الكود ، يمكنك العثور على المطالبات التي استخدمتها لتوجيه جلسة البرمجة الزوج في prompts
> أقدم. لقد قمت بإنشاء ملف موجه جديد لكل خطوة جديدة قمنا بها. وضعت المزيد من المطالبات في نفس الملف ، مفصولة بخط ---
، عندما لا تؤدي موجه واحد إلى اجتياز جميع الاختبارات.
ملاحظاتي على أداء هذه الكاتا مع Copilot
- أشعر أنني أقل تركيزًا على الكود الناتج ، وأكثر تركيزًا على المطالبة الصحيحة وما إذا كانت الاستجابة "تعمل" أم لا
- لقد لاحظت أنه في بعض الأحيان أركز أكثر على شكل المطالبة وما إذا كان الكود يجمع ولا تزال الاختبارات تمر بدلاً من شكل الكود ... في بعض الأحيان قادنا إلى طريق مسدود ، واضطررنا إلى إعادة التغييرات وابدأ مرة أخرى.
- ليس من الواضح مدى حساسية CoPilot لما هو أفضل بعد إعادة التجديد: Refactor في الإرادة؟ متى من المنطقي الانتقال إلى الاختبار التالي؟
- في كثير من الأحيان ، تكون "المواصفات" غامضة بطبيعتها (ماذا تعني "اللعبة التي تعني النرد"؟) => مواجهة هذا الغموض ، فمن المحتمل جدًا أن استجابة النموذج ليست "الصحيح" ، إلا إذا قللنا من الغموض في المطالبة بأنفسنا (وبالتالي افتراض دور "Disambiguators" ، "العميل")
- في بعض الأحيان ، تفاجئني ردود النموذج (على سبيل المثال ، تمكنت من فهم السياق جيدًا وتعديل الكود لاحترام نمط وشكل الكود الحالي) ، وفي أوقات أخرى ترتكب أخطاء تبدو مثل "أخطاء الهاء" كما نفعل نحن البشر؟
- لدى Copilot نافذة سياق ممتازة ، ويمكن أن يتذكر الأشياء التي قالت العديد من المطالبات من قبل.
- عندما تقوم بإعادة تهيئة التغييرات أو تقترحها ، فإنها لا تدرك أنها تحتاج أيضًا إلى إصلاح الاختبارات ... فهي تركز دائمًا على رمز التطبيق فقط؟
- عندما يحتاج الرمز إلى إعادة إنشاء تحضيرية لاستيعاب الميزة التالية (الكلاسيكية "الأولى ، اجعل التغيير سهلاً ، ثم قم بإجراء التغيير السهل") ، صراعات Copilot:
- لا يبدو أنه غير قادر على مواجهة هذا النوع من التفكير (كما هو الحال في "نحن بحاجة إلى العودة إلى الوراء ومراجعة الأشياء بشكل استراتيجي")
- يفشل في تحديد الروائح "المعقدة" كما هو الحال عندما يكون المنطق الذي نحتاجه للميزة التالية منتشرة عبر فئات متعددة ، لذلك نحن بحاجة إلى التراجع قبل المضي قدمًا.
- حتى إذا أخبرتها أن تبدأ من نقطة الصفر ، رمي جميع التعليمات البرمجية التي تم إنتاجها من الاختبار الذي ظل حمراء ، فإنه غالبًا ما يكرر نفس الخطوات ، حتى لو أخبرته "لنجرب نهجًا جديدًا" أو "دعونا نفعل أشياء في خطوات صغيرة ".
انظر أيضًا تأملاتي هنا (الإيطالية)