توضح Cassidy Williams، في تدوينة منشورة على مدونة GitHub في 30 يوليو 2026، كيف استخدمت تطبيق GitHub Copilot لتحديث واجهة تطبيق شخصي يعود إلى نحو نهاية عام 2014، بعد أن أصبحت صيانة قاعدة الشيفرة القديمة أكثر صعوبة. التجربة لا تقدم إطلاقاً جديداً بقدر ما تعرض أسلوباً عملياً لتنظيم العمل البرمجي عبر الجلسات المتسلسلة وطلبات السحب المتسلسلة.
كان التطبيق عبارة عن لوحة شخصية تجمع التقويمات والأجهزة الذكية في المنزل وإدارة المهام. وعلى الرغم من أنه ظل يؤدي الغرض المطلوب لسنوات، فإن اعتمادياته أصبحت قديمة جداً؛ إذ كانت الواجهة تستخدم React 15، الذي صدر في عام 2016، إلى جانب Less ونسخة قديمة من react-bootstrap. وتقول Williams إن تفكيك هذه الفوضى وإعادة تنظيمها قبل أدوات الذكاء الاصطناعي كان سيستغرق أسابيع، وقد سبق لها أن حاولت ذلك وتخلت عنه.
محاولة أولى لم تنجح
بدأت Williams بإضافة المستودع إلى تطبيق GitHub Copilot، ثم طلبت في وضع التخطيط تحديث الواجهة الأمامية، والتخلص من Less، وتقييم استخدام Tailwind أو CSS التقليدي، إلى جانب تحسين إمكانية الوصول والاستجابة للشاشات المختلفة. كما تضمنت الخطة تنظيف مكونات React وتنظيمها وتحديث الاعتماديات عند الحاجة.
حددت في طلبها بعض المتطلبات التفصيلية، مثل تغيير ألوان الروابط وإضافة خطوط تحتها عند التمرير أو التركيز، وتقليل استدارة حدود حقول الإدخال، وتحسين تسميات الحقول، وضمان التفاف المحتوى ووضع حد أقصى لعرض الحاويات حتى لا تمتد حقول الإدخال عبر شاشة عريضة بالكامل.
استخدمت Williams Claude Opus 4.8، كما استعانت بمراجعة من GPT-5.5، وأجرت عدة جولات من النقاش قبل تشغيل الخطة. لكنها اكتشفت أن التنفيذ الأول لم ينجح، وكان السبب مرتبطاً بسياق الفروع في المستودع أكثر من كونه فشلاً في الخطة وحدها.
فهم حالة الفروع قبل مواصلة التحديث
اكتشفت Williams لاحقاً أن لديها فرعاً قديماً باسم dev يتضمن بعض التحديثات الجزئية، وأن النسخة التي تستخدمها في النشر تعتمد عليه، بينما بدأت جلسة Copilot الجديدة من الفرع main. ونتيجة لذلك، كانت بعض الميزات التي تريد الاحتفاظ بها موجودة في dev، كما ظهرت مشكلات توافق لم تكن واضحة في البداية.
بدلاً من اعتبار العمل السابق ضائعاً، طلبت من Copilot تغيير المسار. أنشأ التطبيق جلسة جديدة، وأغلق طلب السحب الذي جرت محاولة إنشائه، ثم نقل قرارات تنسيق الواجهة إلى تغييرات يجري تطبيقها على فرع dev. وتبرز هذه الخطوة أهمية مراجعة تاريخ المستودع والفروع المستخدمة فعلياً قبل تكليف الأداة بإعادة هيكلة واسعة.
اختبار التغييرات واكتشاف مصدر التحذيرات
بعد الوصول إلى فرع وطلب سحب أكثر استقراراً، بدأت Williams اختبار التغييرات ولاحظت تحذيرات قديمة في وحدة التحكم، من بينها مراجع إلى findDOMNode وcomponentWillReceiveProps. لم تكن هذه المراجع منتشرة في شيفرتها الحالية، لكنها كانت موجودة في مكتبة react-bootstrap.
عادت إلى وضع التخطيط وسألت عما إذا كان من الأفضل إزالة react-bootstrap واستبدالها ببديل حديث، أو تحديث المكونات الحالية وترحيلها. عرضت الأداة الخيارات وقدمت خطة أوصت بإزالة المكتبة بالكامل. لكن Williams أدركت أن تنفيذ هذه المهمة ضمن طلب السحب الحالي سيزيد نطاق العمل بدرجة كبيرة.
تقسيم العمل إلى جلسات وطلبات سحب متسلسلة
لتجنب إنشاء طلب سحب ضخم يضم تحديث الواجهة واستبدال react-bootstrap في وقت واحد، طلبت Williams من تطبيق GitHub Copilot إنشاء طلب سحب للعمل المنجز، ثم بدء جلسة جديدة لمهمة إزالة المكتبة، على أن تتفرع الجلسة الجديدة من العمل الحالي وتنتج طلب سحب منفصلاً يدمج لاحقاً في dev.
بحسب وصفها، نفذ التطبيق عدة خطوات مترابطة:
- أنشأ طلب سحب للتغييرات الحالية انطلاقاً من فرع dev.
- أنشأ جلسة متسلسلة لمهمة إزالة react-bootstrap، مع الاحتفاظ بسياق الجلسة السابقة.
- وضع خطة جديدة وطلب موافقتها قبل تشغيلها.
- أنشأ طلب سحب متسلسلاً يتبع العمل السابق.
تعرّف Williams طلبات السحب المتسلسلة بأنها سلسلة من طلبات السحب داخل المستودع نفسه، بحيث يستهدف كل طلب فرع طلب السحب الذي يسبقه، لتشكيل سلسلة مرتبة تنتهي بالفرع الرئيسي. وفي تجربتها، لم تتتابع طلبات السحب فقط، بل تتابعت الجلسات والتغييرات أيضاً.
ما الذي يمكن الاستفادة منه؟
ترى Williams أن أدوات البرمجة الوكيلة تجعل توسيع نطاق المهمة أمراً مغرياً، لأن المطور لا يكتب كل سطر بنفسه. وقد يؤدي ذلك إلى إنشاء طلبات سحب ضخمة تتعامل مع عدد كبير من المشكلات في آن واحد. لذلك كان تقسيم المهمة إلى مراحل مستقلة وسيلة لتقليل المخاطر وتسهيل الاختبار والمراجعة.
تقدم التجربة عدة ممارسات عملية: ابدأ بخطة واضحة، راجع الفروع والنسخة المنشورة قبل تنفيذ تغييرات كبيرة، اختبر العمل المرحلي لاكتشاف الاعتماديات القديمة، وافصل المهام التي تمثل توسعاً في النطاق داخل جلسات وطلبات سحب مستقلة. وتوصي Williams بتجربة هذا الأسلوب عند تحديث قواعد شيفرة قديمة، مع التأكيد الضمني على أن نجاح الأدوات لا يلغي الحاجة إلى اتخاذ القرارات ومراجعة الخطط والنتائج.