الديون التقنية في Flows وApex: كيفية تحديدها وتقليصها دون إعاقة عملية التطوير

لماذا يختلف الدين التقني في الأتمتة عن الدين التقني الاعتيادي

في Salesforce، تتراكم الديون التقنية بسهولة أكبر مما هي عليه في بيئة تطوير نموذجية؛ وذلك لأن الأداة تمكّن أي شخص من إضافة الأتمتة دون المرور بعملية برمجية منظمة. كل مسؤول نظام يضيف Flow Before Save لحل مشكلة محددة، وكل Trigger أضيف منذ عامين ولا يتذكر أحد الغرض منه، وكل حقل صيغة يعتمد على حقل آخر لم يعد موجودًا – كل هذه الأمور تتراكم لتشكّل طبقة لا يمكن رؤيتها بشكل كامل.

يكمن الاختلاف الجوهري بين الدين التقني الاعتيادي والدين التقني في أتمتة Salesforce في أن الأخير يكاد يكون دائمًا خاليًا من التوثيق المركزي. فالتعليمات البرمجية موجودة في المستودع (Repository) مع سجل التزامات (Commits history)، بينما يوجد Flow في Setup بدون شرح لسبب إنشائه. هذا يجعل مرحلة التحديد صعبة للغاية – ليس لأن المشكلة معقدة تقنيًا، بل لأنه لا يوجد من يمكن سؤاله.

تتناول هذه المقالة تحديد وقياس وتقليل هذا الدين. وهي لا تناقش متى يجب اختيار Flow ومتى يجب اختيار Apex من الأساس – لذلك خُصص مقال Flow مقابل Apex: كيف تختار.

ثلاثة أنواع من الديون تتصرف بشكل مختلف

ليس كل دين تقني متماثلًا، ومعالجة جميعها على أنها نفس المشكلة يؤدي إلى إهدار الجهد. من الأفضل تقسيمها إلى ثلاث فئات:

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

كيف يتم تحديد الديون قبل أن تنفجر في بيئة الإنتاج

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

• عدد الـFlows النشطة على كل كائن أساسي (مثل Lead, Opportunity, Case). تجاوز خمسة أو ستة Flows نشطة على نفس الكائن يجعل ترتيب التنفيذ صعب التنبؤ.
• عدد الـTriggers غير الموحدة تحت إطار عمل واحد لكل كائن. أكثر من Trigger واحد لكائن هو بالفعل علامة تحذير، ما لم توجد طبقة توجيه (Routing layer) صريحة.
• كثافة استعلامات SOQL داخل الحلقات التي تظهر في السجلات كـGovernor Limit يقترب من الحد الأقصى، حتى لو لم يتم تجاوزها بالفعل.
• وقت تشغيل غير طبيعي لـFlow أو Apex Batch يزداد بمرور الوقت دون أن ينمو حجم العمل بنفس النسبة.
• الحقول والمتغيرات التي ليس لها استخدام محدد في تقرير Field Usage، والتي تبقى "للحالة التي قد يحتاجها شخص ما".

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

إطار عمل صنع القرار: ما الذي يتم معالجته أولًا

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

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

سيناريو مؤسسي: شركة تأمين لديها 14 Flow على Opportunity

لنفترض شركة تأمين متوسطة الحجم تدير مبيعات B2B عبر Salesforce منذ ست سنوات. على مر الوقت، تراكمت 14 Flow نشطًا على كائن Opportunity: سبعة Flows تتعامل مع تحديثات المراحل، ثلاثة ترسل إشعارات داخلية، اثنان يقومان بمزامنة البيانات مع أداة BI خارجية، واثنان آخران هما بقايا عملية قديمة تم استبدالها قبل عامين ولكن لم يتم تعطيلهما مطلقًا.

triggered كان الخلل المحدد هو الذي أدى إلى تحديد المشكلة: انتقلت صفقة إلى مرحلة "Closed-Won"، ولكن لم يتم إرسال الإشعار إلى فريق الاكتتاب، لأن Flow آخر قام بتحديث نفس الحقل في نفس الوقت، مما أدى إلى توقيت تنفيذ غير متوقع. أمضى الفريق يومين في محاولة لفهم السبب – ليس لأن الخلل كان معقدًا، بل لأن أحدًا لم يكن يعرف ترتيب التنفيذ الكامل لـ14 مكونًا.

لم تكن المعالجة هي "إعادة كتابة كل شيء في Apex". قام الفريق أولاً برسم جميع الـ14 Flow وتصنيفها وفقًا للجدول أعلاه: تم تعطيل الـFlows القديمين بعد التحقق من عدم وجود تبعية نشطة، وتم دمج الإشعارات الثلاثة في Flow واحد مع منطق توجيه واضح، وتم دمج تحديثات المراحل السبعة تحت Record-Triggered Flow واحد بترتيب تنفيذ صريح. النتيجة: من 14 مكونًا إلى 6، مع توثيق ترتيب التنفيذ الذي يمكن لأي مطور جديد قراءته في غضون ربع ساعة.

المخاطر في عملية تخفيض الدين نفسها

تقليل الدين التقني هو عملية تنطوي على مخاطر خاصة بها، ليست مجرد إصلاح لمخاطر موجودة:

الخطر المشترك لجميع هذه الحالات هو نفس الظاهرة: الفريق واثق من أنه "ينظف" فقط، وبالتالي يتجاوز الاختبارات التي كان سيجريها لميزة جديدة. على مستوى الحوكمة، يجب أن يخضع Refactor لنفس عملية القبول التي يمر بها التطوير العادي – ليس أقل.

مقاييس المراقبة المستمرة بعد التخفيض

للتأكد من أن الجهد يقلل الدين حقًا ولا يكتفي بتحريكه، ينبغي متابعة ما يلي:

• عدد مكونات الأتمتة النشطة لكل كائن, كمقياس اتجاه ربع سنوي وليس نقطة واحدة.
• متوسط الوقت لتشخيص خلل الأتمتة, من لحظة الإبلاغ وحتى تحديد المكون المسؤول.
• النسبة المئوية للمكونات الموثقة من إجمالي الأتمتة النشطة في المجموعة الأساسية.
• عدد الأعطال المتكررة على نفس المكون في مدى ثلاثة أشهر.

تستعين المؤسسات التي تواجه صعوبة في تحديد الأولويات بين Refactor والتطوير المستمر بـخدمة هندسة CRM لبناء خطة عمل ملزمة وقابلة للقياس.

قائمة مراجعة تشغيلية قبل البدء في Refactor

• ☐ توجد خريطة كاملة لجميع الأتمتات النشطة على الكائن المعني
• ☐ معروف ترتيب التنفيذ الفعلي، وليس فقط حسب ترتيب الإنشاء
• ☐ تم فحص كل مكون مخصص للإزالة مقابل سجلات التنفيذ على مدار عام كامل
• ☐ وافق مالك العملية التجارية على القاعدة التي يتم تطبيقها من جديد
• ☐ توجد بيئة اختبار تحاكي حجم البيانات الحقيقي
• ☐ تم تحديد مقياس "قبل وبعد" لعدد المكونات ووقت التشخيص
• ☐ تمر عملية الـRefactor بعملية Release عادية، وليس Deploy استثنائي
• ☐ تم تخصيص سعة ثابتة في كل Sprint للمعالجة المستمرة، وليس مجرد حدث لمرة واحدة

الخلاصة

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