بناء التعاون الفوري في تطبيقك المُنشأ بالذكاء الاصطناعي (دون كسر عمل الآخرين)

ماذا يحدث عندما يُعدّل شخصان التطبيق نفسه في الوقت نفسه؟

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

أنشأ أحد المستخدمين قائمة مهام مشتركة مع فريقه. بعد ظهر يوم جمعة، فتحها زميلان في الفريق في الوقت نفسه. كلاهما رأى:

• المهمة 1: البقالة
• المهمة 2: الاتصال بالأم
• المهمة 3: جدولة اجتماع

وضع الزميل أ علامة إتمام على “البقالة”. أضافت الزميلة ب “إصلاح الراوتر”. ثم ضغط كلاهما على حفظ.

عندما أعاد الزميل أ تحميل الصفحة، رأى:

• المهمة 1: البقالة (مكتملة)
• المهمة 2: الاتصال بالأم
• المهمة 3: جدولة اجتماع

اختفت “إصلاح الراوتر”. ضاع عمل الزميلة ب.

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

ما هي أكثر أخطاء التعاون الفوري شيوعًا؟

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

العطل الأول: الكتابة المفقودة (فقدان بيانات صامت)

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

قصة حقيقية: منظّمة أعراس ومساعدتها تعملان على قائمة الضيوف. تضيف المساعدة ثلاثة تأكيدات حضور بينما تضع المنظِّمة علامة “نهائي” على اثنين منها. تختفي علامات المنظِّمة. لا يلاحظ أحد ذلك حتى تُكرر المنظِّمة العدّ في مكالمات المتابعة، فتدعو من جديد أشخاصًا وافقوا على الحضور بالفعل.

تحل معظم التطبيقات الحقيقية هذه المشكلة بحفظ كل ضغطة مفتاح، لا الاكتفاء بالضغط على “حفظ”. تفعل Google Sheets وNotion وFigma ذلك جميعًا. يحتاج تطبيقك إلى هذا السلوك أيضًا.

العطل الثاني: التحديث القديم (رؤية بيانات قديمة)

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

قصة حقيقية: خبير تسوية تأمين ومقاول يعملان على مطالبة تأمينية. يُغيّر الخبير “تكلفة الإصلاح المقدَّرة: 3,000 دولار” إلى “5,000 دولار” استنادًا إلى صور جديدة. لا تزال صفحة المقاول تعرض 3,000 دولار. فيُقدّم نموذج موافقة بمبلغ 3,000 دولار. لاحقًا، يكتشفان التعارض.

بدون تحديثات فورية، يظن كلا الشخصين أنهما يعملان على النسخة نفسها. لكنهما لا يعملان عليها.

العطل الثالث: التناقض المتسلسل (حقيقتان)

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

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

كيف تُصلح أخطاء التعاون الفوري؟

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

الإصلاح الأول: اكتشاف تعارضات الكتابة (الحفظ التدريجي)

اجعل كل تغيير يُحفظ فورًا، لا الاكتفاء بالضغط على “حفظ”. هذا هو الإصلاح الأهم.

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

• يصل تغيير الشخص أ أولًا.
• يصل تغيير الشخص ب ثانيًا.
• يفوز الشخص ب (الكتابة الأخيرة تفوز).

هذا قاسٍ لكنه صادق: سيرى شخص واحد على الأقل أن تغييره لم يُحفظ، ويمكنه إعادة إجرائه.

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

الإصلاح الثاني: التحديث دون فقدان التعديلات المحلية

إذا كنت تستطلع قاعدة البيانات كل 5 ثوانٍ (أو تدفع التحديثات عبر WebSocket)، ادمج البيانات الجديدة دون سحق تعديلات المستخدم الحالية.

الطريقة الخاطئة: إعادة تحميل الصفحة بأكملها. تختفي كل التعديلات المحلية.

الطريقة الصحيحة: حدّث فقط الحقول التي لا يُعدّلها المستخدم حاليًا. إن كان يكتب في العنوان، لا تلمسه. وإن لم يكن يلمس تاريخ الاستحقاق، حدّثه من الخادم.

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

الإصلاح الثالث: أظهر الحقيقة بوضوح

عندما يكون هناك تعارض أو بيانات قديمة، أظهره. لا تُخفه.

أمثلة:

• “حُذفت هذه المهمة من قِبل شخص آخر. تراجع؟”
• “أضاف شخص ما ثلاثة عناصر إلى هذه القائمة أثناء كتابتك. [شاهد ما الجديد]”
• “أنت تنظر إلى نسخة من قبل دقيقتين. أعد التحميل لرؤية الأحدث.”

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

كيف يبدو التعاون الفوري عندما يُحَل بالكامل؟

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

1. كل ضغطة مفتاح تُحفظ فورًا — لا تنتظر زرًا.
2. تُحَل التعارضات بقاعدة ثابتة — إذا عدّلنا كلانا الكلمة نفسها، يختار النظام فائزًا (عادةً تفوز الكتابة الأخيرة، أو تحصل على رسالة تعارض).
3. تصل التحديثات فورًا — عبر WebSocket أو Server-Sent Events أو قاعدة بيانات تدفع التحديثات (مثل Firebase).

لا تحتاج معظم التطبيقات إلى هذا منذ اليوم الأول. ابدأ بالحفظ التدريجي (الإصلاح الأول). أضف الاستطلاع والدمج (الإصلاح الثاني) عندما يستخدمه شخصان في الوقت نفسه. أضف الدفع الفوري فقط إذا كانت التعارضات تسبب ألمًا حقيقيًا.

كيف تختبر التعاون الفوري قبل الإطلاق؟

أجرِ ثلاثة اختبارات في نافذتي متصفح قبل الإطلاق: اختبار الحفظ المتزامن، واختبار البيانات القديمة، واختبار إعادة التحميل. لكل منها نتيجة نجاح أو فشل واضحة.

الاختبار 1: اختبار الحفظ المتزامن

• افتح تطبيقك في نافذتي متصفح.
• في النافذة 1، عدّل الحقل X واحفظ.
• في النافذة 2، عدّل الحقل Y واحفظ فورًا بعد ذلك.
• أعد تحميل النافذتين.
• نجاح: كلا التعديلين موجودان. فشل: اختفى أحد التعديلين.

الاختبار 2: اختبار البيانات القديمة

• افتح التطبيق في النافذة 1. لا تلمسه.
• في النافذة 2، غيّر شيئًا كبيرًا (أضف/احذف صفًا، غيّر عنوانًا).
• عد إلى النافذة 1 (لا تزال تعرض البيانات القديمة).
• حاول تعديل النسخة القديمة في النافذة 1.
• نجاح: تحصل على تحذير أو يتم الدمج بسلاسة. فشل: تكتب فوق تغيير النافذة 2.

الاختبار 3: اختبار إعادة التحميل

• اجعل لديك عملًا فعليًا قيد التنفيذ (نموذج مملوء جزئيًا، رسالة مسودة).
• أعد تحميل الصفحة.
• نجاح: عملك لا يزال موجودًا. فشل: اختفى.

هل يجب أن تحفظ عند كل ضغطة مفتاح أم تنتظر زر الحفظ؟

احفظ عند كل ضغطة مفتاح. هذا القرار الوحيد يقطع بك 80% من الطريق نحو التعاون الفوري — كل ما تبقى هو جعله مرئيًا والتعامل مع التصادمات.

يتوقع المستخدمون هذا الآن. Gmail وGoogle Docs وSlack — كل تطبيق حديث يفعل ذلك. ينبغي لتطبيقك أن يفعله أيضًا.

الشيء الوحيد الذي تبدأ به: اجعل كل تغيير يُحفظ تلقائيًا. اعرض مؤشرًا صغيرًا (“جارٍ الحفظ…” ثم يختفي). راقب ما يحدث عندما يُعدّل شخصان في الوقت نفسه. إذا اختفى تغيير أحدهما، فهذا هو إصلاحك التالي. مشكلة واحدة في كل مرة أفضل من محاولة بناء تعاون مثالي منذ اليوم الأول.