Latest / M365.FM – بودكاست Microsoft 365 وCopilot والذكاء الاصطناعي بالعربية / وداعاً لتصحيح الأخطاء بالترقيع: وضع الوكيل في GitHub Copilot لمشاريع .NET وAzure (دبلجة بالذكاء الاصطناعي)
Transcript
- 0:00هل أنت مستعد لعشرة أيام من مايكروسوفت 365 وكو بايلوت والذكاء الاصطناعي وأشر ومن يصيغون مستقبل العمل؟
- 0:07في يناير القادم يعود مؤتمر M365 وسنقدم لكم نسخة أكبر
- 0:12انضم إلينا في جلسات مباشرة وعروض واقعية ومعرفة عملية من خبراء مايكروسوفت وأبرز المتخصصين حول العالم
- 0:18لا شرائح عرض تقليدية لا مصطلحات جوفاء لا تنتهي
- 0:22نحن نعالج التحديات الحقيقية كو بايلوت ستوديو ووكلاء الذكاء الاصطناعي وفابريك والأمن والحوكمة والأتمتة
- 0:29سواء كنت متخصصا في تقنية المعلومات أو مطورا أو قائدا للأعمال
- 0:33هناك جلسات مصممة خصيصا لك
- 0:35عبر عشر أيام كاملة يمكنك استكشاف تقنيات متعددة والتواصل مع مجتمع عالميا
- 0:40شاهد الفعاليات مباشرة وانقل رؤى عملية إلى مؤسستك
- 0:44يناير 2027 عشر أيام مجتمع مايكروسوفت واحد
- 0:49التسجيل مفتوح الآن
- 0:51توجه إلى M365.net وحجز مقعدك اليوم
- 0:55الموقع هو M365.net
- 0:59انضم الآن عبر M365.net
- 1:02وسنلتقي بكم مباشرة في يناير
- 1:04إذا سبق لك فتح حل برمجي وشعر تفورا بالإرهاق من كثرة الملفات والمراجع والأخطاء الكامنة بانتظارك
- 1:10فأنت لست وحدك
- 1:11يعمل معظم المطورين بطريقة تفاعلية حيث يقومون بالتصحيح هنا وإصلاح الأخطاء هناك
- 1:15يهدف وضع الوكيل agent mood في بيتهب كوبايلوت إلى استيعاب سياق أوسع وتنسيق التغييرات عبر الملفات
- 1:20في هذا الفيديو سنعرض كيف يبدو سير العمل هذا داخل مشروع حقيقي لمبودكاست.net وأشر
- 1:25سنستعرض حلا برمجيا مباشرا ونقارن التغييرات قبل وبعد استخدام الوكيل
- 1:28سترى كيفية إنشاء قود لملفات متعددة بجهد أقل
- 1:31وحل أخطاء الملفات المتقطعة بسرعة
- 1:33وحتى استخدام مواصفات باللغة الطبيعية لهيكلة الميزات
- 1:36وقبل أن نصل إلى ذلك
- 1:37دعونا نبدأ بالتكلفة الخفية لحلقة تصحيح الأخطاء التي يعيشها الكثير من يوميا
- 1:41التكلفة الخفية لتصحيح الأخطاء المجزئي
- 1:43تجلس لإصلاح خطأ يبدو بسيطا بما يكفي
- 1:46لا يتم بناء التطبيق وتشير وحدة التحكم إلى سطر في ملف المشروع الرئيسي الخاص بك
- 1:50تعدل الطريقة وتعيد الترجمة
- 1:52وتظن أنك حللت الأمر حتى تظهر رسالة نفسها بشكل مختلف قليلا
- 1:56يمضي نصف ساعة أخرى قبل أن تكتشف المشكلة الحقيقية
- 1:59اعتمادية مفقودة مخبأة في مجلد مشروع آخر
- 2:02بحلول الوقت الذي يتم فيه تصحيح المرجع وإعادة النشر
- 2:04تكون معظم فترة بعد الظهر قد ضعت في الإصلاحات المتقطعة
- 2:07يتم تأجيل عمل الميزات الذي خطط له إلى الغد
- 2:09هذا النمط شائع جدا لدرجة أنه يبدو طبيعيا
- 2:12ظاهريا أن تتقدم لأن كل خطأ تقضي عليه يبدو وكأنه انتصار
- 2:15عمليا أن تدور في حلقات مفرغة
- 2:17الحلقة هي كتابة الكود الترجمة ظهور الخطأ الإصلاح ثم التكرار
- 2:21تضيع الساعات في مطاردة سلسلة من الأسباب والنتائج
- 2:23والنتيجة النهائية هي تقدم تفعلي بدلا من تحسينات ذات مغزا
- 2:26كم منكم أضاع فترة بعد الظهر في هذه الحلقة تحديدا
- 2:29أترك تعليقا من سطر واحد
- 2:31وسأقرأ الردود الأكثر تفاعلا
- 2:32ما يجعل هذه الدورة مرهقة هو أن الأدوات من حولنا تتطور بينما يظل النمط كما هو
- 2:37تضيف المحررات ميزات جديدة
- 2:38وتتطور الأطور البرمجية وتزداد التكاملات عمقنا
- 2:41لكن التصحيح لا يزال يتطلب نجنا رد فعلا
- 2:43الأمر أشبه بمحاولة إخماد حريق متزايد بدلو من الماء
- 2:47يتم التعامل مع كل دلاع في لحظته
- 2:48لكن الظروف الكامنة التي أوقدته تضل قائمة
- 2:51مما يضمن تقريبا الحريق التالي
- 2:52ومع كل تبديل لعلامة التبويب
- 2:54ترتفع التكلفة الخفية
- 2:55تنتقل من فئة الخدمة إلى ملف التكوين
- 2:57ثم تقفز عبر رسم بياني للتبعية
- 2:59كل تحول يسحبك بعيدا عن أي خيط منطقي تتبعه
- 3:02مما يفرد إعادة تعيين ذهنية
- 3:04ليس الأمر مجرد ثوان تقضيها في تنقل بين النوافذ
- 3:06بل هو الضريبة الذهنية لإعادة بناء السياق مرارا وتكرارا
- 3:09على مدار اليوم
- 3:10تتراكم عمليات إعادة تعيين صديرة هذه لتصبح عبنا ثقيلا
- 3:13بالنسبة للمطورين الأفراد
- 3:14يظهر التعب في شكل إحباط ووقت ضائع
- 3:16بالنسبة للفرق التي تعمل على مشاريع مؤسسية
- 3:19يتضاعف التأثير
- 3:20حلقات التصحيح تخرج أهداف السبرينت عن مسارها
- 3:22وتؤخر إطلاق الميزات
- 3:24وتفتح تراكم عمل ينمو أسرع مما يتقلص
- 3:26تفاقم الديون التقنية ليس سوى تأثير جانبي آخر
- 3:29للساعات المفقودة في مكافحة الحرائق
- 3:31تشير العديد من الفرق إلى أن جزءا كبيرا
- 3:33من وقت تطويرها يستنزف في التصحيح التفاعلي
- 3:35إنه ليس الجزء المثير في الهندسة
- 3:37لا أحد يخطط لخريطة طريق تعتمد على ملاحقة نفس عدم تطابق التبعيات خمس مرات
- 3:41ومع ذلك هذا هو المكان الذي تذهب إليه الموارد
- 3:44أسبوعا تلو الآخر
- 3:44عندما يصبح إصلاح الأخطاء هو تعريف التقدم
- 3:47تصبح بناء الميزات الجديدة ثانوية وتعاني البنية التحتية بصمت في الخلفية
- 3:51الحقيقة المزعجة هي أن التصحيح الترقيعي لا يبطئ الأمور فحسب
- 3:55إنه يعزز ثقافة رد الفعل بدلا من التصميم
- 3:58أن تقضي وقتك في إخماد النيران لا في بناء الأنظمة
- 4:01قد يبقي ذلك المنتج حيا على المدى القصير
- 4:04لكنه يحد من مدى توسع الفريق ومدى ثقتهم في التسليم
- 4:07لذا دعونا نتوقف عند هذه الصورة مكافحة الحرائق
- 4:09أن دفع إلى بؤرة الاشتعال أسكب الماء ثم انتقل لما بعده
- 4:12المشكلة ليست في أن المطورين ليسوا بارعين في ذلك
- 4:15إنهم بارعون
- 4:16المشكلة هي أن النيران لا تتوقف حقا
- 4:18إنها تتحرك فقط تندلع في ملفات جديدة
- 4:20مشاريع جديدة تكوينات جديدة
- 4:22مما يبقي الجميع في وضع الاستجابة بدلا من وضع الإبداع
- 4:24هذا يطرح السؤال
- 4:25ماذا يحدث لو لم تكن هذه الدورة ملقاة على عاتقك وحدك
- 4:29ماذا لو أمكن إدارة الأجزاء المتكررة
- 4:31حلقة التتبع والتبديل والتصحيح بشكل مختلف بينما تظل أنت مركزا على البناء
- 4:36لأنه بينما يبدو ضغط مكافحة الحرائق واضحا
- 4:38هناك نقطة ضغط أخرى لم نتطرق إليها بعد
- 4:40تأتي الصعوبة الحقيقية عندما لا يقتصر مشروعك على ملف واحد أو وحدة واحدة
- 4:44تحدث عندما يمتد الإصلاح الذي تحتاجه ليشمل طبقات متعددة في وقت واحد
- 4:48تخيل أنك تجلس لفتح حل برمجي تتوزع منطقياته عبر مشاريع وخدمات ومكتبات مختلفة
- 4:54الجزء الذي تحتاجه موجود في ثلاثة أماكن في آن واحد
- 4:57والحفاظ على تركيزك في هذا التشتت هو معركة بحد ذاتها
- 5:00فوضى الملفات المتعددة مقابل التحكم في السياق عبر الذكاء الاصطناعي
- 5:04عندما تمتد المشاريع عبر طبقات متعددة لا تكمن التحدي الحقيقي في كتابة الكودي
- 5:08بل في الحفاظ على ترابط كل تلك الأجزاء المتحركة معا
- 5:11هنا يظهر بوضوح التوتر بين فوضى الملفات المتعددة والتحكم في السياق المدعوم بالذكاء الاصطناعي
- 5:15خذ على سبيل المثال حل نيت كبيرا يضم عشرة مشاريع أو أكثر
- 5:19عادة ما تؤثر أي ميزة جديدة على طبقات مختلفة في وقت واحد
- 5:22متحكم في مكان وخدمة في آخر ومجموعة من ملفات الإعدادات في مكان ثالث
- 5:27قبل أن تكتب سطرا وحدا تقضي وقتا في تتبع المراجع وفحص التبعيات
- 5:31على أمل أن لا يؤدي تغيير بسيط إلى أعطال غير متوقعة في السلسلة
- 5:35هذا النمط في العمل ليس استثناء
- 5:37بل هو الوضع الطبيعي في تطبيقات المؤسسات خاصة عند دخول خدمات أشر والتكاملات في الصورة
- 5:42هيكلية هذه الأنظمة ليست مصطحة
- 5:45تلعب الواجهات وتعينات حقن التبعية دي والمراجع العابرة للمشاريع أدوارا محورية
- 5:50مع وجود أشر تخرج بعض التبعيات تماما عن نطاق مجلد الحل
- 5:53مثل تطبيقات الوظائف وربط ناقل الخدمة وإعدادات الموارد واتصالات التخزين
- 5:58أن تنسق بين الكود في بيئة التطوير وملفات الإعدادات على القرص والخدمات المعرفة في السحابة
- 6:03لا أحد منها يهتم برغبتك في تقليل عدد النقارات
- 6:06في كل مرة تغير فيها السياق تستهلك طاقتك في إعادة بناء الصورة الكبيرة
- 6:10يحاول معظمنا التوفيق بين هذا السياق في ذاكرة العمل الخاصة به
- 6:12في البداية يكون الأمر قابلا للإدارة
- 6:14ولكن مع نمو المشروع تتسلل الأخطاء
- 6:16تضيف طريقة جديدة في الخدمة لكنك تنسى تسجيلها في حقن التبعية دي
- 6:20تكتب كود وظيفة أشر ثم تكتشف لاحقا أن الربط لم يضيف إلى ملف هوست جيسون أو قالب النشر
- 6:24لا شيء ينبهك حتى وقت التشغيل حيث تجد نفسك في مرحلة التصحيح بدلا من البناء
- 6:28الكود بحد ذاته ليس الجزء الصعب
- 6:30الجزء الصعب هو التنسيق بين الملفات المختلفة
- 6:32يعرف الجميع شعور التنقل بين علامات التبويب من متحكم إلى خدمة
- 6:36ثم إلى نموذج ثم إلى ملفات الإعدادات
- 6:38ثم العودة مجددا فقط لتفقد سبب فتحك لهذا الملف من الأساس
- 6:41إنهم قطاع بسيط يتكرر عشرات المرات في اليوم
- 6:44تتراكم تلك التفاعلات مما يخلق احتكاكا يعيق التقدم الحقيقية
- 6:48النتيجة هي بطء في التسليم ليس لأن الكتابة بطيئة
- 6:51بل لأن الحفاظ على مزامنة كل شيء يشتط التركيز
- 6:54تتزايد هذه الأعباء في المشاريع المعتمدة على السحابة أولا
- 6:57توزع أشر الأعدادات الرئيسية في أماكن متعددة
- 6:59مثل ملفات التكوين المحلية
- 7:01ومتغيرات البيئة وقوالب أرم أو بي سيب
- 7:04وخطوط أنا بي بي سي سي دي
- 7:06ما يبدو كطلب ميزة واحد غالبا
- 7:08ما يمتد عبر أربع طبقات من التجريد
- 7:10هذا التعقيد ليس اختياريا
- 7:12إنه جزء لا يتجزأ من طريقة عمل النظام البيئي
- 7:15هنا يأتي دور وضع الوكيل
- 7:16أيجنت مود كتحول محتمل
- 7:18بدلا من ترك كل هذا التنسيق لك
- 7:20فقد صم ما ليمتلك سياقا أو سع عبر ملفات متعددة
- 7:22هذا يعني أنه عندما تطلب تغييرا في طبقة واحدة
- 7:25فإنه لا يتجاهل الطبقات الأخرى
- 7:27في العرض التوضيحي سأنشئ وظيفة أشر جديدة
- 7:29وأعرض كيف يساعد الوكيل عبر إنشاء متن الطريقة
- 7:32وإعداد تكوين الربط وتحديث هوست جيسا
- 7:35وحتى اقتراح تسجيل حقن التبعية دي المناسب
- 7:37عادة ما تكون هذه عملية متعددة الخطوات ومشتتة عبر ملفات مختلفة
- 7:41يمكن للوكيل تبسيطها في تدفق عمل واحد
- 7:43لا يتعلق الأمر باستبدال حكمك
- 7:45بل بإزالة المهام الإدارية المتكررة
- 7:47حتى تتمكن من التركيز على خيارات التصميم الفعلية
- 7:50يمكن للبشر الاحتفاظ بمخطط تقريبي في أذهانهم أو رسمه على سبورة بيضاء
- 7:54يمكن للذكاء الاصطناعي تتبع التفاصيل ملفا تلو الآخر دون فقدان الخيط
- 7:58ما يبدو عبنا ذهنيا كبيرا بالنسبة لنا هو مجرد سياق أساسي للوكيل
- 8:01الفرق في الممارسة العملية هو الانتقال من التبديل المشتت بين علامات التبويب إلى تغييرات منسقة تبقى متزامنة
- 8:06سأعرض أيضا طلب السحب
- 8:07أو الاختلافات
- 8:08التي أنشأها الوكيل خلال العرض التوضيحي حتى تتمكن من رؤية التعديلات التي تم إجراؤها بدقة
- 8:13تلك الرؤية مهمة
- 8:14تحصل على تحكم كامل للمراجعة والموافقة بينما يتم إنجاز العمل الشاقي لتحديث ملفات متعددة نيابة عنك
- 8:19بدلا من قضاء فترة بعد الظهر في ربط الأجزاء ببعضها
- 8:21تقوم بتوجيه التغيير مرة واحدة وتأكيد التحديثات التي تم إنشاؤها والانتقال إلى تصميم عالي المستوى
- 8:26الراحة ليست فقط في توفير النقرات أو ضغطات المفاتيح
- 8:29بل في البقاء مركزا على حل المشكلات الفعلية بدلا من تتبع كيفية اتصال عشرات الملفات
- 8:34تظهر هذه الميزة بوضوح أكبر عند تعطل الأمور
- 8:36لأنه حتى مع معالجة سياق أقوى تفشل الأنظمة وتنحرف التكوينات وتتسلل المراجع غير المتطابقة مجددا
- 8:42وهنا يبدأ الاختبار التالي
- 8:43كيفية تتبع الأخطاء وحلها بمجرد ظهورها
- 8:47من البحث عن الأخطاء إلى الإصلاحات الذاتية
- 8:49فكر في عدد المرات التي واجهت فيها رسالة خطأ تشير مباشرة إلى ملف واحد
- 8:53تتبع تتبع المكدس إلى الطريقة التي يسميها
- 8:56وتقوم بتعديل صغير ثم تضغط على إعادة البناء
- 8:58يبدو الأمر حلا بديهينا حتى يظهر نفس الخطأ مرة أخرى بشكل مختلف قليلا
- 9:03عندها تدرك أن تتبع المكدس أظهر العرض فقط
- 9:06المشكلة الحقيقية تكمن في مكان آخر تماما
- 9:08ربما في فئة داعمة أو مخفية داخل ملف تكوين لم تفتحه طوال الأسبوع
- 9:11كل مطور واجه هذا النوع من التضليل
- 9:14ما يبدو أنه المشكلة ليس هو في الواقع مكان الحل
- 9:16هذا يستهلك الوقت بسرعة
- 9:18تعدل شيئا وحدا ثم تعيد البناء وتنتظر
- 9:20ثم يواجهك خطأ جديد يقودك إلى ملف آخر وتعديل آخر
- 9:24وإعادة بناء أخرى
- 9:25تبدو الحلقة الإنتاجية وكأنها عمل مستمر لأنك تتحرك وتكتب وتعيد التجميع
- 9:28لكنها في جوهرها تجربة وخطأ أكثر من كونها حلا فعليا
- 9:32هذه الدورة يمكن أن تلتهم الساعات تاركة إياك مع إصلاحات سطحية بسيطة دون أي تقدم حقيقي في الميزة التي بدأت بها
- 9:38التكلفة الحقيقية هنا هي ضياع الفرص
- 9:40بينما أنت عالق في وطيرة إعادة البناء والمحاولة
- 9:43فأنت لا تحل مشاكل العمل ولا تقدم الوظائف التي ينتظرها المستخدمون
- 9:47يضيع الزخم في التخمين بدلا من التصميم
- 9:50يبدو الأمر نشطنا في تلك اللحظة
- 9:52لكن تلك الساعات لا تضيف الكثير سوى منع النظام من التعطل
- 9:55على مستوى الفريق تقطئ هذه الحركة السطحية كل شيء وتخلق تراكما في الميزات التي تستمر في التأجيل
- 10:01هنا يبدأ سير عمل الوكيل في الاختلاف
- 10:04الفكرة ليست التوقف عند السطر الواحد الذي يبزه تتبع المكدس ستاك تريس
- 10:08بدلا من ذلك تم تصميمه ليحتفظ بسياق على مستوى النظام
- 10:11لا يسأل فقط عما يجب أن يفعله هذا الملف
- 10:14بل ما هي سلسلة التغييرات المطلوبة عبر الأجزاء المتصلة لاستعادة الاتصاق
- 10:17من الناحية العملية هذا يعني أنك قد تراه يقترح تعديلات تمتد عبر ملفات متعددة
- 10:22على سبيل المثال سترى في العرض التوضيحي أنه عندما تتطلب إحدى الطرق تغييرات
- 10:25يمكنه اقتراح تعديلات مطابقة في ملفات التكوين ذات السلة أو قوالب النشر
- 10:29بدلا من تركك تبحث عنها بنفسك
- 10:30تلك هي القفزة من الإكمال التلقائي إلى شيء أوسع
- 10:33الإكمال التلقائي ينهي الأسطرة أما الوكيل فينسق عبر الملفات
- 10:36وهذا التنسيق يهم أكثر عندما لا تكون الأخطاء موجودة في مكان واحد بوضوح
- 10:40لنأخذ سيناريو شائعا في أشر
- 10:42لقد أنشأت تطبيق وظيفة جديدا
- 10:44ولكن بمجرد نشره يفشل مشغل قائمة الانتظار لأن الربط لا يتطابق مع توقيع الطريقة
- 10:48عادة تقوم بالتنقيب في السجلات ومعرفة أي ربط هو الخاطئ
- 10:51وتعديل جايسون الوظيفة يدويا
- 10:53وربما حتى تغيير قالب البنية التحتية الخاص بك إذا كانت القيمة غير متطابقة هناك أيضا
- 10:57كل خطوة هي مطاردة منفصلة وكل إصلاح يؤدي إلى تشغيل اختبار آخر
- 11:01مع وضع الوكيل يختلف سير العمل
- 11:04يمكنه اقتراح تغيير الكود وإنشاء ربط جايسون الوظيفة المناسب
- 11:07وإظهار التعديلات لنصوص المشر البرمجية إذا كانت غير متوافقة
- 11:10أن تراجع وتؤكد وتمضي قدما دون قضاء ساعات في تجميع كل طبقة معا
- 11:14والثقة هي المفتاح هنا
- 11:15لا ينبغي لأحد أن يشعر بأن تعديلات غير مرئية تحدث في الخلفية
- 11:18لهذا السبب فإن عملية المراجعة مهمة
- 11:20في هذا العرض التوضيحي سنستعرض ذلك معا
- 11:22يقترح الوكيل التغييرات المنسقة
- 11:24سنفتح ملف الفرق دف لنفحص بدقة ما تم إنشاؤه
- 11:27ونشغل اختباراتنا الوحدوية ونتحقق من البناء محليا
- 11:30وعندها فقط نختار قبول التعديلات أو رفضها
- 11:33حلقة التحقق هذه تبقي كفي كامل السيطرة بينما تتخلص من الأعمال الشاقة
- 11:37تجدر الإشارة إلى أن الوكلاء يمكنهم المساعدة في تسريع العمل
- 11:39لكنهم لا يغنون عن ممارسات الهندسة الجيدة
- 11:41يجب أن تظلت عمل مراجعات الكود وعمليات التكامل المستمر
- 11:44سي كحراس بوابة لا يمكن التنازل عنهم
- 11:46داع ذكاء الاصطناعية يقلل الوقت الذي تقضيه في أعمال التحري
- 11:48لكن احتفظ بالفحوصات الآلية والمراجعة البشرية كشبكة أمان
- 11:51هذا التوازن يحل مشكلة الثقة ويضمن أن مكاسب السرعة لا تقود الاستقرار
- 11:55فرق السرعة ليس نظريا فحسب
- 11:57حيث قد تستهلك ملاحقة الأخطاء والتصحيح اليدوي نصف يوم
- 12:00يمكن للاقتراحات المناسقة اختصار ذلك إلى دقائق
- 12:03والوقت المسترد يتدفق ليعود إلى العمل الذي ترغب حقا في تكريس طاقتك له
- 12:07الميزات التي يلاحظها مستخدمك
- 12:08وقرارات الهندسة المعمارية التي تحسن قاعدة الكود الخاصة بك
- 12:11بدلا من إطفاء الحرائق وقت التشغيل
- 12:13يمكنك التصميم بثقة مسبقة
- 12:15لذا لا يجب أن تحدد حلقة تصحيح الأخطاء يومك بعد الآن
- 12:18مع وكيل يقترح تحديثات عبر الملفات
- 12:20تتحول من البحث العشوائي إلى إيقاع المراجعة والموافقة
- 12:23تتوقف عن الدوران في حلقات مفرغة حول الأخطاء
- 12:26وتبدأ في التعامل مع التصحيح كخطوة منظمة وشبه آلية في سير عملك
- 12:30هذا التحول يفرغ مساحة دهنية وساعات عمل لبناء الميزات
- 12:33وليس فقط إصلاح العيوب
- 12:34وبمجرد أن يصبح إصلاح الأخطاء أقل تركيزا على ملاحقة الأعراض
- 12:37يفتح ذلك الباب لشيء أكبر
- 12:39كيف يمكنك بدء ميزات كاملة بنفس الطريقة المنظمة
- 12:42تخيل لو أن نفس سير العمل الذي يقترح إصلاحات منسقة
- 12:46يمكنه أيضا أخذ مواصفات بلغة واضحة وتشكيل هيكل عمل حولها
- 12:50هنا تبدأ المرحلة التالية من التطوير
- 12:52التطوير القائم على المواصفات بدون أعباء إضافية
- 12:55أحد أكثر التحولات إثارة للاهتمام يأتي عندما تتوقف عن التفكير فقط من حيث الملفات والأساليب
- 13:00وتبدأ في صياغة العمل بلغة بسيطة بدلا من ذلك
- 13:02وهنا يأتي دور التطوير القائم على المواصفات بدون تعقيدات زائدة
- 13:06تخيل كتابة طلب ميزة بسيط
- 13:08أضف سير عمل للتقارير ينشئ ملخصات شهرية ويخزنها
- 13:11ويجعلها متاحة من خلال صفحة إدارية
- 13:14بدلا من الخصول على بضع مقتطفات معزولة فقط
- 13:16تحصل على هيكل عمل تم تعيينه بالفعل عبر تطبيقك
- 13:19يتم إنشاء المتحكمات
- 13:21والنماذج
- 13:22وتسجيل الخدمات
- 13:23وربط الإعدادات
- 13:24هذا الانتقال من وصف القصد إلى رؤية هيكل ملموس يظهر في مشروعك
- 13:28هو المكان الذي يشعر فيه هذا النهج أخيرا بأنه عملي وليس نظريا
- 13:31في الإعدادات التقليدية
- 13:33يتمتع التطوير القائم على المواصفات بسمعة ثقيلة
- 13:35في المؤسسات الكبيرة
- 13:36يعني هذا عدتا مستندات متطلبات طويلة
- 13:38وأوراق تصميم متعددة صفحات
- 13:40ومخططة جامدة تبطئ الجميع
- 13:42إنها منطقية في الصناعات الخضعة للتنظيم أو الفرق الموزعة عالميا
- 13:44ولكن بالنسبة للبرمجة اليومية
- 13:46يتجاوزها معظم المطورين
- 13:47إن كتابة المواصفات التفصيلية والحفاظ عليها يضيف تكلفة لا يملك أحد الوقت أو الصبر لها
- 13:52إنه عمل إضافي فوق مهام تسليم الميزات
- 13:54ومع اقتراب الموعيد النهائية
- 13:55عادة ما يتم التضحية بهذه الجهود الإضافية
- 13:57المفارقة واضحة
- 13:58فالمطورون يحبون في الواقع التفكير في الخطوط العريضة
- 14:01معرفة الهيكل مسبقا يبعث على الطمأنينة
- 14:03المشكلة ليست في النية
- 14:05بل في المتابعة والصيانة
- 14:06بمجرد أن تبدأ المواصفات في فقدان التزامن مع الواقع
- 14:09تصبح صيانتها عبئا
- 14:10لهذا السبب يميل الكثير من العمل الواقعي نحو الارتجال بدلا من التصميم الكامل
- 14:14حتى في الشركات التي تؤيد تقنيا التخطيط المكثفة
- 14:17يوفر سير عمل الوكيل
- 14:18بديلا لذلك
- 14:20بدلا من المطالبة بوثيقة تصميم مسكولة
- 14:22يمكنه المساعدة في ترجمة مواصفات باللغة العادية إلى هيكل أساسي يمكنك تحسينه
- 14:26لا تحتاج إلى مخططات UML أو خرائط واجهات مكتوبة بخط اليد
- 14:29يمكنك ببساطة أن تطلب إنشاء وحدة تقارير مع نقطة نهاية APA جديدة
- 14:33وربطها بالتخزين
- 14:34وتأمينها بوصول يعتمد على الأدوار
- 14:37ليقوم النظام بتوليد أساس عبر الملفات في حل
- 14:39نيث الخاص بك
- 14:40في العرض التوضيحي
- 14:41سأقرأ مواصفات باللغة العادية بصوت عال
- 14:43ثم سأعرض الملفات التي أنتجها الوكيل
- 14:45من وحدات تحكم ونماذج وتسجيل خدمات
- 14:47وسأشير إلى النقاط التي لا تزال بحاجة إلى تحسين يدويا
- 14:50بهذه الطريقة يمكنك الحكم على الجودة بنفسك
- 14:53هذا يضع أرضية مشتركة بين أسلوب عمل للمطورين
- 14:56من جهة هناك البرمجة العفوية فيب كود سريعة وحرة الشكل
- 14:59لكنها هشة للأنظمة طويلة الأمد
- 15:01ومن جهة أخرى هناك التصميم المعتمد على المواصفات موثوق
- 15:04لكنه بطيء بشكل مؤلم
- 15:06مع دعم الوكيل توضح فكرتك بكلمات طبيعية
- 15:08فيظهر الهيكل الأساسي
- 15:10ويمكنك التكرار بسرعة تقارب البرمجة العفوية
- 15:12مع الحفاظ على ميزة الهيكل المنظم
- 15:14لنأخذ سير عمل التقارير مرة أخرى
- 15:16عادة يتعين عليك إنشاء النموذج
- 15:18وبناء خدمة البيانات
- 15:19وتوصيل وحدة التحكم وتكوين الأمان
- 15:21وربط كل شيء في ملف البدء
- 15:23وهذا يعني التنقل بين ملفات متعددة
- 15:25والأمل في الحفاظ على الاتساق
- 15:26مع هذا النهج يضع الهيكل الأساسي في مكانه دفعة واحدة
- 15:30التوفير الحقيقي لا يأتي من كتابة عدد أقل من الأسطر
- 15:32بل من تجنب أخطاء الملفات المتداخلة
- 15:34مثل نسيان تسجيل خدمة جديدة بعد أن قمت ببنائها بالفعل
- 15:36بالطبع هناك دائما تساؤل حول الأسلوب
- 15:39هل سيفرض الذكاء الاصطناعي قوالب جاهزة أو يتجاهل الاتفاقيات المتبعة
- 15:42من الناحية العملية غالبا ما تعكس الوكلاء أن ماط المشروع الحالية في اقتراحاتهم
- 15:46في العرض التوضيحي سترى كلا الجانبين
- 15:48مواضع تطابق فيها هيكل وحدة التحكم الخاصة بنا تماما
- 15:51ومواضع أخرى تعدد فيها تخميناته عن المساري
- 15:54هذا المزيج مهم
- 15:55ستعرف ما يمكنك الوثوق به وما لا تزال بحاجة إلى تعديله
- 15:58النتيجة النهائية ليست كودا نمطيا مكررا
- 16:00لا يزال المشروع يبدو كأنه مشروعك الخاص فقط بجهد أقل في أعداد الهيكل اليدوي
- 16:04يمكنك الحفاظ على السرعة مع الاستناد إلى أساس قابل للتطوير من أجل النمو المستقبلي
- 16:08بدلا من أن يقتصر العمل على المواصفات على المهندسين الذين يتحلون بالصبر لرسم المخططات
- 16:13يصبح أداة لأي مطور يريد التجربة بسرعة دون التضحية بالنظام
- 16:17وعندما يصبح هذا جزءا من تدفق عملك اليومي
- 16:19تتوقف المواصفات عن كونها خطوة رسمية معقدة وتصبح أقرب إلى أسلوب مختصر وخفيفا
- 16:24أنت تصف نيتك والنظام يضع الأساس
- 16:27وأنت تركز على تشكيل التفاصيل
- 16:29التأثير الأكبر لا يأتي فقط من الكود الذي تنشئه
- 16:32بل مما تعنيه وفرة الوقت أسبوعا بعد أسبوع
- 16:34ساعات أكثر للميزات وجهد أقل في الإعداد
- 16:38هذا يقودنا مباشرة إلى السؤال الذي يهتم به كل مطور أكثر من غيره
- 16:41ما الذي تضيفه هذه التغييرات فعليا من حيث الإنتاجية
- 16:45عائد الإنتاجية
- 16:46السؤال الحقيقي ليس ما إذا كنت ستوفر بضع دقائق هنا وهناك
- 16:50بل كيف تتراكم تلك التحولات الصغيرة لتصبح ساعات ذات قيمة طوال الأسبوع
- 16:54هذا هو عائد الإنتاجية
- 16:56استعادة الوقت الذي يضيع عادة دون ملاحظة بسبب تبديل السياق
- 16:59ودورات البناء المتكررة والتصحيحات اليدوية
- 17:02معظم المطورين يتقبلون تلك الخسائر الصغيرة كجزء طبيع من العمل
- 17:05عشر دقائق هنا للبحث عن قيمة إعداد
- 17:07وخمسة عشر دقيقة أخرى لإعادة التشغيل بعد مرجع مفقود
- 17:09أو التنقل بين الملفات للتحقق من الروابط
- 17:11بحد ذاتها تبدو هذه الأمور بسيطة
- 17:14ولكن عند جمعها خلال دورة عمل كاملة
- 17:15فهي تحدد حجم القيمة الفعلية التي يتم تسليمها
- 17:18ما يبدو كحركة روتينية يخفي عقا حقيقيا أمام جداول التسليم
- 17:22العبء الخفي ليس في أوقات التجميع أو سرعة الكتابة
- 17:25بل في إيقاع التوقف والبدء الذي يفرض على تركيزك
- 17:27في كل مرة تنتقل فيها من ملف إلى آخر
- 17:29يقوم عقلك بإعادة الضبط
- 17:30إعادة الضبط تلك لها تكلفة
- 17:32إسناد التصحيحات المتكررة إلى وكيل ذكي يخفف من ذلك العبء
- 17:36بدلا من إعادة بناء السياق باستمرار
- 17:38يمكنك توجيه تركيزك حيث يهم لحل مشكلة التصميم الكبرى
- 17:42لا تتتبع العديد من الفرق هذه التكاليف الدقيقة
- 17:44العمل الذي لا يؤدي إلى نتيجة لا يتم تسجيله
- 17:48لكنه يستهلك الطاقة رغم ذلك
- 17:50ومع توسع قواعد الكودي لا يزداد هذا الاحتكاك بشكل خطي فحسبه
- 17:53المزيد من الطبقات يعني المزيد من التبعيات التي يجب الاحتفاظ بها في الذاكرة
- 17:56والمزيد من الفرص لضيع الوقت في مجرد موامة الهيكل قبل المضي قدما
- 17:59سير عمل الوكلاء يغير هذه المعادلة من خلال استهداف هذه الهدر مباشرة
- 18:03إنهم لا يقومون فقط بملئ هياكل الدوال بشكل أسرع
- 18:05بل يقللون من حلقات البحث والتصحيح وإعادة التشغيل التي تلتهم فترات بعد الظهيرة
- 18:09تشير الفرق التي تستخدم سير عمل الوكلاء إلى تقليل وقت فك الحضر في كثير من الحالات
- 18:14في هذا الفيديو سنعرض مهمة قبل وبعد حتى تتمكن من الحكم على التأثير
- 18:18سأسجل الوقت المستغرق لتنفيذ نفس ميزة أشر يدويا
- 18:21ثم مرة أخرى باستخدام الوكيل حتى ترى مكاسب الانتاجية بشكل ملموس
- 18:25من منظور تجاري تظهر القيمة في سرعة إنجاز المشروع
- 18:29دورات العمل الأسرع لا تتعلق فقط برضى المطورين
- 18:31فهي تحدد ما إذا كانت الميزات ستصدر في هذا الإصدار أو ستتأخر لأرباع سنوية قادمة
- 18:35كما أنها تؤثر على الدين التقنيي
- 18:36حيث يقل الاعتماد على الخلول المؤقتة والترجعات البرمجية في قائمة المهم
- 18:39يتيح سير العمل الأكثر سلاسة للفرق المضية قدما بوضوح بدلا من إعادة معالجة عمل تلف من سبرينت سابق
- 18:44هذا الاتساق يتراكم ليقلل من العمل تحت الضغط ويحقق نتائج أقوى بمرور الوقت
- 18:48هناك أيضا العامل البشري
- 18:50يوم ضائع في مطاردة الأخطاء يترك أي مهندس منحكنا
- 18:53بمجرد شعورك بالتعب يصبح التصميم النظيف أصعب وتفوتك التفاصيل وتتسلل الأخطاء
- 18:57من خلال نقل الإصلاحات الآلية إلى وكيل ذكاء إصطناعيا
- 19:00يبقى المطورون في حالة تركيز لفترات أطولة
- 19:02هذا التركيز الإضافي يعزز كلا من الإنتاجية والجودة
- 19:05عندما لا تكون مثقلا باحتكاك العمل المتكرر
- 19:08تكون حرا في التفكير بشكل أوسع والتخطيط بفعالية أكبر
- 19:11الفرق في الممارسة يبدو هكذا
- 19:13دالة أشر جديدة مع روابط متعددة وتكامل خدمات قد تستغرق يومين كاملين دون مساعدة
- 19:18بين الإعداد والاختبار والرجوع عن المراجع غير المتطابقة
- 19:22تطول المهمة مع مساعدة الوكيل
- 19:25يمكن إنجاز نفس الدالة في نصف يوم
- 19:27ليس لأننا اختصرنا الطريقة
- 19:28بل لأن الإعداد والتنسيق بين الملفات يتم بشكل صحيح من المرة الأولى
- 19:32يتقلص الجدول الزمني بإزالة البدايات الخاطئة والجهد المتكرر
- 19:35يطرح بعض المطورين مخاوف مشروعة
- 19:38هل الاعتماد على الذكاء الاصطناعي في الصيانة يضعف مهاراتك الخاصة؟
- 19:41هذا المنظور غالبا ما يغفل ما يتغير حقا
- 19:44إسناد الإعداد المتكرر لا يضعف خبرتك
- 19:46بل يحفظها للتصميم والهندسة حيث يصنع حكمك الفارقة
- 19:50في الواقع أن تكسب مساحة لممارسة حل المشكلات المعقدة
- 19:53بدلا من إهدار الطاقة على التصحيحات الروتينية
- 19:55إذا جربت هذا شاركنا في التعليقات بعدد الساعات التي استعدتها في دورة العمل سبريم
- 19:58سأعرض الردود المثيرة للاهتمام في الفيديوهات القادمة
- 20:01سماع كيف تختبر الفرق الأخرى هذا التحول يعطي الجميع صورة أوضح للقيمة الحقيقية
- 20:05بعيدا عن العروض التوضيحية والأمثلة
- 20:06ملاحظة تحذيرية
- 20:08الأتمتة تساعد لكن الأمان يظل مهما
- 20:10قم دائما بتشغيل اختباراتك واستخدم مراجعة الكود للتحقق من التغييرات التي ينشئها الوكيل
- 20:14ثق بأن العمل الروتيني سينخفض ولكن حافظ على نفس معايير الأمان في مكانها
- 20:18فرق السرعة لا يؤتي ثماره إلا إذا ظلت الجودة ثابتة
- 20:21الاختبارات القوية ومراجعة طلبات السحب
- 20:23الذكية تحمي خط إصدار البرمجيات من الأتمتة الهشة
- 20:26الفائدة لا تتعلق بكتابة سطور من الكود بسرعة
- 20:28بل بتوفير مساحة لإنتاج حلول أقوى
- 20:31مع تعب أقل وقليل منه