ما هو VBA: حدوده، آفاقه المستقبليّة، متى يجب استبداله، وأنماط الترحيل العمليّة

تميل الأسئلة المتعلّقة بـ VBA إلى التداخل بسرعة كبيرة:

• ما هو VBA فعلاً
• هل أصبحت الماكروهات تُعتبر اليوم خطرة جدّاً بحيث لا يمكن استخدامها
• هل سيختفي VBA قريباً
• هل ينبغي نقل كلّ شيء إلى Office Scripts أو Power Automate
• هل ينبغي الاحتفاظ بمصنّفات .xlsm الموجودة أو أصول Access أم استبدالها
• هل من المقبول تشغيل Excel في الباتشات الليليّة أو على خادم

هذه المواضيع لا تنحلّ إلى إجابة واحدة نظيفة بنعم أو لا.
أوّل تقسيم مفيد ليس هل التقنية قديمة أم جديدة، بل أين تُشغَّل، ومن يستخدمها، وهل لا يزال Excel أو Access هو واجهة المستخدم الفعليّة، وهل يجب أن يعمل الحمل بدون مراقبة.

ترتّب هذه المقالة الموضوع بهذا التسلسل: ما هو VBA، وأين تقع حدوده، وهل من المرجّح أن يختفي، ومتى يكون الاستبدال منطقيّاً، وكيف يبدو الترحيل المتدرّج العمليّ.
يستند النقاش إلى المعلومات الرسميّة من Microsoft التي يمكن التحقّق منها حتى مارس 2026.¹²³⁴⁵

1. النسخة المختصرة

يبدو الملخّص العمليّ كالآتي:

• VBA هو لغة موجَّهة بالأحداث لتوسيع تطبيقات Office على سطح المكتب. وُضع ليعمل داخل تطبيقات مثل Excel وWord وPowerPoint وAccess.¹
• اعتباراً من مارس 2026، لا يوجد إعلان واضح من Microsoft يقول إنّ VBA نفسه على وشك الإيقاف. ما يتغيّر ليس إزالةً مفاجئة، بل حدّاً أوضح حول المواضع التي يناسبها VBA والمواضع التي لا يناسبها.¹²³⁴
• بشكل ملموس، لا يستطيع Excel for the web إنشاء أو تشغيل أو تحرير VBA، وماكروهات الملفّات ذات الأصل من الإنترنت محظورة افتراضيّاً.²³
• لذلك السؤال الحقيقيّ ليس هل نتخلّص من VBA كلّيّاً. بل هو أيّ المسؤوليّات ينبغي أن تبقى في VBA وأيّها ينبغي أن تنتقل إلى مكان آخر.
• على وجه الخصوص، الأحمال التي تتطلّب التنفيذ غير المراقب، أو التنفيذ على الخادم، أو التشغيل المشترك بين عدّة مستخدمين، أو الوصول من المتصفّح، أو التوزيع المركزيّ، أو قابليّة التدقيق العالية لا تُعدّ في الغالب مرشّحات جيّدة للبقاء كلّيّاً داخل VBA. كذلك لا توصي Microsoft بأتمتة Office على جانب الخادم ولا تدعمها.⁶
• لا يوجد هدف استبدال واحد.
  التقسيم الواقعيّ هو: الإبقاء على Excel ولكن نقل المنطق الثقيل إلى DLL من .NET أو إلى عمليّة أخرى، واستخدام Office Scripts + Power Automate لأتمتة سير عمل Microsoft 365، واستخدام Office Add-ins للتمديدات متعدّدة المنصّات، والانتقال إلى تطبيق Windows أو ويب عندما لا يعود Excel هو واجهة المستخدم الفعليّة.⁴⁵⁶

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

2. ما هو VBA

VBA هو اختصار لـ Visual Basic for Applications، وهو شكل من Visual Basic يأتي مع Microsoft Office. تصفه وثائق Microsoft نفسها بأنّه لغة برمجة موجَّهة بالأحداث تتيح لك توسيع تطبيقات Office.¹⁷

النقطة العمليّة المهمّة هي أنّ VBA يسهل فهمه باعتباره لغة توسعة داخل تطبيقات Office بدلاً من اعتباره منصّة تطبيقات للأغراض العامّة.

في Excel على سبيل المثال، يعيش بالقرب من أشياء مثل:

• Workbook
• Worksheet
• Range
• الأزرار والنماذج
• الأحداث مثل فتح المصنّف أو الحفظ أو تغيير خليّة

هذا القرب هو السبب في أنّ VBA لا يزال يعمل بشكل جيّد لـ الأتمتة من جانب المستخدم التي تبقى على سطح المكتب.
يفتح المستخدم Office على سطح المكتب، وينقر زرّاً، ويعالج بيانات محلّيّة أو من مجلّد مشترك، ويُنتج مصنّف أو تقرير مخرجات. هذا النوع من سير العمل لا يزال يطابق الأرضيّة الطبيعيّة لـ VBA.¹

ما لم يُصمَّم VBA من أجله أصلاً هو الخوادم أو المتصفّحات أو الأجهزة المحمولة أو أنظمة الويب متعدّدة المستأجرين.

3. لماذا لا يزال VBA يبقى في المشاريع الفعليّة

يبقى VBA في العمل الحقيقيّ ليس فقط لأنّ الأنظمة القديمة لم تُنظَّف أبداً. بل يبقى أيضاً لأنّ Excel وAccess يحتفظان في الغالب بـ إجراءات عمل فعليّة، وليس مجرّد بيانات.

يمكن أن يشمل ذلك:

• تخطيط التقارير
• إعدادات الطباعة
• التحقّق من المدخلات
• ترتيب عمليّات نهاية الشهر
• قواعد الاستثناءات الخاصّة بالأقسام
• خطوات يدويّة يتّبعها المستخدمون منذ سنوات

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

كذلك يكون VBA قريباً من نموذج كائنات Office نفسه، فعندما يكون الهدف هو التلاعب بسطح Excel أو Access الذي ينظر إليه المستخدم بالضبط، يمكن أن تبقى كمّيّة الكود والإجراءات الشكليّة صغيرة نسبيّاً.

ولذلك فإنّ التقسيم العمليّ الأكثر فائدة هو:

• إذا كان Excel لا يزال هو واجهة المستخدم، فقد يظلّ الإبقاء على بعض VBA أمراً يستحقّ
• إذا كان Excel يحتاج فقط إلى البقاء كمدخل ومخرج، فمن الأسهل نقل المنطق الأساسيّ خارجاً
• إذا كان Excel لم يعد هو واجهة المستخدم الصحيحة على الإطلاق، فإنّ إعادة التصميم الأكثر اكتمالاً تصبح طبيعيّة

4. الحدود الرئيسيّة لـ VBA

4.1 إنّه موجَّه نحو سطح المكتب أساساً

هذا هو الحدّ الأكبر.
VBA هو في الأساس تقنية تعيش داخل Office على سطح المكتب.

تذكر المعلومات الرسميّة من Microsoft صراحةً أنّ Excel for the web لا يستطيع إنشاء أو تشغيل أو تحرير VBA، رغم أنّه يستطيع فتح وتحرير مصنّف يحتوي على كود VBA دون تنفيذ ذلك الكود.²⁸

هذا يجعل VBA بالفعل غير ملائم عندما تبدو المتطلّبات كالآتي:

• الاستخدام عبر المتصفّح فقط
• التوسعة نفسها عبر Mac وiPad والويب
• التوزيع الإداريّ المركزيّ
• تجنّب الاعتماد على تطبيق Excel على سطح المكتب المحلّيّ

كذلك توجّه وثائق VBA الخاصّة بـ Microsoft نفسها الناس نحو Office Add-ins عندما يكون الهدف هو التوسعة عبر منصّات متعدّدة.⁹⁵

4.2 الأمن والتوزيع أصبحا أكثر احتكاكاً بكثير الآن

جزء كبير من الإحساس بأنّ «VBA لم يعد يعمل» هو في الواقع تشديد أمنيّ، وليس اختفاء اللغة.

تحظر Microsoft الماكروهات في الملفّات التي جاءت من الإنترنت بشكل افتراضيّ. ملفّ .xlsm الذي تمّ تنزيله أو إرفاقه عبر البريد لم يعد يتصرّف بشكل عابر كما كان قبل سنوات.³

هذا هو الاتجاه الأمنيّ الصحيح.
لكن من الناحية التشغيليّة، يعني هذا مزيداً من الاحتكاك:

• يصبح إرسال مصنّفات الماكرو كمرفقات غير موثوق
• لا تعمل القوالب التي تمّ تنزيلها مباشرةً بعد الآن
• يصبح التعامل مع OneDrive وSharePoint والشبكات كأصل مربكاً
• تصبح «الرجاء النقر للتمكين» نموذج توزيع ضعيف

لذلك فإنّ إحدى المشكلات الحقيقيّة حول VBA ليست فقط سطح اللغة. إنّها أيضاً تصميم التوزيع والثقة.

4.3 لا يزال حدّ 32-bit / 64-bit مهمّاً

يأتي Office بنسختين 32-bit و64-bit، وOffice 2019 وMicrosoft 365 يكونان افتراضيّاً 64-bit.⁷

يعني هذا أنّ كود VBA الأقدم، ولا سيّما الكود الذي يستدعي Windows APIs عبر Declare، قد لا يستمرّ في العمل دون تغيير في بيئات 64-bit. توثّق Microsoft الحاجة إلى أمور مثل PtrSafe وLongPtr وLongLong عند عبور ذلك الحدّ.⁷

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

• اعتماديّات COM / ActiveX / OCX القديمة
• مكتبات DLL خارجيّة تفترض 32-bit
• مكوّنات تعتمد على التسجيل في registry
• اختلافات في إعدادات مرجعيّات Office

لذلك فإنّ كثيراً من ترحيلات VBA تتحوّل إلى ممارسة لتنظيف bitness والاعتماديّات، وليست مجرّد إعادة كتابة لغويّة.

4.4 إنّه ليس مناسباً للتنفيذ غير المراقب أو على جانب الخادم

هذا الجزء مهمّ جدّاً.
تقول Microsoft صراحةً إنّ الأتمتة على جانب الخادم لـ Office غير موصى بها وغير مدعومة. صُمّمت تطبيقات Office حول الاستخدام التفاعليّ على سطح المكتب وملفّات تعريف المستخدمين، ويمكن أن تصبح غير مستقرّة أو يحدث لها deadlock في البيئات غير المراقبة.⁶

يجعل هذا الأنماط التالية محفوفة بالمخاطر:

• تشغيل Excel من خدمة Windows
• أتمتة Office من ASP.NET أو DCOM
• تشغيل نسخ Excel مخفيّة إلى أجل غير مسمّى في Task Scheduler
• إخراج توليد التقارير إلى Excel على جانب الخادم

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

عندما يكون التنفيذ غير المراقب هو المتطلّب، فإنّ أوّل شيء يجب التشكيك فيه ليس VBA نفسه، بل قرار قيادة تطبيق Excel في المقام الأوّل.

4.5 الصيانة والاختبار ومراجعة الفروقات أصعب بنيويّاً

كود VBA محصور في الغالب داخل المصنّفات أو ملفّات Access.
يؤدّي ذلك إلى مشكلات عمليّة متكرّرة:

• يصبح من غير الواضح أيّ ملفّ هو مصدر الحقيقة
• تنتشر المسؤوليّات عبر النماذج والأوراق والوحدات القياسيّة
• تنحرف المرجعيّات واعتماديّات ActiveX بين البيئات
• تصبح مراجعة الكود ومراجعة الفروقات أصعب
• اختبار الوحدة صعب
• تصبح إحداثيّات الخلايا نفسها جزءاً من المواصفات تدريجيّاً

هذه ليست مشكلة «لغة VBA» فحسب. إنّها أيضاً مشكلة إبقاء منطق الأعمال داخل ملفّات Office.

4.6 الاعتماديّات المتعلّقة بـ VBScript تحتاج إلى فحص منفصل

في عام 2025، حذّر Microsoft 365 Developer Blog من أنّ الإلغاء التدريجيّ لـ VBScript في Windows يمكن أن يؤثّر على بعض مشاريع VBA.
يهمّ هذا بشكل خاصّ المشاريع التي تشغّل سكريبتات .vbs خارجيّة أو تعتمد على VBScript.RegExp.¹⁰

في الوقت نفسه، وصفت Microsoft أيضاً مساراً لتخفيف الأثر يتضمّن أنّ فئة RegExp مُدرَجة في VBA افتراضيّاً في Office على Windows ابتداءً من Microsoft 365 Version 2508 (Build 19127.20154).¹⁰

النقطة المهمّة هي أنّ إلغاء VBScript ليس هو نفسه إلغاء VBA.
من الأدقّ التفكير فيه على أنّه مراجعة لاعتماديّات خارجيّة معيّنة استخدمتها مشاريع VBA صدفةً.

5. هل سيختفي VBA

الإجابة الصادقة هي: ليس بمعنى «كلّ شيء يتوقّف عن العمل غداً».
لكنّه أيضاً لم يعد عصر «استخدم VBA لأيّ شيء في أيّ مكان».

إذا قرأت اتّجاه Microsoft الحاليّ على المستوى العمليّ، فإنّه يبدو أكثر كالآتي:

• يستمرّ VBA في الوجود كتقنية توسيع لـ Office على سطح المكتب¹
• تتجّه سيناريوهات الويب والمنصّات المتعدّدة نحو Office Scripts وOffice Add-ins⁴⁵⁹
• يُعامل توزيع الماكرو بمزيد من الاحتكاك الأمنيّ مقارنةً بالسابق³
• قد تتأثّر الاعتماديّات المحيطة مثل VBScript بتغييرات المنصّة المستقبليّة¹⁰

كذلك تذكر Microsoft أنّ Office Scripts مقصود لحلول آمنة ومتعدّدة المنصّات وقائمة على السحابة، بينما يغطّي VBA حتّى الآن مجموعة أوسع من ميزات Excel على سطح المكتب.⁴

ينتج عن ذلك صورة عمليّة:

• العمل العميق على Excel سطح المكتب لا يزال يناسب VBA بشكل أفضل في كثير من الحالات
• سيناريوهات المتصفّح وMicrosoft 365 وسير العمل المشترك تناسب Office Scripts أو Add-ins بشكل أكثر طبيعيّة
• لذلك فالإجابة ليست «استبدل كلّ شيء بـ Office Scripts» ولا «احتفظ بـ VBA في المركز إلى الأبد»

من الواقعيّ أكثر رؤية مستقبل VBA على أنّه حدود أوضح، وليس اختفاءً.

6. متى يتمّ الاستبدال ومتى لا

يبدو جدول القرار التقريبيّ ولكن المفيد كالآتي:

النقطة المهمّة هي أنّ قرار الاستبدال لا ينبغي أن يستند إلى «VBA قديم».
عوامل القرار الحقيقيّة هي بيئة التشغيل، والعمليّات، والتوزيع، والاعتماديّات، وقابليّة التدقيق، واحتياجات التوسعة.

7. مسارات الاستبدال الواقعيّة

7.1 احتفظ بـ Excel، لكن انقل المنطق الثقيل إلى .NET أو إلى عمليّة أخرى

غالباً ما يكون هذا هو المسار الأكثر واقعيّة والأقلّ خطورة.

• احتفظ بـ Excel أو Access كنقطة دخول متاحة للمستخدم
• احتفظ بالأزرار والنماذج الموجودة الآن
• انقل منطق الأعمال، ومكالمات HTTP، والتشفير، والتعامل مع CSV / JSON، والحسابات الكبيرة، أو معالجة الملفّات إلى خارج VBA
• قلّص VBA إلى طبقة جسر بالإضافة إلى التلاعب من جانب واجهة المستخدم

الميزة الكبيرة هي أنّ التخطيط وسير العمل المتاحَين للمستخدم لا يحتاجان إلى الكسر دفعةً واحدة.

مقالة ذات صلة:

• كيفيّة استخدام DLL لـ .NET 8 من VBA مع الربط المبكّر عبر COM وdscom

من الناحية العمليّة، «انقل الجزء الثقيل أوّلاً فقط» غالباً ما يكون أكثر صحّة بكثير من «أعد كتابة كلّ شيء أوّلاً».

7.2 لتوليد التقارير غير المراقب، توقّف عن قيادة Office وأنشئ الملفّات مباشرةً

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

لا توصي Microsoft بأتمتة Office على جانب الخادم.
عوضاً عن ذلك، تشير الإرشادات الرسميّة إلى مقاربات مثل التعامل مع ملفّات Office مباشرةً بصيغ مثل Open XML.⁶

لذلك إذا كان المتطلّب الفعليّ هو:

• إنشاء ملفّات .xlsx
• توليد عدد كبير من التقارير ذات التنسيق الثابت
• التصدير إلى PDF
• التشغيل في باتش ليليّ

فإنّ سؤال التصميم يجب أن يكون هل نُجمِّع ملفّات Excel مباشرةً، وليس هل نستمرّ في قيادة Excel.

مقالة ذات صلة:

• كيفيّة بناء مخرجات تقارير Excel: أتمتة COM وOpen XML والمفاضلات القائمة على القوالب

7.3 إذا كان سير العمل موجوداً بالفعل داخل Microsoft 365، ففكّر في Office Scripts + Power Automate

عندما تعيش عمليّة الأعمال بالفعل حول OneDrive وSharePoint وTeams وOutlook وForms، يصبح Office Scripts مرشّحاً قويّاً.

تصف Microsoft Office Scripts بأنّه مسار حلّ آمن ومتعدّد المنصّات وقائم على السحابة.
بالاندماج مع Power Automate، يمكنه أتمتة عمل Excel المشغَّل بواسطة البريد الإلكترونيّ والنماذج والجداول الزمنيّة وأحداث M365 الأخرى.⁴¹¹

لكنّه ليس بديلاً شاملاً:

• لا يدعم Office Scripts الأحداث على مستوى Excel
• التنفيذ بشكل عامّ يدويّ أو يُشغَّل عبر Power Automate⁴
• يتطلّب مسار التكامل مع Power Automate ترخيص أعمال Microsoft 365¹¹
• يحتوي إجراء Run script على حدود مثل 1,600 استدعاء لكلّ مستخدم في اليوم و120 ثانية للتنفيذ المتزامن¹²

لذلك من الأفضل في الغالب أن يُفهم Office Scripts ليس باعتباره «VBA الجديد»، بل باعتباره لبنة أتمتة داخل Microsoft 365.

7.4 إذا كنت بحاجة إلى توسعات متعدّدة المنصّات، فإنّ Office Add-ins هو المسار الطبيعيّ

إذا كان الهدف هو توسيع Word أو Excel أو Outlook عبر Windows وMac وiPad والويب، فإنّ Office Add-ins هو أوّل ما يجب تقييمه.

تصف وثائق Microsoft الرسميّة Office Add-ins بأنّها مبنيّة بـ HTML / CSS / JavaScript، قادرة على العمل عبر منصّات متعدّدة، ومناسبة للتوزيع المركزيّ.⁵

يناسب هذا سيناريوهات مثل:

• ربط Office ببوّابة داخليّة أو نظام أعمال أساسيّ
• إظهار نفس واجهة المستخدم أو الأوامر في Outlook وExcel وWord
• الابتعاد عن توزيع الماكرو لكلّ جهاز
• ترك نموذج توزيع .xlsm المحلّيّ خلفك

نموذج التطوير مختلف كثيراً عن «اكتب الكود داخل Excel».
لكن في المقابل، تصبح العمليّات والتوزيع أنظف بكثير.

7.5 إذا لم يعد Excel أو Access هو واجهة المستخدم الفعليّة، فانتقل نحو تطبيق Windows أو ويب

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

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

في هذه الحالة، قد يكون تطبيق سطح مكتب C# / .NET أكثر طبيعيّة لأدوات الأعمال على Windows فقط، بينما قد يناسب تطبيق ويب بشكل أفضل عندما تكون قاعدة المستخدمين وانتشار الأجهزة أوسع.

8. مسار ترحيل متدرّج عمليّ

أخطر حركة ترحيل هي محاولة دفع كلّ شيء إلى تقنية جديدة واحدة من البداية.
من الناحية العمليّة، يكون الترتيب الأكثر أماناً عادةً كالآتي.

8.1 ابنِ جرداً للأصول أوّلاً

أوّل ما يجب جرده ليس حجم الكود، بل الاعتماديّات.

• ما هي ملفّات .xlsm و.xlam و.accdb و.mdb الموجودة
• أيّها هو نقطة دخول تشغيليّة فعليّة
• ما هي المرجعيّات المُهيَّأة
• ما هي اعتماديّات Declare ومكتبات DLL الخارجيّة وCOM / ActiveX / OCX الموجودة
• ما هي افتراضات 32-bit / 64-bit
• أيّ المستخدمين يشغّلون أيّ الماكروهات في أيّ خطوات الأعمال
• ما هي المخرجات: Excel وCSV وPDF والطباعة والبريد الإلكترونيّ وما إلى ذلك

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

8.2 قسّم الكود حسب المسؤوليّة

الخطوة التالية هي فصل النظام ليس حسب الملفّ، بل حسب المسؤوليّة:

• التلاعب بواجهة Excel / Access
• إدخال وإخراج ورقة العمل
• تخطيط التقرير
• قواعد العمل
• I/O لـ API الخارجيّ والملفّ وقاعدة البيانات
• معالجة الباتش
• الطباعة والتوزيع

يُسهِّل ذلك بكثير رؤية ما ينبغي أن يبقى وما ينبغي أن يصبح أرقّ وما ينبغي أن يخرج.

8.3 اختر وجهة لكلّ مسؤوليّة

غالباً ما يبدو التقسيم العمليّ كالآتي:

• التلاعب بواجهة المستخدم وورقة العمل: احتفظ به في VBA الآن
• منطق الأعمال: انقله إلى .NET أو عمليّة أخرى أو خدمة
• توليد التقارير غير المراقب: انتقل نحو Open XML أو توليد الملفّ مباشرةً
• سير عمل Microsoft 365: استخدم Office Scripts + Power Automate
• واجهة المستخدم متعدّدة المنصّات: استخدم Office Add-ins
• المناطق التي أصبحت أنظمة فعليّة: افصلها إلى تطبيقات Windows أو ويب

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

8.4 حدّد الواجهة قبل إعادة الكتابة

قبل أن يبدأ الترحيل، يساعد تثبيت عقد كحدّ أدنى:

• ما هو المدخل
• ما هو المخرج
• كيف تُعاد الأخطاء
• أيّ ورقة أو نطاق مسمّى أو مسار ملفّ يصبح جزءاً من العقد
• في أيّ نقطة تُعتبر النتيجة مكتملة

إذا تخطّيت ذلك، تصبح إحداثيّات الخلايا نفسها هي الـ API، وهو أمر هشّ.

8.5 شغّل القديم والجديد بالتوازي للمقارنة

بالنسبة لعمل التقارير والتجميع بشكل خاصّ، التحوّل دفعةً واحدة محفوف بالمخاطر.

• شغّل تنفيذ VBA القديم والتنفيذ الجديد بالتوازي
• قارن مخرجات .xlsx أو CSV أو PDF المُنتَجة
• تحقّق من الفروقات في التواريخ والتقريب والتنسيق ومناطق الطباعة
• اختبر الحالات الحدّيّة وحالات البيانات الفارغة أيضاً

أكثر حوادث استبدال VBA إيلاماً ليست في الغالب «إنّه يتعطّل»، بل انحراف الأرقام أو التنسيق بصمت.

9. الأخطاء الشائعة

9.1 البدء بـ «VBA قديم، لذلك انقل كلّ شيء إلى Office Scripts»

Office Scripts قويّ، لكنّ Microsoft نفسها تقول إنّ VBA لا يزال يغطّي مجموعة أوسع من قدرات Excel على سطح المكتب.
كذلك لا يدعم Office Scripts الأحداث على مستوى Excel.⁴

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

9.2 إبقاء Excel يعمل إلى الأبد في التنفيذ غير المراقب

هذا شائع جدّاً.
يمكن أن يبدو ملائماً ما دام يعمل، لكنّ Microsoft لا توصي بأتمتة Office على جانب الخادم.⁶

بالنسبة للباتشات الليليّة والخدمات، عادةً ما يكون أكثر صحّة الانتقال من قيادة Excel نحو تجميع ملفّات Excel.

9.3 تغيير واجهة المستخدم وتخطيط التقرير وقواعد العمل دفعةً واحدة

الجزء الأكثر إخافة في كثير من ترحيلات VBA ليس ترجمة الكود. إنّه إسقاط سلوك أعمال لم يُكتَب أبداً بشكل واضح.

غالباً ما تحتوي أوراق Excel ونماذج Access على كمّيّة كبيرة من معرفة التشغيل غير المكتوبة.
إذا تغيّر كلّ شيء دفعةً واحدة، تحصل على نتائج تبدو متشابهة لكنّها تختلف في المكان الدقيق الذي يهمّ في نهاية الشهر أو أثناء التعامل مع الاستثناءات.

9.4 ترك bitness والمرجعيّات الخارجيّة لوقت متأخّر

في كثير من مشاريع الترحيل، تنفجر هذه المسائل قبل كود VBA نفسه:

• Declare
• مكتبات DLL الخارجيّة
• COM / ActiveX / OCX
• bitness في Office
• إعدادات المرجعيّات

إذا أجّلت تلك الأسئلة، يميل التنفيذ إلى أن يصبح مؤلماً في وقت متأخّر من المشروع.⁷

9.5 الخلط بين إلغاء VBScript وإلغاء VBA

من وجهة نظر VBA، إلغاء VBScript هو مشكلة مراجعة اعتماديّات، وليس دليلاً على أنّ VBA ككلّ على وشك الانتهاء.¹⁰

إذا اختلط هذان الموضوعان، تنتهي الفرق بسهولة بشائعات داخليّة غامضة مثل «على ما يبدو أنّ VBA على وشك الانتهاء».

10. الخلاصة

في جملة واحدة، VBA هو لغة توسعة مرتبطة ارتباطاً وثيقاً بتطبيقات Office على سطح المكتب.
لأتمتة العمل الذي يبقى قريباً من Excel أو Access على جهاز المستخدم، لا يزال عمليّاً في كثير من الحالات.¹

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

• إذا كنت بحاجة إلى الوصول من المتصفّح أو متعدّد المنصّات، فانظر إلى Office Scripts أو Office Add-ins⁴⁵
• إذا كنت بحاجة إلى التنفيذ غير المراقب أو على جانب الخادم، فتجنّب أتمتة Office⁶
• انقل المنطق الثقيل والتكامل الخارجيّ إلى .NET أو حدود عمليّة أخرى
• إذا كان Excel أو Access لم يعد هو واجهة المستخدم الصحيحة، فانتقل نحو تطبيق Windows أو ويب

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

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

ولهذا السبب يكون الاستبدال أكثر أماناً عندما يُعامَل ليس باعتباره ترجمة، بل باعتباره هيكلة وتوضيحاً.

11. مقالات ذات صلة

• ما هي COM / ActiveX / OCX - دليل عمليّ للفروقات والعلاقات
• كيفيّة استخدام DLL لـ .NET 8 من VBA مع الربط المبكّر عبر COM وdscom
• كيفيّة بناء مخرجات تقارير Excel: أتمتة COM وOpen XML والمفاضلات القائمة على القوالب

12. المراجع

مقالات ذات صلة

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

أين يتصل هذا الموضوع

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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