ضمانات التحرير المتزامن: العمل على النموذج نفسه دون أن يمحو أحدكما عمل الآخر

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

المشكلة في عملية حفظ بسيطة

عملية حفظ تكتفي بالكتابة فوق ما هو مخزَّن أصلاً، أي عملية «upsert» بسيطة، تعمل جيداً مع محرِّر واحد. أما مع أكثر من محرِّر، فليس لديها وسيلة لملاحظة أن الصف تغيّر تحتها بين لحظة تحميله ولحظة حفظه. عملية الكتابة الثانية ليست خاطئة في ذاتها؛ إنها فقط تفتقد إلى تعديلات الشخص الأول، وتبدو مطابقة تماماً لعملية حفظ عادية وناجحة. وقد وجد فريق Rexfin هذا النمط بعينه في قائمة التوظيف، حيث كان بإمكان محرِّرَين يعملان على الخطة نفسها أن يمحو أحدهما تعديلات الآخر عبر نقطة الحفظ دون أن يترك ذلك أي أثر.

كيف تكتشف Rexfin ذلك

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

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

أبعد من نموذج واحد

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

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

أين يقع هذا داخل مساحة العمل

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