هل هناك أحد آخر؟ لقد عملت مع كلا النمطين الآن، لوحة السحب والإفلات البصرية وقائمة الكتل القابلة للتكوين الممله.
تعرض لوحة القماس نفسها بشكل جميل. بعد ستة أشهر، تتقاطع الأسهم، ولا يستطيع أحد العثور على أي شيء، ومعرفة السبب الذي جعل العميل يحصل على إجابة معينة هو في الأساس علم آثار. تلك القائمة على الكتل قبيحة لكن على الأقل يمكنني قراءتها.
ما الذي أوقفك على التدفقات الفوضوية الحقيقية؟ وإذا كنت تستخدم إحدى تلك الأدوات المساعدة التي تصيغ التدفقات لك، هل تسمح لها بتعديل تدفق موجود أم فقط إنشاء أجزاء جديدة؟ أنا فقط أسمح لها بالإنشاء، وهذا ربما يكون خرافة من جانبي.
قسّم حسب مرحلة المحادثة، وليس حسب عدد العقد. كل مرحلة توجد في سير عملها الخاص خلف عقدة Execute Sub-workflow مع تعريف Workflow Inputs، بحيث يكون الأب صفًا واحدًا من ستة صناديق يمكن لأي شخص قراءتها. التوجيه يمر عبر عقدة Switch واحدة مع تفعيل Rename Output، بحيث تخبر الفروع ما هي بدلاً من Output 3. للتوثيق، فعّل Save successful executions في إعدادات سير العمل وضع عقدة Execution Data في الأعلى لحفظ conversationId و intent. قائمة Executions تصفيها على أساس هذه، و Copy to editor تعيد تشغيل هذا التشغيل بالضبط مع بيانات حقيقية مثبتة. على المنشئ: create only هي قاعدة عادلة للأب. تعديل سير عمل فرعي آمن بدرجة كافية، لأن Workflow history يحفظ كل نسخة، والعودة بخطوة واحدة، وأثر الانفجار هو مرحلة واحدة. لا أزال أبقيها بعيدة عن Switch.
تقسيم سير العمل إلى أجزاء فرعية في وقت مبكر كان أكبر إصلاح بالنسبة لي عندما يتجاوز لوح العمل الواحد حوالي 15-20 عقدة، أقوم بفصل الأجزاء القابلة لإعادة الاستخدام (المصادقة والتنسيق ومعالجة الأخطاء) إلى سير عملهم الخاص واستدعاؤهم. تسمية العقد بشكل وصفي بدلاً من ترك الافتراضيات (مثل IF1 أو Set2) توفر الكثير من الوقت بعد أشهر. على سؤال المسودات المساعدة والتدفقات: السماح لها فقط بإنشاء أجزاء جديدة ليس خرافة، إنه تحرير تلقائي سليم على السلك الموجود يمكن أن تعيد توصيل الاتصالات بصمت دون أن تلاحظها حتى ينقطع شيء ما في الإنتاج. أفضل مراجعة فرق العقد الجديدة بدلاً من الوثوق بها ألا تلمس ما يعمل بالفعل.
إعجاب واحد (1)
كلا الردين أعلاه يحلان مشكلة إيجاد التشغيل. ما يبقى صعباً هو معرفة ما إذا كانت الإجابة صحيحة. إعادة تشغيل التنفيذ تخبرك بما حدث، وليس بما كان يجب أن يحدث.
أرخص طريقة لسد هذه الفجوة هي مجموعة مجمدة من محادثات حقيقية، الحالات الحرجة بدلاً من مسارات النجاح، كل منها مع النتيجة التي يجب أن تنتجها: النية، الفرع المتخذ، شكل الرسالة النهائية. أعد تشغيل المجموعة بعد كل تغيير وقارن النتائج بدلاً من المستندات.
هذا يجيب أيضاً على سؤال الإنشاء مقابل التحرير بدون تخمين. يظهر إعادة التوصيل الصامتة كثلاث محادثات تأخذ فجأة فرعاً مختلفاً في يوم التحرير، بدلاً من شكوى العميل بعد أسابيع. إذا كان الاختلاف السلوكي نظيفاً، فإن السماح به بالتحرير هو رهان أصغر بكثير.
تقسيم سير العمل إلى سير فرعي هو القرار الصحيح، وهناك شيء واحد يستحق معرفته قبل أن تقوم به: فهو يحل مشكلة القراءة وبهدوء يجعل مشكلة علم الآثار أصعب، ما لم تفعل شيئًا إضافيًا واحدًا.
سير عمل فرعي يتم استدعاؤه من خلال Execute Sub-workflow يحصل على تنفيذه الخاص. لذلك بيانات تنفيذ الأب — conversationId و intent المحفوظة في الأعلى — تعيش على صف الأب، والستة تشغيلات فرعية التي قامت بالعمل فعليًا لا تحمله. قم بتصفية قائمة Executions حسب هذا conversationId وستحصل على الأب مرة أخرى، الذي يخبرك أن المحادثة حدثت وليس أكثر من ذلك بكثير. افتحه وأنت تنقر عبر كل فرع يدويًا، وهو بالضبط علم الآثار الذي كنت تحاول إيقافه، فقط مع صناديق أنظف.
الحل صغير وسهل أن تنساه: ضع عقدة Execution Data في الجزء العلوي من كل سير عمل فرعي أيضًا، يتم ملؤها من Workflow Inputs الخاص به، بحيث يتم كتابة conversationId نفسه على كل فرع. ثم يعود مرشح واحد المحادثة بأكملها كمجموعة من الصفوف بدلاً من صف واحد يخفي خمسة. حدد المدخلات بحيث يكون conversationId مدخلاً معلنًا بدلاً من شيء تصل إليه في $('...') — بهذه الطريقة لا يمكن لسير عمل فرعي يتم استدعاؤه من مكان جديد أن يفقد علامته بصمت.
شيئان دفعاني بنفس الطريقة التي ذهبت إليها، لما تستحقه:
Rename Output يحقق فائدته تتجاوز سهولة القراءة. بمجرد تسمية الفروع، يصبح اسم الفرع قيمة يمكنك حفظها في بيانات التنفيذ، لذلك “أي مسار جاءت هذه الإجابة منه” يصبح مرشحًا بدلاً من إعادة قراءة القماش. هذا هو السؤال المحدد الذي وصفته بأنه علم الآثار، وينقلب إلى استعلام.
الفشل الذي ينجو من كل هذا هو الفرع الذي كان يعمل ولم يفعل شيئًا. جهاز توجيه يرسل محادثة إلى مرحلة حيث تكون الكتابة على المسار غير المأخوذ ينتج عنه تنفيذ أخضر ببيانات تبدو صحيحة. البنية لا تمسكه، لأنه لا يوجد شيء خاطئ مع البنية؛ التشغيل انتهى حقًا. ما يمسكه هو التأكيد على العدد بعد كل كتابة — العناصر المكتوبة أكبر من صفر — لذا تصبح الحالة الصامتة تشغيلاً أحمرًا عاديًا بدلاً من عميل يخبرك بعد أسابيع.
على سؤال البناء: أستخدم نفس قاعدة create-only للأب، وأنا لا أعتقد أنها خرافة. ليس لأن الأداة سيئة في التحرير، بل لأن الأب هو الملف الوحيد حيث تكون الشكل هي التوثيق. والد معاد إنشاؤه يكون متطابقًا وظيفيًا وتم إعادة ترتيبه بصريًا يكلفك الخريطة الذهنية التي بنيتها، وستكتشف ذلك في أسوأ لحظة. سير العمل الفرعي رخيص للسماح له باللمس، لأن عقدهم هي المدخلات المعلنة — إذا كانت تلك لا تزال متطابقة، فإن الجسم المعاد كتابته هو جسم يمكنك قراءته بشكل طازج.
الحد الصريح من كل هذا: فهو يجعل الإجابة قابلة للعثور عليها بعد الواقعة. لا شيء هنا يقصر الفجوة بين سير عمل يسقط صامتًا وبين شخص ما يلاحظ، وفي تجربتي تلك الفجوة هي حيث تجلس التكلفة الحقيقية.