تبادل موازی

ایجاد تغییر در رابط کاربری که بر تمام مصرف کنندگان آن تأثیر می گذارد ، به دو حالت تفکر نیاز دارد: اجرای خود تغییر و سپس به روزرسانی تمام کاربردهای آن. این می تواند دشوار باشد وقتی که سعی می کنید هر دو را همزمان انجام دهید ، به خصوص اگر این تغییر در یک منتشر شده با مشتری های متعدد یا خارجی باشد.

تغییر موازی ، که به عنوان گسترش و قرارداد نیز شناخته می شود ، الگویی برای اجرای تغییرات سازگار با عقب در یک رابط به صورت ایمن ، با شکستن تغییر در سه مرحله مجزا است: گسترش ، مهاجرت و قرارداد.

برای درک این الگوی ، بیایید از نمونه ای از یک کلاس شبکه ساده استفاده کنیم که با استفاده از یک جفت مختصات عدد صحیح x و y اطلاعات در مورد سلولهای آن را ذخیره می کند و اطلاعاتی را در مورد سلولهای آن ارائه می دهد. سلول ها در داخل در یک آرایه دو بعدی ذخیره می شوند و مشتری ها می توانند از روش های AddCell () ، Fetchcell () و isempty () برای تعامل با شبکه استفاده کنند.

به عنوان بخشی از اصلاح مجدد ، ما تشخیص می دهیم که X و Y یک DataClump هستند و تصمیم می گیرند یک کلاس مختصات جدید را معرفی کنند. با این حال ، این یک تغییر به عقب سازگار با مشتریان کلاس شبکه خواهد بود. به جای تغییر همه روشها و ساختار داده داخلی به طور هم زمان ، تصمیم می گیریم الگوی تغییر موازی را اعمال کنیم.

در مرحله گسترش ، رابط را تقویت می کنید تا از نسخه های قدیمی و جدید پشتیبانی کنید. در مثال ما ، ما یک ساختار داده نقشه جدید و روش های جدید را معرفی می کنیم که می توانند بدون تغییر کد موجود ، نمونه های مختصات را دریافت کنند.

مشتری های موجود همچنان به مصرف نسخه قدیمی ادامه می دهند و تغییرات جدید را می توان به تدریج معرفی کرد بدون اینکه روی آنها تأثیر بگذارد.

در مرحله مهاجرت ، کلیه مشتری ها را با استفاده از نسخه قدیمی به نسخه جدید به روز می کنید. این کار می تواند به صورت تدریجی انجام شود و در مورد مشتری های خارجی ، این طولانی ترین مرحله خواهد بود.

پس از انتقال همه کاربردها به نسخه جدید ، شما مرحله قرارداد را برای حذف نسخه قدیمی و تغییر رابط کاربری انجام می دهید تا فقط از نسخه جدید پشتیبانی کند.

به عنوان مثال ، از آنجا که پس از حذف روش های قدیمی ، دیگر از آرایه داخلی دو بعدی استفاده نمی شود ، می توانیم با اطمینان از ساختار داده ها حذف کنیم و Newcells را به سلول تغییر دهیم.

این الگوی به ویژه در هنگام تمرین ادامه کار مفید است زیرا اجازه می دهد کد شما در هر یک از این سه مرحله آزاد شود. همچنین با اجازه دادن به مهاجرت مشتری و آزمایش نسخه جدید به صورت تدریجی ، خطر تغییر را کاهش می دهد.

حتی هنگامی که شما کنترل همه کاربردهای رابط را کنترل می کنید ، پیروی از این الگوی هنوز هم مفید است زیرا مانع از گسترش شکستگی در کل پایگاه کد می شود. مرحله مهاجرت می تواند کوتاه باشد ، اما جایگزینی برای تکیه بر کامپایلر برای یافتن تمام کاربردهای لازم برای رفع است.

برخی از برنامه های نمونه این الگوی عبارتند از:

• Refactoring: هنگام تغییر یک روش یا امضای عملکرد ، به خصوص هنگام انجام یک اصلاح طولانی مدت یا هنگام تغییر یک افسر منتشر شده. اجرای متنوع این الگوی در حین اصلاح مجدد ، اجرای روش قدیمی از نظر API جدید و استفاده از روش Inline برای به روزرسانی همه کاربردهای یکباره است. واگذاری روش قدیمی به روش جدید همچنین راهی برای شکستن مرحله مهاجرت به مراحل کوچکتر و ایمن تر است و به شما امکان می دهد قبل از تغییر API در معرض مشتری ، ابتدا اجرای داخلی را تغییر دهید. این زمانی مفید است که مرحله مهاجرت طولانی تر باشد ، بنابراین مجبور نیستید دو اجرای جداگانه را حفظ کنید.
• اصلاح دیتابیس: این یک مؤلفه اصلی برای طراحی پایگاه داده تکاملی است. اکثر اصلاحات پایگاه داده از الگوی تغییر موازی پیروی می کنند ، جایی که مرحله مهاجرت دوره انتقال بین طرح اصلی و جدید است ، تا اینکه تمام کد دسترسی به پایگاه داده برای کار با طرح جدید به روز شده است.
• استقرار: تکنیک های استقرار مانند نسخه های قناری و Bluegreendeployment برنامه هایی از الگوی تغییر موازی هستند که در آن شما نسخه های قدیمی و جدید از کد مستقر در کنار هم دارید و به طور تدریجی کاربران را از یک نسخه به نسخه دیگر مهاجرت می کنید ، بنابراین خطر تغییر را کاهش می دهیدبشردر یک معماری میکروسرویس ، همچنین می تواند به دلیل وابستگی به نسخه بین آنها ، نیاز به ارکستراسیون استقرار پیچیده خدمات مختلف را برطرف کند.
• از راه دور API Evolution: می توان از تغییر موازی برای تکامل یک API از راه دور (به عنوان مثال یک سرویس وب REST) استفاده کرد ، هنگامی که نمی توانید تغییر را به روشی سازگار با عقب انجام دهید. این یک جایگزین برای استفاده از یک نسخه صریح در API در معرض است. می توانید هنگام ایجاد تغییر در بار پذیرفته شده یا بازگشت توسط API در یک نقطه انتهایی معین ، الگوی را اعمال کنید ، یا می توانید یک نقطه پایانی جدید را معرفی کنید تا بین نسخه های قدیمی و جدید تمایز قائل شوید. در مورد استفاده از تغییر موازی در همان نقطه پایانی ، پیروی از قانون Postel یک تکنیک خوب برای جلوگیری از شکستن مصرف کنندگان در هنگام گسترش بار است.

در مرحله مهاجرت ، می توان از FeatureToggle برای کنترل کدام نسخه از رابط استفاده کرد. یک تغییر ویژگی در سمت مشتری اجازه می دهد تا با نسخه جدید تأمین کننده سازگار باشد ، که انتشار تأمین کننده از مشتری را جدا می کند.

هنگام اجرای BranchbyAbstraction ، تغییر موازی راهی مناسب برای معرفی لایه انتزاع بین مشتری و تأمین کننده است. همچنین یک روش جایگزین برای انجام یک تغییر در مقیاس بزرگ بدون معرفی لایه انتزاع به عنوان درز برای جایگزینی در سمت تأمین کننده است. با این حال ، هنگامی که تعداد زیادی مشتری دارید ، استفاده از شاخه با انتزاع یک استراتژی بهتر برای محدود کردن سطح تغییر و کاهش سردرگمی در مرحله مهاجرت است.

نکته منفی استفاده از تغییر موازی این است که در مرحله مهاجرت ، تأمین کننده باید از دو نسخه مختلف پشتیبانی کند و مشتری می تواند در مورد اینکه کدام نسخه جدید در مقابل قدیمی است ، گیج شوند. اگر مرحله قرارداد اجرا نشود ، ممکن است در وضعیت بدتری از آنچه شروع کرده اید به پایان برسید ، بنابراین برای اتمام انتقال با موفقیت به نظم و انضباط نیاز دارید. افزودن یادداشت های استهلاک ، مستندات یا یادداشت های TODO ممکن است به اطلاع رسانی به مشتریان و سایر توسعه دهندگان که روی همان پایگاه کد کار می کنند ، کمک کند که در مورد کدام نسخه در حال تعویض است.

بیشتر خواندن

Refactoring Album Industrial Logic را اسناد می کند و نمونه ای از انجام یک تغییر موازی را نشان می دهد.

سپاسگزاریها

این تکنیک برای اولین بار به عنوان یک استراتژی بازپرداخت توسط جوشوا کریسکی در سال 2006 ثبت شد و در گفتگوی خود انجمن محدود قرمز ارائه شده در کنفرانس نرم افزار و سیستم های Lean در سال 2010 ارائه شد.

با تشکر از جوشوا کریسکی به خاطر بازخورد در مورد اولین پیش نویس این پست. همچنین به لطف بسیاری از همکاران TukeWorks بخاطر بازخورد خود: گرگ داتچر ، بدرینات جاناکیرامان ، پرافیک تادکار ، ریک کاراگر ، فیلیپه اسپرندیو ، جیسون یپ ، تووشار مادوکار ، پیت هاجسون و کیف موریس.