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