در بخش قبلی درباره چالش های دپریکیت کردن سیستم ها صحبت کردیم. متوجه شدیم چرا وابستگی های پنهان و استفاده های پیش بینی نشده از سیستم های قدیمی، فرایند حذف آن ها را پیچیده می کند. همچنین به اهمیت برنامه ریزی دقیق، تعیین زمان بندی مشخص، و مدیریت منابع برای موفقیت این فرایند اشاره کردیم و مثال هایی از تجربه گوگل در مدیریت تدریجی دپریکیشن را داشتیم.
بخش دوم: https://vrgl.ir/IHsVP
دپریکیت کردن سیستم ها یک فرایند واحد نیست و شامل طیفی از رویکردها می باشد. این فرایند می تواند از «امیدواریم روزی این سیستم را خاموش کنیم» تا «فردا این سیستم به طور کامل از دسترس خارج می شود، مشتریان آماده باشند» متغیر باشد. به طور کلی می توان آن را به دو دسته اصلی تقسیم کرد:
Advisory Deprecation
در این رویکرد، هیچ مهلت یا اجبار مشخصی برای کنار گذاشتن سیستم قدیمی مشخص نمی شود و معمولا منابع محدودی برای آن اختصاص داده می شود. این روش بیشتر برای معرفی سیستم های جدید و تشویق کاربران در شرایطی که سیستم جدید قابلیت های بهتری ارائه می دهد مناسب است.
سیستم جدید باید از ابتدا آماده استفاده باشد و قابلیت پشتیبانی کافی و نامحدود را داشته باشد. ابزارهای سلف سرویس و اطلاع رسانی می توانند کاربران را برای مهاجرت تشویق کنند، اما تجربه نشان داده است که صرف هشدار دادن یا ارائه مزایای جزئی معمولا کافی نیست. سیستم قدیمی همچنان نیاز به نگهداری خواهد داشت، مگر اینکه برنامه های کامل تری برای تشویق کاربران به مهاجرت داشته باشیم.
Hope is not a strategy.
Compulsory Deprecation
در این روش تاریخ مشخصی برای حذف سیستم تعیین می شود و کاربران موظفند تا آن زمان به سیستم جدید مهاجرت کنند. اگر این مهاجرت انجام نشود، دسترسی کاربران به سیستم قدیمی قطع می شود. موفقیت این روش به تشکیل تیم های تخصصی، زمان بندی دقیق و اختصاص منابع کافی بستگی دارد.
یکی از نکات مهم در این فرایند، تعیین مکانیزم هایی برای اعمال قانون است. تیم مسئول باید اختیار کامل برای قطع دسترسی کاربران پس از اطلاع رسانی های کافی را داشته باشد. اما این فرایند نباید ظالمانه به نظر برسد و لازم است همراه با پشتیبانی مناسب انجام شود. برای مثال در گوگل از رویکردی تدریجی استفاده می شود که شامل قطعی های برنامه ریزی شده و افزایش تدریجی مدت این قطعی ها است. این روش به تیم ها کمک می کند وابستگی های خود را شناسایی و حذف کنند.
هشدارهای مرتبط با دپریکیت کردن چه در Advisory Deprecation و چه در Compulsory Deprecation ابزار مهمی برای علامت گذاری سیستم های قدیمی و تشویق آن ها به مهاجرت هستند. اما این هشدارها تنها زمانی موثر خواهند بود که به درستی طراحی شوند:
قابل اجرا: هشدار باید شامل راهکارهای عملی باشد که کاربران با مهارت متوسط نیز بتوانند آن را اجرا کنند.
زمان بندی مناسب: هشدار باید دقیقا زمانی نمایش داده شود که کاربر با موضوع مرتبط درگیر است، مانند هنگام کد نویسی یا استفاده از سیستم قدیمی.
اما باید مراقب باشیم که تعداد زیاد هشدارها منجر به کلافگی ناشی از هشدار نشود، چون این اتفاق باعث می شود کاربران نسبت به هشدارها بی تفاوت شوند. هشدارهای دقیق و به موقع می توانند سرعت مهاجرت را افزایش دهند، اما به تنهایی برای کاهش وابستگی به سیستم های قدیمی کافی نیستند و نیازمند اقدامات بیشتری هستند.
یکی از چالش های مهم در فرایند دپریکیشن، تعیین مالکیت برای پروژه های قدیمی است. اگر پروژه ای مالک مشخصی نداشته باشد، احتمال پیشرفت در فرایند دپریکیشن بسیار پایین خواهد بود، حتی اگر هشدارهای زیادی صادر شود. در سازمان های بزرگ معمولا پروژه هایی وجود دارند که همچنان استفاده می شوند اما مالک مشخصی ندارند. گاهی این وضعیت به دلیل انتقال مالک پروژه به سیستم های جایگزین رخ می دهد. بدون تعیین مالکیت پروژه ها در حالت تعلیق باقی می مانند و فرایند دپریکیشن دچار اختلال می شود.
منبع: کتاب Software Engineering at Google
