اگر دو نفر یک سفارش یا پرونده را هم‌زمان ویرایش کنند، نرم‌افزار نباید تغییر نفر اول را بی‌صدا با نسخه قدیمی نفر دوم جایگزین کند. مدیریت تعارض ویرایش هم‌زمان یعنی سامانه تغییر وضعیت از زمان بازشدن فرم تا لحظه ذخیره را تشخیص دهد، نوشته کاربر را حفظ کند و مسیر روشنی برای تصمیم درباره اختلاف‌ها ارائه دهد. پیام «ذخیره شد» فقط وقتی مفید است که کاربر بداند چه چیزی واقعاً ذخیره شده است.
این مسئله فقط مربوط به سامانه‌های بزرگ نیست. دو زبانه مرورگر، یک اتصال به نرم‌افزار دیگر یا پردازش خودکار پس‌زمینه هم می‌توانند روی همان داده اثر بگذارند. در این راهنما، مسئله را از دید مدیر محصول و خریدار نرم‌افزار سفارشی بررسی می‌کنیم: چه رفتاری باید سفارش داده شود، کدام تفاوت‌ها نیازمند تصمیم انسانی هستند و پیش از تحویل پروژه چه آزمون‌هایی لازم است.
تغییرات چگونه بدون هشدار گم می‌شوند؟
در یک مثال فرضی، کارشناس فروش و مسئول ارسال هر دو یک سفارش را باز می‌کنند. کارشناس فروش توضیح مشتری را اصلاح و ذخیره می‌کند. مسئول ارسال چند دقیقه بعد آدرس را تغییر می‌دهد، اما فرم او هنوز توضیح قدیمی را دارد. اگر ذخیره تمام فرم بدون کنترل نسخه انجام شود، توضیح تازه می‌تواند دوباره با متن قدیمی جایگزین شود؛ حتی اگر مسئول ارسال آن قسمت را لمس نکرده باشد.
کاربران معمولاً این اتفاق را به فراموشی همکار یا ذخیره‌نشدن فرم نسبت می‌دهند. مسئله اصلی، تعریف ناقص رفتار سامانه هنگام رقابت چند تغییر است. ترتیب رسیدن درخواست‌ها به سرور لزوماً نشان نمی‌دهد کدام تصمیم کسب‌وکار درست‌تر است. «آخرین ذخیره برنده است» یک سیاست است، نه نتیجه‌ای که باید بدون اطلاع تیم به آن تن داد.
تعارض با سطح دسترسی و تاریخچه فرق دارد
سطح دسترسی تعیین می‌کند چه کسی اجازه ویرایش دارد؛ کنترل هم‌زمانی مشخص می‌کند ویرایش مجاز چگونه با تغییر جدید شخص دیگر برخورد کند. ممکن است هر دو نفر کاملاً مجاز باشند اما نسخه‌های متفاوتی از داده را ببینند. محدودکردن دسترسی همه به یک نفر، همیشه پاسخ عملی مناسبی نیست و می‌تواند کار تیم را معطل کند.
تاریخچه نیز پس از وقوع اتفاق کمک می‌کند، اما به‌تنهایی جلوی بازنویسی را نمی‌گیرد. راهنمای ردپای حسابرسی نرم‌افزار برای ثبت تغییر و تصمیم مفید است؛ بااین‌حال سامانه باید قبل از پذیرفتن ذخیره ناسازگار، وضعیت را بررسی کند. پیشگیری و امکان بررسی بعدی، دو لایه مکمل‌اند و نباید یکی را جای دیگری فروخت.
کنترل نسخه؛ سؤال ساده پیش از ذخیره
ایده اصلی این است: آیا داده‌ای که کاربر هنگام شروع ویرایش دیده، هنوز همان نسخه جاری است؟ سامانه همراه رکورد یک شناسه نسخه دریافت می‌کند و هنگام ذخیره آن را با وضعیت معتبر مقایسه می‌کند. اگر نسخه تغییر کرده، به‌جای بازنویسی بی‌صدا، اختلاف به مسیر تعیین‌شده هدایت می‌شود. شکل دقیق شناسه به معماری وابسته است و لازم نیست برای کاربر نهایی پیچیده نمایش داده شود.
در HTTP، استاندارد RFC 9110 درباره If-Match یکی از سازوکارهای درخواست شرطی برای جلوگیری از بازنویسی ناخواسته را توضیح می‌دهد. این سازوکار تنها یک نمونه فنی است؛ صرف افزودن یک هدر یا فیلد در صفحه کافی نیست. سمت سرور باید شرط را به‌درستی اجرا کند و برنامه مسیر قابل فهمی برای نتیجه ناسازگار داشته باشد.
بررسی و ثبت باید به هم وابسته باشند
اگر برنامه ابتدا نسخه را بخواند و مدتی بعد بدون شرط ذخیره کند، ممکن است تغییر دیگری در فاصله این دو رخ دهد. تیم فنی باید نشان دهد بررسی نسخه و پذیرش تغییر چگونه از این فاصله آسیب نمی‌بینند. این موضوع جزئیات نمایشی نیست؛ بخشی از تضمینی است که نرم‌افزار درباره نگهداری اطلاعات می‌دهد و باید با آزمون هم‌زمان بررسی شود.
بعد از تشخیص تعارض چه چیزی به کاربر نشان دهیم؟
پیام کلی «خطا رخ داد» کاربر را به زدن دوباره دکمه ذخیره سوق می‌دهد. پیام بهتر توضیح می‌دهد که رکورد از زمان بازشدن فرم تغییر کرده و نوشته فعلی کاربر هنوز محفوظ است. گزینه‌های بعدی باید روشن باشند: مشاهده نسخه تازه، مقایسه اختلاف‌ها، انتخاب مقدار نهایی یا کنارگذاشتن آگاهانه تغییرات خود. تازه‌سازی اجباری صفحه نباید پیش‌نویس را نابود کند.
برای مقایسه قابل اتکا، سه وضعیت اهمیت دارد: مقداری که کاربر ابتدا دیده، مقداری که خودش نوشته و مقدار جاری سامانه. فقط مقایسه دو نسخه آخر همیشه نشان نمی‌دهد هر طرف واقعاً کدام قسمت را تغییر داده است. رابط لازم نیست همه فیلدها را یک‌جا نمایش دهد؛ می‌تواند روی قسمت‌های تغییرکرده تمرکز کند و بقیه را برای مشاهده اختیاری نگه دارد.
از رنگ به‌تنهایی استفاده نکنید
برچسب‌های «نسخه اولیه»، «تغییر شما» و «نسخه جاری» باید مستقل از رنگ قابل تشخیص باشند. در فرم فارسی، چینش راست‌به‌چپ و اعداد ترکیبی هم باید خوانا بمانند. اگر مقدار طولانی است، امکان دیدن متن کامل بدهید. حذف بخشی از متن در نمایش مقایسه می‌تواند تصمیم اشتباه ایجاد کند، حتی اگر کنترل نسخه در پشت صحنه درست کار کند.
چه تغییرهایی را می‌توان ادغام کرد؟
تغییر دو فیلد جدا گاهی قابل ادغام است، اما جدا بودن ظاهری کافی نیست. آدرس و روش ارسال ممکن است به هم وابسته باشند. تغییر تعداد و تخفیف نیز می‌تواند نتیجه محاسبه را عوض کند. ادغام خودکار باید بر اساس قواعد واقعی همان رکورد انجام شود، نه صرفاً اینکه نام ستون‌ها متفاوت‌اند. هر قاعده ادغام باید قابل توضیح و آزمودنی باشد.
برای فیلدی که هر دو طرف تغییر داده‌اند، معمولاً باید اختلاف دیده شود. انتخاب همیشگی مقدار جدیدتر یا طولانی‌تر، معنای کسب‌وکار را نمی‌فهمد. حتی ابزار هوش مصنوعی که پیشنهاد ترکیب متن می‌دهد، نباید بدون سیاست روشن درباره مقدار حساس تصمیم نهایی بگیرد. پیشنهاد باید قابل بررسی باشد و منبع هر بخش مشخص بماند.
یادداشت افزایشی با ویرایش مشترک فرق دارد
اگر نیاز واقعی ثبت یادداشت‌های مستقل است، شاید بهتر باشد هر یادداشت رکورد جداگانه داشته باشد و کاربران یک متن واحد را بازنویسی نکنند. این انتخاب مدل داده می‌تواند تعارض غیرضروری را کم کند. البته اصلاح یا حذف یادداشت هم قواعد خود را می‌خواهد. هدف، تغییر معماری همه سامانه نیست؛ فقط باید روشن شود آیا اصلاً یک فیلد مشترک، مدل مناسب مسئله بوده است یا نه.
قفل ویرایش چه زمانی مفید است؟
گاهی سازمان ترجیح می‌دهد یک نفر در یک زمان روی بخش مشخص کار کند. در این الگو، نرم‌افزار باید مالک قفل، محدوده آن و رفتار هنگام قطع اتصال را روشن کند. اگر کاربر لپ‌تاپ را ببندد، رکورد نباید برای همیشه غیرقابل ویرایش بماند. همچنین آزادکردن قفل توسط مدیر باید دلیل و سابقه داشته باشد، نه اینکه یک راه مخفی برای دورزدن کنترل باشد.
قفل طولانی می‌تواند تجربه تیم را بدتر کند؛ کنترل نسخه نیز ممکن است در بخش‌های پرتعارض پیام‌های زیادی بسازد. انتخاب میان این روش‌ها به الگوی استفاده بستگی دارد. برای بعضی فرایندها ترکیب محدود قفل و کنترل نسخه مناسب است. از تأمین‌کننده بخواهید انتخاب را با نمونه واقعی تیم شما توضیح دهد، نه با ادعای اینکه یک روش همیشه برتر است.
کار آفلاین و اتصال‌های دیگر را فراموش نکنید
کاربری که آفلاین کار کرده ممکن است ساعت‌ها بعد تغییرات را بفرستد. برنامه باید پیش‌نویس محلی را از ذخیره معتبر سرور جدا نشان دهد. هنگام اتصال مجدد، همان قواعد نسخه و تعارض لازم‌اند. نمایش «ذخیره شد» برای اطلاعاتی که فقط روی دستگاه مانده‌اند، تصور نادرستی درباره دسترسی همکاران به داده ایجاد می‌کند.
همین کنترل باید برای API، ورود فایل و پردازش‌های پس‌زمینه نیز بررسی شود. اگر فقط فرم مرورگر نسخه را کنترل کند، اتصال خارجی هنوز می‌تواند تغییر تازه را بازنویسی کند. البته همه مسیرها لازم نیست یک رابط یکسان داشته باشند؛ ولی سیاست مالکیت داده و برخورد با نسخه قدیمی باید سازگار باشد و مورد ناسازگار بی‌صدا حذف نشود.
حل تعارض هم به مجوز نیاز دارد
دیدن نسخه جاری یا انتخاب مقدار نهایی نباید راهی برای مشاهده داده خارج از دسترسی کاربر شود. اگر سطح دسترسی در فاصله بازشدن فرم تا ذخیره تغییر کرده، سامانه باید دوباره مجوز را بررسی کند. کنترل نسخه جای کنترل دسترسی را نمی‌گیرد. راهنمای دسترسی مبتنی بر نقش برای تعریف نقش‌ها و محدوده مجاز ویرایش مکمل این بحث است.
در موارد حساس، ممکن است کاربر فقط بتواند اختلاف را گزارش کند و تصمیم نهایی با مسئول دیگری باشد. این مسیر باید مالک و وضعیت مشخص داشته باشد تا گزارش تعارض به صف فراموش‌شده تبدیل نشود. سابقه تصمیم بهتر است نشان دهد چه مقادیری بررسی شدند و چرا نتیجه نهایی انتخاب شد، با رعایت سیاست نگهداری و محرمانگی داده.
آزمون پذیرش را با دو کاربر واقعی اجرا کنید
برای شروع، دو نشست جدا یک رکورد را باز کنند. نفر اول ذخیره کند و نفر دوم با نسخه قدیمی تغییر دیگری بفرستد. بررسی کنید تغییر نخست گم نشده، پیش‌نویس دوم حفظ شده و پیام قابل فهم است. سپس حالتی را آزمایش کنید که هر دو همان فیلد را تغییر می‌دهند. این دو سناریو الزاماً نباید نتیجه یکسان داشته باشند.
آزمون را به دو کاربر محدود نکنید. بعد از نمایش صفحه مقایسه، یک تغییر سوم وارد کنید و ببینید تصمیم کاربر بر پایه نسخه منقضی پذیرفته نمی‌شود. همچنین حذف رکورد، تغییر مجوز، قطع شبکه و ارسال از دو زبانه یک مرورگر را امتحان کنید. آزمون موفق فقط نبودن خطای برنامه نیست؛ حفظ درست اطلاعات و روشن‌بودن تصمیم بعدی است.
معیار موفقیت را قبل از تحویل بنویسید
معیارهای عملی شامل جلوگیری از بازنویسی خاموش، نگهداری پیش‌نویس تا تصمیم کاربر، نمایش اختلاف مرتبط و ثبت نتیجه حل تعارض‌اند. تعداد تعارض‌ها به‌تنهایی شاخص بدی نیست؛ گاهی سامانه تازه، مشکلات قبلاً پنهان را آشکار می‌کند. برای سنجش بهبود، موارد ازدست‌رفتن تغییر و زمان رفع اختلاف را با خط مبنای واقعی مقایسه کنید و درصد ساختگی تعیین نکنید.
جمع‌بندی و قدم بعدی
نرم‌افزار چندکاربره باید اختلاف را مدیریت کند، نه اینکه آن را با آخرین ذخیره پنهان کند. طراحی مناسب از شناخت نسخه اولیه، حفظ نوشته کاربر و تعریف قواعد ادغام شروع می‌شود. سپس باید رفتار API، کار آفلاین، مجوزها و تغییر سوم در هنگام حل اختلاف نیز بررسی شود. این قابلیت بخشی از اعتماد به اطلاعات است، نه صرفاً یک پیام خطای بهتر.
برای شروع، یک فرم پرتکرار و چند نمونه اختلاف واقعی تیم را انتخاب کنید. تعیین کنید کدام فیلدها مستقل‌اند، کدام تغییرها نیازمند بررسی هستند و چه کسی تصمیم نهایی می‌گیرد. برای طراحی این رفتار در سامانه موجود یا پروژه جدید، از خدمات نرم‌افزار سفارشی ایزی‌ساز استفاده کنید تا معیار پذیرش از ابتدا به مسئله واقعی کاربران متصل باشد.