ثورة أداء .NET 10 LTS: 7 أشياء يجب أن يعرفها كل مهندس قبل الترحيل

أعمل مع .NET منذ أكثر من عشر سنوات. خلال هذه المدة أدرت ثلاث عمليات ترحيل LTS: من .NET Core 3.1 إلى 6، ومن 6 إلى 8، والآن من 8 إلى 10. كل عملية جاءت مصحوبة بأشهر من اجتماعات التخطيط وتدقيق التبعيات ونوافذ الطرح التدريجي. قرار «LTS» يبدو صغيراً في البداية، إذ يُختزل لدى كثيرين إلى مجرد تغيير رقم إصدار. غير أنّك بمجرد الالتزام به، ستحمل تلك الأنظمة لمدة ثلاث سنوات كاملة.

في 10 مارس 2026، صدر .NET 10 كإصدار LTS: أكثر من 300 ميزة جديدة، وأكثر من 5,000 إصلاح للأخطاء، وتكامل Visual Studio 2026، ودعم Microsoft حتى عام 2028. في هذا المقال أتناول الأشياء السبعة التي تهم فعلاً قبل ترحيل أنظمة الإنتاج: ليست قائمة جافة بالمميزات، بل ما لاحظته من تشغيل هذه الترحيلات عملياً، وما الذي تغيّر حقاً هذه المرة.

‎1. ماذا يعني وضع LTS لفريقك؟

دورة إصدارات .NET تهم أكثر مما يدرك الناس. الإصدارات ذات الأرقام الزوجية (6، 8، 10) هي LTS: ثلاث سنوات من الدعم. أمّا الإصدارات ذات الأرقام الفردية (7، 9) فهي STS (الدعم القياسي المحدود)، بمدّة 18 شهراً فقط. تنتهي دورة حياة .NET 9 في مايو 2026، فيما ينتهي دعم .NET 8 في نوفمبر 2026.

بالنسبة للأنظمة المؤسسية، الحساب واضح: الترحيل إلى .NET 9 ومواجهة ترحيل آخر خلال 18 شهراً، أم القفز مباشرة إلى .NET 10 LTS والبقاء مستقراً حتى 2028؟ معظم الفرق يجب أن تختار الأخير. غير أنّ توقيت القرار يهم كثيراً؛ فنهاية دعم .NET 8 في نوفمبر 2026 تعني أنك بحاجة إلى خطة ترحيل جاهزة الآن، لا في أكتوبر 2026 حين يتسابق الجميع.

‎2. تحسينات GC: لماذا إدارة الذاكرة مختلفة؟

50 ميلي ثانية من توقف GC على خدمة تعالج 10,000 طلب في الثانية تتحوّل مباشرة إلى مئات من انتهاءات المهلة المتزامنة. هذه ليست أرقاماً نظرية، بل واقع زمن استجابة P99 في أيّ خدمة عالية الإنتاجية. ومع ذلك يتجاوز معظم المطورين ملاحظات إصدار GC تحت تفكير «إنه يعمل بالفعل»، فيما تجلب .NET 10 تغييرين يستحقان قراءة متأنية.

التغيير الأول هو توسيع نطاق Dynamic PGO (التحسين الموجَّه بالملف الشخصي). قُدِّم هذا المُحسِّن أصلاً في .NET 8، حيث يتعلم في وقت التشغيل مسارات الكود الأكثر استخداماً ويضبط تجميع JIT وفقاً لذلك. في .NET 10 ينطبق التحسين على قاعدة كود أوسع، ويقلّ معه زمن الإحماء. التغيير الثاني يخصّ وضع Server GC؛ إذ صار يتصرّف بقابلية أعلى للتنبؤ تحت ضغط الذاكرة، مع تحسينات خوارزمية تُقلّ تجزؤ Large Object Heap في الخدمات طويلة الأمد.

كيف تقيّم ذلك؟ اجمع مقاييس GC باستخدام dotnet-counters monitor على خدمتك الحالية. بعد الترحيل إلى .NET 10، شغّل القياسات ذاتها تحت حمل مكافئ وقارن النتائج. إذا كان زمن استجابة P99 لديك مدفوعاً بـ GC اليوم، فمن المرجح أن .NET 10 سيحرّك هذا الرقم بصورة ملموسة.

‎3. ‎C# 14: الميزات الأربع التي تغيّر الكود اليومي

ما الميزات الأربع في C# 14 التي ستظهر فعلاً في كودك خلال أسابيع من اعتماد .NET 10؟ يجلب الإصدار الجديد الكثير من الإضافات، ومحاولة تعلّمها جميعاً دفعة واحدة أمر مرهق وغير مثمر. لذا أرى أنّ التركيز على أربع ميزات بعينها هو الطريق الأقصر لقيمة فعلية على لوحة المفاتيح.

الكلمة المفتاحية field (الخصائص شبه التلقائية): لسنوات، كانت إضافة أيّ منطق مخصص لخاصية ما تعني كتابة حقل دعم منفصل وتعريف خاصية كامل؛ كليشيه غير ضروري للحالات البسيطة. تتيح الكلمة المفتاحية field في C# 14 استخدام حقل الدعم المُولَّد من قِبَل المترجم مباشرة داخل موصّلات الخاصية، مثل: get => field.ToUpper();، دون الحاجة إلى تعريف حقل منفصل.

أعضاء الامتداد: توابع الامتداد كانت موجودة في C# منذ سنوات. يضيف C# 14 خصائص الامتداد والتوابع الثابتة للامتداد، فإثراء الأنواع الموجودة دون تعديلها أصبح أكثر طبيعية الآن، إذ يمكن إضافة خصائص النطاق مثل Order.IsOverdue خارجياً دون لمس تعريف النوع.

‎params Span<T> وReadOnlySpan<T>: يعمل params الآن مع spans، لا مع المصفوفات وحدها. هذا يُلغي تخصيصات الكومة في التوابع التي تُستدعى بشكل متكرر، مما ينتج تحسينات أداء قابلة للقياس في مسارات الكود عالية التردد.

‎Spans من الدرجة الأولى: يعمل Span<T> وReadOnlySpan<T> بصورة أكثر طبيعية في قيود النوع العام وبنى اللغة الأخرى، حتى كتابة كود عالي الأداء منخفض التخصيص باتت تتطلب بنية جملة أقل إرهاقاً.

‎4. ‎ASP.NET Core 10: الـ Minimal API نضجت أخيراً

وصلت Minimal API في .NET 6. كل إصدار منذ ذلك الحين أغلق فجوة. في .NET 10، يمكن القول بثقة إنّها نضجت فعلاً.

التغيير الرئيسي هو توليد وثائق OpenAPI المدمج. حزمة Microsoft.AspNetCore.OpenApi التي ظهرت في .NET 9 أصبحت مستقرة وجاهزة للإنتاج في .NET 10. لا حاجة لاعتماد Swashbuckle؛ إذ يعمل توليد وثائق متوافقة مع OpenAPI 1.0 من خلال الإعدادات الافتراضية. هذا التوليد المدمج يقلّ من التبعيات، ويحرّرك من تأخيرات تحديث Swashbuckle.

التغيير الثاني يخصّ معالجات lambda الثابتة. في Minimal API، باتت معالجات نقطة النهاية المعرَّفة كمراجع توابع ثابتة تُحسَّن في وقت التجميع. تُلغى تخصيصات الإغلاق، ويقلّ معها ضغط الذاكرة في نقاط النهاية عالية الزيارات.

التغيير الثالث هو التوافق الكامل مع Native AOT. يمكن تجميع ونشر خدمات ASP.NET Core 10 باستخدام Native AOT، فينخفض وقت البدء البارد بصورة كبيرة: من ثوانٍ إلى ميلي ثوانٍ في سيناريوهات serverless وحاويات sidecar. ومن ثمّ تنعكس هذه المكاسب مباشرة على تكاليف أقل، وتجربة مستخدم أفضل للفرق التي تعمل على أحمال عمل تلقائية التوسع.

‎5. ‎MAUI 10: أين يقف Cross-Platform الآن؟

لـ MAUI تاريخ معقد. استقطبت الإصدارات الأولى انتقادات بسبب مشاكل الأداء وعدم استقرار الأدوات وأخطاء إعادة التحميل السريع. جلب .NET 8 تحسينات جوهرية. القصة مختلفة تماماً مع .NET 10.

أهم تطوير: دعم Native AOT. تشهد تطبيقات MAUI المُجمَّعة بـ Native AOT انخفاضاً ملحوظاً في حجم التطبيق وفي وقت بدء تشغيله. وعلى المنصات المحمولة يبدو هذا الأثر واضحاً بشكل خاص؛ إذ يمكن تقليص أوقات بدء تشغيل iOS وAndroid إلى النصف تقريباً مقارنة بوقت البدء المُفسَّر للـ .NET runtime.

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

مع ذلك، تتطلب الأمانة هذا التحفظ: MAUI لا تزال لا تمتلك نضج نظام بيئي مثل React Native أو Flutter. إذا كنت تبدأ مشروع موبايل cross-platform جديداً، وكان لفريقك خبرة .NET/C# قوية، فـ MAUI 10 خيار جدي. غير أنّك إن كانت لديك خبرة عميقة في Flutter أو React Native، فقد يظل ذلك الخيار الأفضل.

‎6. خمسة أشياء يجب فعلها قبل الذهاب إلى الإنتاج

في 2021، عاشت ثلاث خدمات إنتاج لديّ ترحيلاً متسرّعاً من .NET Core 3.1 إلى .NET 6 خلال أسبوع واحد. ما اكتشفناه بعد الترحيل ظلّ يُلاحقنا أكثر من ثلاثة أشهر: ساعات مهدورة في تتبّع تراجعات أداء كان يمكن رصدها بقياس حمل بسيط قبل النشر. منذ ذلك الحين، لم أرَ عملية ترحيل LTS مؤسسية ناجحة من دون السمة ذاتها: خطوات تدريجية، مقاسة، وقابلة للعكس. هذا التسلسل الذي أوصي به:

‎7. ما معنى ذلك للنظام البيئي العالمي لـ .NET؟

تعكس دورة LTS لـ Microsoft استراتيجية منصة أوسع. الالتزام بـ .NET 10 حتى 2028 ليس مجرد قرار runtime، بل إشارة حول اتجاه النظام البيئي. ويشير تكامل Native AOT عبر المكدس (ASP.NET Core، MAUI، تطبيقات وحدة التحكم) إلى رهان واضح على النشر المستقل ومنخفض الحمل بوصفه الوضع الافتراضي لتطبيقات .NET.

للفرق البانية على البنية التحتية السحابية، لهذا الالتزام آثار مباشرة على الميزانية. عمليات البدء البارد للـ serverless المقاسة بالميلي ثانية بدلاً من الثوانٍ تعني موارد أقل فائضاً وتكلفة أدنى. كذلك تبدأ الخدمات المُجمَّعة بـ Native AOT في بيئات Kubernetes أسرع، وتستخدم ذاكرة أقل في وضع الخمول، وهي وفورات ملموسة على نطاق واسع.

كلمة ختامية

‎.NET 10 LTS ليس مجرد تحديث لرقم الإصدار. تحسينات GC، وميزات لغة C# 14، ونضج Minimal API، ودعم MAUI Native AOT، كلّها تشير في اتجاه واحد: ذاكرة أقل، بدء أسرع، وكليشيه أقل في الكود. امتلاك أساس LTS مستقر حتى 2028 يعني ثلاث سنوات من البناء على أرضية صلبة بدلاً من ملاحقة تحديثات الـ runtime.

إذا كنت لا تزال على .NET 8 ولم تبدأ التخطيط بعد، فالوقت المناسب الآن. دعم .NET 8 ينتهي في نوفمبر 2026. واستراتيجية الترحيل المرحلي المُختبَرة أقل إيلاماً دائماً من التسابق في اللحظات الأخيرة. ابدأ بتدقيق التبعيات، واختر خدمة غير حرجة كمرحلة تجريبية، وانطلق من هناك.