لماذا يجب أن يكون تطبيقك القادم state machine

9 مايو 2025 · 4 دقائق قراءة

المؤسس المشارك والقائد التقني

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

لا تكمن المشكلة في فريقك. المشكلة في البنية.

التكلفة الخفية لـ"تحرك بسرعة واكسر الأشياء"

تنفق صناعة البرمجيات ما يُقدّر بـ2.41 تريليون دولار سنويًا على إصلاح الكود السيئ (CISQ 2022). ليس على بناء ميزات جديدة — على إصلاح ما هو موجود بالفعل.

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

User clicks "Submit" →
  Is the form valid? (depends on 12 boolean flags)
  Is the user authenticated? (check a global variable)
  Is the network available? (hope for the best)
  Has this already been submitted? (add another boolean)

تضاعف كل علامة منطقية (boolean flag) عدد الحالات الممكنة. مع 10 علامات، يملك تطبيقك 1,024 حالة ممكنة — معظمها لم يختبره أحد.

ماذا لو كان من المستحيل أن يكون تطبيقك إلا في حالات حددتها أنت؟

هذا ما تمنحك إياه الـ state machine (نظام يدير سلوك البرنامج عبر حالات محددة وانتقالات صريحة بينها).

بدلاً من العلامات المنطقية المتناثرة والحالة الضمنية، تُعلن بالضبط ما هو ممكن:

{
  "states": [
    { "name": "Draft", "isInitial": true },
    { "name": "Submitted" },
    { "name": "UnderReview" },
    { "name": "Approved" },
    { "name": "Rejected" }
  ]
}

خمس حالات. ليس 1,024. كل transition (انتقال بين حالتين) بينها صريح:

{
  "from": "Draft",
  "to": "Submitted",
  "event": "SUBMIT",
  "guard": ["and",
    ["not-empty", "@entity.title"],
    ["not-empty", "@entity.description"]
  ]
}

ينص الـ guard (شرط يجب تحققه قبل السماح بالانتقال): لا يمكنك الإرسال بدون عنوان ووصف. ليست هذه مكتبة تحقق قد تنسى استدعاءها — إنها بنية تفرض القاعدة.

الحجة التجارية

1. الأخطاء تصبح مستحيلة معماريًا

تُمنع الأخطاء في التطبيق التقليدي بالاختبارات. تغطي الاختبارات الحالات التي فكرت فيها. تمنع الـ state machines الأخطاء بجعل الحالات غير الصالحة غير قابلة للتمثيل.

هل لديك نافذة منبثقة لا يمكن إغلاقها؟ يرفضها الـ compiler (المُصرِّف الذي يحوّل الـ schema إلى كود) في Almadar:

Error: CIRCUIT_NO_OVERLAY_EXIT
  State 'EditModal' renders to 'modal' slot but has no exit transition.
  Users will be stuck in this overlay.

يُطلق هذا الخطأ في وقت التصريف. قبل النشر. قبل ضمان الجودة. قبل المستخدمين.

2. سرعة التطوير تزداد

يُصرَّف تطبيق كامل مع Almadar — واجهة أمامية، واجهة خلفية، قاعدة بيانات، واجهة برمجية — من ملف schema (ملف يصف التطبيق بالكامل) واحد:

orbital compile invoice-app.orb --shell typescript -o app/

يستغرق تطبيق CRUD نموذجي، الذي يستغرق 2-4 أسابيع تقليديًا، أيامًا بنهج الـ schema أولًا. يتعامل الكود المُولَّد مع التوجيه وإدارة الحالة ونقاط API ونماذج قاعدة البيانات.

3. الامتثال يصبح تلقائيًا

للصناعات المنظمة، الـ schema هو المواصفة:

{
  "from": "InProgress",
  "to": "Completed",
  "event": "COMPLETE",
  "guard": ["and",
    ["=", "@entity.allFieldsFilled", true],
    [">=", "@entity.inspectorSignatures", 2]
  ]
}

لا يستطيع المفتش إكمال تقرير بدون ملء جميع الحقول وتوقيعين. هذا ليس اقتراحًا في دليل تدريب — إنه مفروض من قبل النظام.

لا يحتاج المدققون مراجعة الكود. إنهم يراجعون الـ schema — مستند JSON قابل للقراءة هو النظام.

4. التأهيل يستغرق ساعات، لا أسابيع

لا يحتاج المطورون الجدد فهم آلاف الأسطر من React و Express و Redux. إنهم يقرأون الـ schema:

تخبرهم الـ entities (الكيانات — نماذج البيانات) ما هي البيانات الموجودة
تخبرهم الحالات ما يمكن للتطبيق فعله
تخبرهم الـ transitions كيف ينتقل بين الحالات
تخبرهم الـ guards بقواعد العمل
تخبرهم الـ effects (العمليات التي تُنفَّذ عند كل transition) ما يحدث عند كل انتقال

يعتبر الـ schema بمثابة التوثيق. وهو دائمًا دقيق لأنه هو النظام الذي يعمل.

مثال واقعي: نظام تفتيش حكومي

قمنا ببناء نظام تفتيش ميداني للاستخدام الحكومي. النهج التقليدي: 6 أشهر، 5 مطورين، إدارة سير عمل معقدة.

مع Almadar:

5 مراحل تفتيش مُمثّلة كحالات (المقدمة، المحتوى، التحضير، التسجيل، الختام)
المتطلبات القانونية مُشفّرة كـ guards (لا يمكن الإغلاق بدون جميع الحقول الإلزامية)
سجل المراجعة مدمج في الـ state machine (كل transition يُسجَّل)
توليد المستندات يُطلق كـ effects عند transition الختام

يولد الـ schema من 400 سطر تطبيق ويب كاملًا مع واجهة برمجية خلفية ونماذج قاعدة بيانات وواجهة مستخدم للمفتشين.

متى لا تناسب الـ state machines

لا تصلح الـ state machines لكل شيء:

مواقع المحتوى الصرف (المدونات، صفحات الهبوط) — لا حالة معقدة
البرامج النصية لمرة واحدة — لا تستحق الهيكل
النماذج الأولية الاستكشافية للغاية — أحيانًا تحتاج اكتشاف ما تبنيه أولًا

لكن لـأي تطبيق به سير عمل، نماذج، موافقات، عمليات متعددة الخطوات، أو أدوار مستخدمين — وهو معظم برمجيات الأعمال — تقضي الـ state machines على فئات كاملة من الأخطاء.