طابور المهام

طابور المهام هو صف انتظار داخل برنامجك، وهو موجود لأن بعض الأعمال أثقل من أن تُنفَّذ والموظف واقف أمام الشاشة. خمسمئة فاتورة، أو تقرير آخر الشهر، أو رسالة تذهب إلى تسعة آلاف عميل، كلها من هذا النوع. فالنظام يضع هذا العمل في صف وينفّذه في الخلفية، قطعة بعد قطعة.

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

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

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

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