Developer Experience | The .NET Blog

مراجعة طلبات السحب داخل Visual Studio هي بالضبط نوع تقليل الاحتكاك الذي يعجبني

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. لقراءة الأصل، انقر هنا.

لقد أخذ المتصفح أكثر من اللازم من سير عمل مراجعة الكود لفترة طويلة جدًا.

لذلك أنا سعيد جدًا لرؤية Visual Studio يتقدم أكثر في مراجعة طلبات السحب من البداية إلى النهاية داخل IDE.

هذه من تلك الميزات التي قد لا تصنع عناوين ضخمة، لكنها قادرة تمامًا على تحسين التطوير اليومي.

القيمة الرئيسية بسيطة: تبديل سياق أقل

عندما تعيش حلقة المراجعة جزئيًا داخل IDE وجزئيًا في المتصفح، يتراكم الاحتكاك:

افتح طلب السحب في مكان آخر
افحص التغييرات في أداة واحدة
ارجع إلى الحل لمزيد من التحقيق
انتقل مرة أخرى للتعليق أو الموافقة

الأمر ليس كارثيًا. إنه فقط غير فعّال.

إذا تمكن Visual Studio من أن يتيح لك فتح طلب السحب وفحصه والتعليق عليه والموافقة عليه ودمجه من نفس بيئة العمل، فهذه مكسب إنتاجي حقيقي.

خيار “المراجعة من دون checkout” لطيف بشكل خاص

أحد الأمور التي أحبها بشكل خاص هو إمكانية المراجعة من دون سحب فرع طلب السحب.

قد يبدو ذلك صغيرًا، لكنه مثالي لـ:

جولات مراجعة سريعة
طلبات ملاحظات مرتبطة بمقاطعات العمل
إبقاء الفرع الحالي والحالة المحلية كما هي

هذا بالضبط نوع المرونة التي تحتاجها أدوات مراجعة الكود الجيدة.

وجهة نظري

هذه ليست ميزة ثورية.

إنها شيء أفضل: ميزة عملية.

بالنسبة للفرق التي تقضي معظم يومها في Visual Studio، فإن دعم مراجعة طلبات السحب بشكل أعمق يعني انقطاعات أقل في سير العمل ومسارًا أكثر سلاسة من الفحص إلى الفعل.

هذا تحسين يستحق العناء في رأيي.

المقال الأصلي: مراجعة طلبات السحب من دون مغادرة Visual Studio

أطر تشغيل الوكلاء (Agent Harnesses) مهمة لأن الأوامر النصية وحدها لا تكفي

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

واحد من أسهل الأخطاء في تطوير الوكلاء هو الاعتقاد بأن الأمر النصي (prompt) هو المنتج نفسه.

هذا غير صحيح.

شرح agent harness وclaw الجديد من فريق Microsoft Agent Framework قيّم لأنه يُبقي التركيز على الجزء الذي يحدد فعليًا ما إذا كان الوكيل قابلاً للاستخدام أم لا: الغلاف التشغيلي حول النموذج.

ويشمل ذلك:

الأدوات
التخطيط
حالة الجلسة
الذاكرة
أنماط التنفيذ
وحدة تحكم أو واجهة قابلة للاستخدام للتكرار

هذا هو المكان الذي يتوقف فيه الوكلاء عن كونهم عروضًا توضيحية ذكية ويبدؤون بالشعور وكأنهم برمجيات فعلية.

نمط الـ harness عملي

ما يعجبني هنا هو مدى سهولة الوصول إلى الفكرة.

تبدأ بعميل محادثة (chat client).

ثم تُغلّفه ضمن harness مزوّد بتعليمات وأدوات.

ثم تُشغّله عبر غلاف (shell) يدعم التخطيط، وقوائم المهام، والجلسات، والتفاعل المتدفق.

هذا نمط صحي لأنه يفصل الاهتمامات بوضوح:

النموذج يتعامل مع الاستدلال
الـ harness يتعامل مع السلوك التشغيلي
التطبيق يقرّر أي الأدوات والتجارب مهمة

هذا يتناسب جيدًا جدًا مع طريقة بناء مطوري .NET للأنظمة

فكرة الـ harness تتماشى أيضًا بشكل جيد مع عقلية .NET.

عادةً ما نُبلي بلاءً أفضل عندما يكون السلوك التشغيلي صريحًا وقابلاً للتركيب. البرمجيات الوسيطة (middleware)، وخطوط الأنابيب، والخيارات، والموفّرون، والمهايئات، كل ذلك يبدو طبيعيًا في هذا العالم.

لهذا أعتقد أن Agent Framework لديه فرصة جيدة للانتشار بين مطوري .NET. إنه لا يُجبر الجميع على تجريد سحري واحد. إنه يمنحك قطعًا تشغيلية منظمة يمكنك ربطها معًا.

رأيي

الجزء الأكثر فائدة في هذا المنشور هو التذكير بأن الوكلاء يحتاجون إلى أكثر من نموذج جيد وسلسلة تعليمات ذكية.

إنهم يحتاجون إلى غلاف تشغيلي يمنحهم البنية، والذاكرة، والوصول إلى الأدوات، والتخطيط، وحلقة تطوير عملية.

هذا ما يمنحك إياه الـ harness.

وبصراحة، هذا هو سبب استحقاق هذا النمط للانتباه.

المصدر الأصلي: Meet your agent harness and claw

يُحكم Aspire في VS Code 13.4 حلقة عمل المطور بكل الطرق الصحيحة

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

أفضل تحديثات الأدوات هي تلك التي تشعر بها بعد أيام قليلة من الاستخدام، لا تلك التي تبدو جيدة فقط في ملاحظات الإصدار.

هذا ما يبدو عليه Aspire في VS Code 13.4 بالنسبة لي.

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

هذا اتجاه جيد جدًا.

الفوز الكبير هو تقليل التنقل بين السياقات

إذا كنت تستخدم Aspire بجدية، فأنت عادةً تتنقل عبر عدة أسطح:

كود AppHost
الطرفية
لوحة التحكم
السجلات
جلسات التصحيح
نقاط نهاية الخدمة

ما يفعله 13.4 بشكل جيد هو تقليل الاحتكاك بين هذه الأسطح.

تجعل تجربة VS Code الجديدة المزيد من حالة التطبيق مرئية بالضبط حيث تعمل بالفعل:

صحة الموارد في المحرر
أوامر بجانب إعلانات الموارد
وصول أسهل إلى لوحة التحكم
وصول إلى السجلات من سياق AppHost
لوحة تبقى مفيدة حتى قبل بدء التصحيح الكامل

يبدو هذا صغيرًا حتى تفعله كل يوم.

تصحيح المكدّسات المختلطة أهم مما يظن الناس

أحد أقوى أجزاء هذا التحديث هو القصة الأكثر طبيعية لتصحيح C#، وTypeScript، وPython، وGo، وتطبيقات المتصفح، وAzure Functions في تدفق واحد مدفوع بـ Aspire.

هذا يعكس الشكل الحقيقي للتطبيقات الحديثة بشكل أفضل بكثير من التظاهر بأن كل شيء يعيش في وقت تشغيل واحد.

بالنسبة لمطوري .NET بشكل خاص، هذا قيّم لأن كثيرًا منا يبني الآن أنظمة تمزج مشاريع API، والواجهات الأمامية، والعمّال (workers)، والخدمات ذات الصلة بالذكاء الاصطناعي بلغات مختلفة.

كون Aspire يجعل هذا يبدو أكثر توحيدًا داخل VS Code هو تحسين عملي جدًا.

وصول دعم TypeScript AppHost إلى الإتاحة العامة مهم أيضًا

لن أتجاهل جانب TypeScript AppHost من هذا الإصدار.

أصبح Aspire أكثر طبيعية لكل من C# وTypeScript، وهذا يُوسّع دائرة من يمكنه العمل ضمن نموذج النظام نفسه دون سير عمل غريب من الدرجة الثانية. هذا مهم للفرق التي يعيش فيها كود المنصة، وكود الواجهة الأمامية، وتنسيق الخدمات بالقرب من بعضهم البعض.

رأيي

Aspire 13.4 في VS Code لا يتعلق بميزة واحدة قاتلة. إنه يتعلق بتنعيم الحواف الخشنة في الحلقة اليومية:

ابدأ بشكل أسرع
شاهد المزيد من الحالة حيث تكتب الكود
صحّح بشكل أكثر طبيعية
انتقل إلى السجلات ولوحة التحكم فقط عند الحاجة

هذا بالضبط كيف يجب أن تتطور الأدوات الجيدة.

إذا كنت تستخدم Aspire بالفعل، يبدو هذا التحديث يستحق التثبيت. أما إذا كنت لا تزال تتساءل عمّا إذا كان VS Code موطنًا جادًا للتطوير القائم على Aspire، فالإجابة تصبح أكثر وضوحًا يومًا بعد يوم.

المصدر الأصلي: Aspire in VS Code: the 13.4 developer loop

وكيل Plan الجديد في Visual Studio يحل مشكلة حقيقية جدًا في سير عمل الذكاء الاصطناعي

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. لقراءة الأصل، انقر هنا.

من أكثر سير العمل المزعجة في كتابة الكود بالذكاء الاصطناعي أن يبدأ التنفيذ بسرعة زائدة.

قد يكون الكود صحيحًا تقنيًا تمامًا، لكنه يحل النسخة الخاطئة من المشكلة التي كنت تقصدها.

كنت تريد إعادة هيكلة، فبدأ إعادة كتابة. كنت تريد تحسينًا محدود النطاق، فلامس نصف المشروع. كنت تريد مناقشة الخيارات، فانتقل مباشرة إلى تغييرات الملفات.

لهذا السبب يعد وكيل Plan الجديد في Visual Studio إضافة مفيدة جدًا.

هذا يحل مشكلة حقيقية في سير العمل، لا مجرد مشكلة شكلية

يصف المنشور الأصلي حالة مألوفة جدًا: “الكود ليس خاطئًا… لكنه ليس ما كنت تريده.”

هذه العبارة ممتازة.

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

ويصبح هذا مهمًا جدًا في الحالات التالية:

الميزات الكبيرة
قواعد الشيفرة غير المألوفة
عمليات إعادة الهيكلة غير البسيطة
التغييرات الحساسة على البنية
العمل الذي يحتاج مراجعة الفريق قبل بدء التعديلات

في مثل هذه الحالات، فإن القفز مباشرة إلى التنفيذ غالبًا ما يكون الخطأ.

التخطيط ليس عبئًا عندما تكون المهمة حقيقية

أعتقد أن الفرق تقلل أحيانًا من مقدار الوقت الذي تخسره عندما تبدأ التنفيذ مبكرًا جدًا.

إذا قام الوكيل بما يلي:

لمس الملفات الخطأ
اختيار النهج الخطأ
تجاهل قيد مهم
إغفال حالة حافة مطلوبة

فإن البداية “السريعة” تتحول إلى سير عمل أبطأ في المحصلة.

لهذا السبب يعجبني هذا الخيار.

إنه يفسح المجال لـ:

أسئلة توضيحية
صياغة خطة
تعديل الخطة مباشرة
مشاركة الخطة قبل أن تبدأ تغييرات الكود

هذا ليس بيروقراطية. إنه غالبًا مجرد هندسة جيدة.

ملف الخطة Markdown خيار ذكي

أحد التفاصيل التي أعجبتني خصوصًا هو أن كل خطة تُحفظ في .copilot/plans/plan-{title}.md.

هذا يجعل خطوة التخطيط ملموسة.

يعني أن الخطة ليست محبوسة داخل سجل محادثة. بل تصبح شيئًا يمكنك:

مراجعته
تعديله
نسخه ذهنيًا
مناقشته مع زملائك
تسليمه إلى التنفيذ بشكل أكثر قصدًا

هذا يجعل الميزة تبدو أكثر جدية بكثير من مجرد مقدمة مؤقتة قبل توليد الكود.

هنا تبدأ سير عمل الذكاء الاصطناعي في احترام عملية الفريق

أعتقد أن هذا من أقوى المؤشرات على نضج هذه الأدوات.

أفضل سير عمل للمطور مع الذكاء الاصطناعي ليس الذي يزيل كل الخطوات الوسيطة. بل الذي يحسن الخطوات الوسيطة الصحيحة.

والتخطيط واحدة من تلك الخطوات.

إذا كانت الخطة قوية، يصبح التنفيذ أسهل. إذا كانت الخطة ضعيفة، يصبح التنفيذ صاخبًا ومربكًا.

هذه الميزة تعترف بذلك مباشرة.

وجهة نظري

هذا ليس مجرد لطف من الذكاء الاصطناعي.

إنه تحسين في سير العمل.

وفي الميزات الحقيقية وعمليات إعادة الهيكلة الحقيقية، فهو بالضبط نوع التحسين الذي يمكن أن يوفر الكثير من التبديل غير الضروري، وضجيج المراجعة، وإعادة العمل من نوع “هذا ليس ما قصدته”.

أعتقد أن المزيد من تجارب الوكلاء ستحتاج في النهاية إلى شيء كهذا.

Visual Studio وصل إلى ذلك مبكرًا بطريقة تبدو مفيدة.

المقال الأصلي: التخطيط قبل البناء: تقديم وكيل Plan في Visual Studio

حلقة التطوير لديك مليئة بالمعرفة القبلية - وAspire يقدّم الرد الصحيح

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

تمت ترجمة هذه المقالة تلقائيًا. لقراءة الأصل، انقر هنا.

قد تكون هذه واحدة من أهم المقالات عن Aspire لفهم لماذا يهم هذا المنتج.

ليس لأنه يعلن عن ميزة جديدة ضخمة.

بل لأنه يسمّي مشكلة شعرت بها تقريبًا كل فرق الهندسة، وليس كل الفرق وصفتها جيدًا:

حلقة التطوير مليئة بالمعرفة القبلية.

هذه العبارة تصيب الهدف لأنها صحيحة.

المشكلة ليست نقص الأدوات

الحجة الأساسية في المقال الأصلي ممتازة: كثير من الفرق لا تفتقر إلى البنية التحتية أو البرامج النصية أو لوحات المعلومات أو الأوامر.

ما تفتقر إليه هو نموذج متماسك يحوّل كل المعرفة التشغيلية المخفية حول التطبيق إلى شيء مرئي وقابل للتكرار.

الهيكل الحقيقي لكثير من التطبيقات يعيش في:

سجل أوامر shell
برامج نصية متناثرة
أجزاء من ملفات README
محادثات Slack
ذلك المهندس الكبير الوحيد الذي يعرف ترتيب العمليات

هذه ليست حلقة تطوير مستدامة للبشر.

وهي بالتأكيد ليست واحدة للوكلاء.

الاقتباس الذي أرى أنه يلخّص المنشور كله

هناك جملة واحدة في المقال الأصلي أعتقد أنها تلتقط الفكرة الأوسع بشكل ممتاز:

“التطبيقات موجودة بالفعل كنظم. يجعل Aspire هذه النظم صريحة، لأن النظم الصريحة تتوسع أفضل من المعرفة القبلية.”

هذا هو جوهر الحجة في سطر واحد.

وبصراحة، إنها واحدة من أقوى العبارات المختصرة عن Aspire التي رأيتها حتى الآن.

لماذا يهم هذا الآن أكثر من قبل عام

أعتقد أن هذه المقالة تصيب الهدف بشكل خاص في اللحظة الحالية لأن التطوير المدعوم بالذكاء الاصطناعي يغيّر كلفة الغموض.

يمكن للبشر تعويض الأنظمة غير المكتملة بشكل مدهش.

نتذكر:

أي برنامج نصي نشغّله أولاً
أي متغير بيئة مطلوب سرًا
أي طرفية تعرض السجلات المفيدة عادةً
أي خدمة تحتاج إلى إعادة تشغيل مرتين لأسباب لم يوثقها أحد

الوكلاء أضعف بكثير في هذا النوع من الفولكلور التشغيلي المخفي.

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

لهذا أعتقد أن إطار Aspire مهم.

القيمة الحقيقية لـ Aspire ليست فقط التنسيق

خطأ شائع هو النظر إلى Aspire فقط كأداة تشغيل تطبيقات موزعة أو أداة مساعدة للتنسيق المحلي.

هذا إطار صغير جدًا.

القيمة الأقوى هي أن Aspire يمنح التطبيق:

نموذجًا
شكلاً
موارد مسماة
تبعيات صريحة
أسطحًا للصحة والعمليات
أوامر يمكن للبشر والأتمتة فهمها

هذا يغيّر حلقة التطوير أكثر مما يدركه الناس أحيانًا.

لأنه بمجرد أن يتوقف التطبيق عن كونه كومة من الاتفاقيات الضمنية ويبدأ في أن يكون نظامًا بنموذج حقيقي، تصبح عدة أشياء أسهل في الوقت نفسه:

onboarding
debugging
إعداد يمكن تكراره
اتساق CI
سير العمل المدعوم بالذكاء الاصطناعي

هذا قدر كبير من الرافعة من خيار تصميم واحد.

أحب بشكل خاص زاوية “الأوامر كعمليات من الدرجة الأولى”

نقطة أخرى من المقال الأصلي أعتقد أنها تستحق مزيدًا من الاهتمام هي الانتقال من تعليمات README إلى أوامر مرتبطة بالموارد.

هذا تغيير كبير بشكل مخادع.

بدلاً من القول:

شغّل هذا البرنامج النصي، ثم ذاك، ثم ربما هذا الآخر إذا فشل الأول

يمكنك نمذجة العمليات مباشرة داخل سياق التطبيق.

هذا يعني أن البشر يمكنهم اكتشافها بسهولة أكبر.

ويعني أن الوكلاء لا يحتاجون إلى تخمين النية من النص.

هذا هو النوع من الأشياء الذي يحول التطبيق من “يمكن تشغيله إذا كنت تعرفه بالفعل” إلى “قابل للتشغيل عن قصد”.

ما الذي سأستخلصه من هذا كقائد فريق

لو كنت أراجع حلقة التطوير الخاصة بفريقي من هذا المنظور، فسأطرح أسئلة مباشرة:

إلى أي مدى يعتمد إعدادنا على الذاكرة؟
كم من الإجراءات التطويرية الحرجة تعيش فقط في الوثائق أو محادثات الدردشة؟
كم مرة يتعثر القادمون الجدد بسبب سلوك نظام غير مرئي؟
هل يمكن لأداة أتمتة أو وكيل برمجي أن يفهم طوبولوجيا تطبيقنا من المستودع نفسه؟

إذا كانت الإجابة عن السؤال الأخير هي “ليس قريبًا حتى”، فيجب أن تلامس هذه المقالة وترًا مهمًا بشكل مفيد.

وجهة نظري

هذا إطار قوي جدًا للقيمة الحقيقية لـ Aspire.

ليس مجرد orchestration.

إنه يتعلق بجعل نموذج التطبيق صريحًا بما يكفي ليصبح النظام أسهل في التشغيل والفهم والأتمتة.

هذا مهم للبشر. وهو مهم للفرق. وهو مهم أكثر الآن لأن الكثير من التطوير الحديث يتحرك نحو سير عمل مدعوم بالوكلاء.

هذا بالضبط نوع المقالة الذي يساعد على تفسير لماذا يبدو Aspire أكثر أهمية خارج مجرد علامة .NET التجارية.

المقال الأصلي: حلقة التطوير لديك مليئة بالمعرفة القبلية— title: “حلقة التطوير لديك مليئة بالمعرفة الضمنية، وAspire لديه الرد المناسب” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “يطرح منشور جديد عن Aspire نقطة قوية: كثير من الفرق لا ينقصها الأدوات، بل ينقصها نموذج تطبيق متسق يحول المعرفة التشغيلية الخفية إلى شيء يستطيع البشر والسكربتات والوكلاء استخدامه فعليًا.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

تمت ترجمة هذه المقالة تلقائيًا. لقراءة الأصل، انقر هنا.

قد تكون هذه من أهم المقالات عن Aspire لفهم لماذا هذه الأداة مهمة.

ليس لأنها تعلن عن ميزة جديدة ضخمة.

بل لأنها تسمي مشكلة يشعر بها تقريبًا كل فريق هندسي، لكن ليس كل فريق يصفها جيدًا:

حلقة التطوير مليئة بالمعرفة الضمنية.

هذه العبارة تلامس الواقع لأنها صحيحة.

المشكلة ليست نقص الأدوات

الحجة الأساسية في المقال الأصلي ممتازة: الفرق غالبًا لا ينقصها البنية التحتية أو السكربتات أو لوحات المعلومات أو الأوامر.

الذي ينقصها هو نموذج متماسك يحول كل المعرفة التشغيلية الخفية حول التطبيق إلى شيء مرئي وقابل للتكرار.

البنية الحقيقية لكثير من التطبيقات تعيش في:

سجل الأوامر في shell
سكربتات متفرقة
مقاطع متناثرة من README
سلاسل Slack
ذلك المهندس الكبير الوحيد الذي يعرف ترتيب العمليات

هذا ليس حلقة تطوير مستدامة للبشر.

وبالتأكيد ليس كذلك بالنسبة للوكلاء.

الاقتباس الذي أعتقد أنه يلخص المنشور بالكامل

هناك جملة واحدة في المقال الأصلي أعتقد أنها تلخص الفكرة الأوسع بشكل ممتاز:

“التطبيقات موجودة بالفعل كنظم. يجعل Aspire تلك النظم صريحة، لأن النظم الصريحة تتوسع أفضل من المعرفة الضمنية.”

هذه هي الحجة كاملة في سطر واحد.

وبصراحة، إنها من أقوى التفسيرات المختصرة لـ Aspire التي رأيتها حتى الآن.

لماذا يهم هذا الآن أكثر من قبل عام

أعتقد أن هذه المقالة تصيب الهدف بشكل خاص في اللحظة الحالية لأن التطوير المدعوم بالذكاء الاصطناعي يغيّر تكلفة الغموض.

البشر يستطيعون تعويض الأنظمة غير المكتملة بشكل مدهش.

نتذكر:

أي سكربت يجب تشغيله أولًا
أي متغير بيئة مطلوب سرًا
أي طرفية تعرض السجلات المفيدة عادةً
أي خدمة يجب إعادة تشغيلها مرتين لأسباب لم يوثقها أحد

الوكلاء أسوأ بكثير في هذا النوع من المعرفة التشغيلية غير الموثقة.

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

لهذا السبب أعتقد أن إطار Aspire مهم.

قيمة Aspire الحقيقية ليست فقط orchestration

من الأخطاء الشائعة مع Aspire اعتباره مجرد مشغل تطبيقات موزعة أو مساعد orchestration محلي.

هذا إطار صغير جدًا.

القيمة الأقوى هي أن Aspire يمنح التطبيق:

نموذجًا
شكلاً
موارد مسماة
تبعيات صريحة
واجهات للصحة والعمليات
أوامر يستطيع البشر والأتمتة فهمها معًا

هذا يغيّر حلقة التطوير أكثر مما يدركه الناس أحيانًا.

لأنه عندما يتوقف التطبيق عن كونه كومة من الاتفاقيات الضمنية ويصبح نظامًا ذا نموذج حقيقي، تصبح عدة أمور أسهل دفعة واحدة:

onboarding
debugging
الإعداد القابل للتكرار
اتساق CI
سير العمل المدعوم بالذكاء الاصطناعي

هذا كثير من النفوذ من خيار تصميم واحد.

أحب بشكل خاص زاوية “الأوامر كعمليات من الدرجة الأولى”

نقطة أخرى في المقال الأصلي أعتقد أنها تستحق مزيدًا من الانتباه هي الانتقال من تعليمات README إلى أوامر مرتبطة بالموارد.

هذا تغيير كبير بطريقة مخادعة.

بدلًا من القول:

شغّل هذا السكربت، ثم ذاك، ثم ربما هذا الآخر إذا فشل الأول

يمكنك نمذجة العمليات مباشرة داخل سياق التطبيق.

هذا يعني أن البشر يستطيعون اكتشافها بسهولة أكبر.

ويعني أن الوكلاء لا يحتاجون إلى تخمين النية من النثر.

هذا هو النوع من الأشياء التي يحوّل التطبيق من “قابل للتشغيل إذا كنت تعرفه مسبقًا” إلى “قابل للتشغيل بالتصميم”.

ماذا كنت سأستخلص من هذا بصفتي قائد فريق

إذا كنت أنظر إلى حلقة التطوير في فريقي من خلال هذه العدسة، فسأطرح بعض الأسئلة المباشرة:

كم يعتمد إعدادنا على الذاكرة؟
كم عدد إجراءات التطوير المهمة التي توجد فقط في الوثائق أو سلاسل الدردشة؟
كم مرة يتعطل القادمون الجدد بسبب سلوك نظام غير مرئي؟
هل يستطيع أداة أتمتة أو وكيل برمجة فهم طوبولوجيا التطبيق من المستودع نفسه؟

إذا كانت الإجابة عن السؤال الأخير هي “ليس حتى قريبًا”، فهذه المقالة يجب أن تلامس عصبًا مهمًا بطريقة مفيدة.

وجهة نظري

هذا إطار قوي جدًا لقيمة Aspire الحقيقية.

إنه ليس مجرد orchestration.

إنه يتعلق بجعل نموذج التطبيق صريحًا بما يكفي حتى يصبح النظام أسهل في التشغيل والفهم والأتمتة.

هذا مهم للبشر. وهو مهم للفرق. وهو أهم الآن مع انتقال الكثير من التطوير الحديث نحو سير عمل مدعوم بالوكلاء.

هذه بالضبط من نوع المقالات التي تشرح لماذا يبدو Aspire أكثر صلة الآن، وليس فقط كعلامة تسويقية لـ .NET.

المقال الأصلي: حلقة التطوير لديك مليئة بالمعرفة الضمنية

اختبارات Aspire الشاملة المعزولة هي النمط الذي ينبغي على مزيد من الفرق أن يتبنّاه

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

تُرجِمت هذه المقالة تلقائيًا. للاطلاع على النسخة الأصلية بالإنجليزية، انقر هنا.

الاختبارات الشاملة الهشّة مكلفة بطريقة لا تظهر دائمًا على لوحة القياسات.

هي لا تفشل فقط. بل تُدرّب الفريق ببطء على التوقف عن الثقة بحلقة التغذية الراجعة.

ولهذا فإن هذا الشرح الخاص بـ Azure Chaos Studio + Aspire جذبني فورًا. إنه ليس إعلانًا استعراضيًا عن منتج. بل قصة هندسية متينة عن كيفية جعل الاختبار الشامل يتوقف عن الشعور وكأنه مساومة مع الحظ.

وبصراحة؟ أعتقد أن على مزيد من الفرق أن ينسخوا هذا النمط.

الفكرة الأساسية بسيطة، لكن العائد كبير جدًا

الحركة الأساسية هنا هي منح كل اختبار بيئته الخاصة المعزولة المؤقتة، مع خدمات حقيقية، وتبعيات حقيقية، وإقلاع صريح قائم على الجاهزية.

يبدو ذلك بديهيًا عندما تقرأه في جملة واحدة. لكنه أصعب بكثير في الأنظمة الحقيقية، خصوصًا عندما تدخل التبعيات السحابية والبيئات المشتركة والخدمات الموزعة في الصورة.

يشرح المقال الأصلي المشكلة بوضوح شديد: البيئات الاختبارية المشتركة تجلب معها “التداخل المتبادل، والهشاشة، ورسائل الدردشة الجماعية من نوع من الذي كسر staging؟” باعتبارها ثمن العمل.

هذه العبارة مضحكة لأنها مؤلمة للغاية.

يتقبل عدد كبير من الفرق هذه المقايضة على أنها أمر طبيعي. أنا لا أعتقد أنه ينبغي عليهم ذلك.

لماذا يهم هذا النمط أبعد من الاختبار

أكثر ما يعجبني هنا أن المقال لا يقول فقط: “جعلنا الاختبارات أكثر اعتمادية”.

إنه في الحقيقة يقول شيئًا أكبر:

إذا كان من الصعب إعادة إنتاج نظامك الموزع، وعزله، والتحقق منه، فإن حلقة الهندسة بأكملها ستتباطأ.

وهذا لا يؤثر على CI فقط.

بل يؤثر على:

مدى ثقة المطورين في إعادة الهيكلة
سرعة تشخيص الانحدارات
مدى أمان إجراء تغييرات معمارية أكبر
مقدار الثقة التي يضعها الفريق في التحقق الآلي

وفي 2026، يؤثر أيضًا على مدى فائدة التطوير بمساعدة الذكاء الاصطناعي.

أهم اقتباس في المنشور

هناك سطر واحد في المقال أعتقد أنه يستحق أن يُعاد ذكره:

“لا يجب أن يكون الوكلاء مثاليين. يجب أن يكونوا قابلين للتحقق.”

هذا تأطير ممتاز جدًا.

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

إذا اقترح وكيل إعادة هيكلة ذات معنى، وكانت إشارة الأمان الوحيدة لديك عبارة عن مجموعة اختبارات شاملة هشة وشبه عشوائية تعمل فوق بيئة مشتركة، فالمشكلة ليست في الوكيل وحده.

المشكلة في نموذج التحقق لديك.

هذا النمط في Aspire يحسّن ذلك بشكل كبير.

ما الذي يجعل هذا التطبيق جيدًا على نحو خاص

هناك عدة أجزاء في القصة الأصلية تجعلها أكثر من مجرد منشور فضفاض من نوع “حسّنا الاختبارات”.

1. مخطط خدمات حقيقي، لا مسرحيات زائفة

الاختبارات لا تُبنى حول كومة من الـ mocks المفصولة التي تتظاهر بأنها تحقق شامل.

بل تشغّل الثنائيات الحقيقية، وتربط المحاكيات حيثما أمكن، وتستخدم نموذج التطبيق نفسه المستخدم في التطوير المحلي.

وهذا مهم.

لأنه عندما تتحول الاختبارات الشاملة إلى مسرحية mock-against-mock، فإنها تتوقف عن إخبارك بأي شيء موثوق عن التركيب الحقيقي.

2. إقلاع قائم على الجاهزية بدل النوم السحري

هذا الجزء أكبر مما يبدو.

يشير المقال بوضوح إلى أن الاختبارات تنتظر الجاهزية الفعلية باستخدام WaitForResourceHealthyAsync، بدل الاعتماد على تخمينات زمنية عشوائية.

هذا فرق هائل.

مجموعة اختبارات تقول “انتظر 30 ثانية وتمنَّ الأفضل” هي عمليًا توثّق عدم اليقين. أما المجموعة التي تنتظر الجاهزية الحقيقية فهي توثق نية النظام.

3. النموذج نفسه يقود التطوير المحلي والاختبار

أعجبني هذا كثيرًا لأنه ينسجم مع أقوى قصص Aspire عمومًا.

نموذج التطبيق نفسه يقود:

التطوير المحلي
ربط الخدمات
المحاكيات للتبعيات
فحوصات الجاهزية
تنسيق الاختبارات المعزولة المؤقتة

هذا يقلل الانحراف، والانحراف من أكثر القتلة الخفيين للثقة.

هذا النوع من الاستثمار في تجربة المطورين يُستهان به

أحد أسباب رغبتي في أن يكون هذا المنشور أطول من مجرد انطباع سريع هو أنني أعتقد أن هذه التحسينات الهندسية غالبًا ما يُستهان بها.

هي ليست براقة.

لا تُعرض بسهولة مثل ميزة جديدة في الذكاء الاصطناعي.

ولا تنتج دائمًا شريحة واحدة تثير حماس المديرين التنفيذيين.

لكنها تخلق مع الوقت شيئًا أثمن بكثير: فريقًا يستطيع التحرك بسرعة أكبر من دون أن يكذب على نفسه بشأن الجودة.

هذا أمر مهم جدًا.

يذكر المقال أنهم يشغّلون الآن نحو 90 اختبارًا معزولًا مؤقتًا، بما في ذلك سيناريوهات مثل تعطل المناطق، وفشل DNS، وفشل النسخ المتماثل الجغرافي. هذا ليس مجرد تحسن في نظافة الاختبار. هذا نموذج ثقة أقوى بكثير لمنصة موزعة.

ما الذي سأستخلصه من هذا لو كنت أعمل على نظام .NET موزع

إذا كنت تعمل اليوم مع الخدمات الموزعة وAspire وخطوط CI/CD، فإليك ما سأستخلصه فورًا من هذا:

توقف عن تطبيع الهشاشة في البيئات المشتركة
انتقل إلى بوابات بدء قائمة على الجاهزية كلما أمكن
تعامل مع AppHost بوصفه شيفرة تنسيق حقيقية على مستوى الإنتاج
ابنِ فحوصات شاملة تتحقق من تركيب الخدمات، لا من صحة كل خدمة على حدة فقط
إذا كنت تتبنى التطوير بمساعدة الذكاء الاصطناعي، فاستثمر في قابلية التحقق قبل أن تطارد اتساع الأتمتة

هذه النقطة الأخيرة هي التي أعتقد أن على مزيد من الفرق سماعها.

وجهة نظري

هذا أحد أقوى منشورات Aspire في هذه المجموعة لأنه يحل مشكلة عملية للغاية.

إنه لا يحاول إبهارك بالتجريد. بل يوضح كيف تجعل الاختبارات الشاملة أكثر تحديدًا، وأكثر فائدة، وأكثر موثوقية في نظام موزع حقيقي.

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

إذا كانت قصة الاختبارات الشاملة لديك لا تزال تعتمد على بيئات مشتركة، ومعرفة إعدادات مخفية، وقليل من الدعاء، فهذا يستحق الدراسة بجدية.

المقال الأصلي: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests