نوسازی برای نوآوری؛ چگونه معماری‌های قدیمی را بدون یک بازنویسی پرخطر متحول کنیم؟

عنوان سخنرانی: Renovate to Innovate: Fundamentals of Transforming Legacy Architecture
ترجمه عنوان: نوسازی برای نوآوری؛ مبانی تحول معماری‌های قدیمی
سخنران: Rashmi Venugopal
همایش: QCon San Francisco 2024
مدت ویدئو: ۳۰ دقیقه و ۵۵ ثانیه
لینک ویدئو: https://youtu.be/brHepv_JNNg?si=GyCpb_SuZ1v1PleS

وقتی اصطلاح «سیستم قدیمی» یا Legacy System را می‌شنویم، معمولا سیستمی فرسوده، ناکارآمد و پر از بدهی فنی را تصور می‌کنیم که باید هرچه سریع‌تر کنار گذاشته شود. اما قدیمی‌شدن یک سیستم همیشه نشانه طراحی بد یا شکست تیم فنی نیست. گاهی یک سیستم دقیقا به این دلیل به Legacy تبدیل می‌شود که در گذشته موفق بوده، مدت زیادی مورد استفاده قرار گرفته و کسب‌ و کار از توانایی‌های اولیه آن فراتر رفته است. سخنران تاکید می‌کند که سیستم‌های قدیمی، تا حدی محصول طبیعی موفقیت و رشد سازمان هستند؛ مسئله اصلی این نیست که چرا چنین سیستم‌هایی به وجود آمده‌اند، بلکه این است که آیا سازمان توانایی نوسازی آن‌ها را دارد یا اجازه می‌دهد مانع رشد آینده شوند.

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

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

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

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

برای اجرای موفق نوسازی، نخستین راهکار سخنران استفاده از معماری تکاملی است. در این رویکرد، معماری از ابتدا یک ساختار کامل و تغییرناپذیر در نظر گرفته نمی‌شود، بلکه با تغییر نیازهای کسب‌ و کار تکامل پیدا می‌کند. تیم ابتدا باید شاخص‌هایی قابل‌ اندازه‌گیری برای ویژگی‌های مهم سیستم، مانند کارایی، مقیاس‌پذیری، امنیت یا نگهداری‌پذیری، تعریف کند. سپس تغییرات به‌ صورت کوچک انجام شوند، مرتب منتشر شوند و نتیجه آن‌ها با این معیارها ارزیابی شود. تحویل مداوم و حلقه‌های بازخورد نیز کمک می‌کنند تیم بدون انجام یک مهاجرت بزرگ و یک‌باره، مسیر خود را به‌تدریج اصلاح کند.

راهبرد دوم با عبارت «ابتدا کاری کن که کار کند، سپس درستش کن و در نهایت سریعش کن» توضیح داده می‌شود. در مرحله اول، هدف اثبات امکان‌ پذیر بودن راه‌حل و ساخت یک نمونه اولیه است؛ نه رسیدن به کدی بی‌نقص. در مرحله دوم، تست‌ها، حالت‌های مرزی و معیارهای کیفی بررسی می‌شوند و راه‌حل به یک محصول حداقلی قابل‌استفاده تبدیل می‌شود. مرحله سوم نیز فقط به افزایش سرعت اجرای برنامه مربوط نیست؛ مستندسازی، تحویل مداوم، مانیتورینگ و مشاهده‌ پذیری نیز در این مرحله قرار می‌گیرند، زیرا سرعت توسعه و عملیات تیم را افزایش می‌دهند. به نظرم، این تقسیم‌بندی از گرفتارشدن تیم در کمال‌گرایی و تحلیل بیش‌ از حد جلوگیری می‌کند و یک پروژه بزرگ نوسازی را به نقاط عطف قابل‌ کنترل تبدیل می‌سازد.

سومین راهکار، توسعه مبتنی بر کنارگذاری یا Deprecation-Driven Development است. معمولا در پروژه‌های نرم‌افزاری موفقیت با تعداد قابلیت‌های جدید سنجیده می‌شود، درحالی‌که حذف کدها، فناوری‌ها و قابلیت‌های کم‌ارزش نیز می‌تواند به همان اندازه مهم باشد. سخنران پیشنهاد می‌کند پیش از انتقال تمام قابلیت‌های سیستم قدیمی، ارزش واقعی هرکدام بررسی شود. اگر هزینه نگهداری یا مهاجرت یک قابلیت بیشتر از ارزش تجاری آن باشد، شاید بهترین تصمیم حذف آن باشد. مثال پایان سرویس DVD نتفلیکس نشان می‌دهد که کنارگذاشتن آگاهانه یک محصول می‌تواند اولویت‌های مهندسی را روشن کند و از ادامه سرمایه‌گذاری روی بخشی که دیگر با آینده کسب‌ و کار هماهنگ نیست، جلوگیری کند.

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

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

در مجموع، برداشت من این است که هدف نوسازی، ساختن معماری‌ای کاملا جدید و بدون نقص نیست؛ بلکه آزادکردن سیستم و سازمان از محدودیت‌هایی است که سرعت نوآوری را کاهش داده‌اند. یک نوسازی موفق باید تدریجی، قابل‌اندازه‌گیری و هماهنگ با نیازهای واقعی کسب‌وکار باشد. همچنین باید بپذیریم سامانه‌ای که امروز مدرن محسوب می‌شود، ممکن است در آینده به یک سیستم Legacy تبدیل شود؛ بنابراین مهم‌تر از انتخاب یک فناوری خاص، ایجاد توانایی دائمی برای یادگیری، تغییر و نوسازی است.

منابع

• ویدئوی رسمی سخنرانی Renovate to Innovate :
  https://youtu.be/brHepv_JNNg?si=GyCpb_SuZ1v1PleS

• ویدئو و متن کامل سخنرانی در InfoQ :
  https://www.infoq.com/presentations/scale-payments

• صفحه رسمی سخنرانی در QCon San Francisco 2024 :
  https://qconsf.com/presentation/nov2024/renovate-innovate-fundamentals-transforming-legacy-architecture

• مقاله سخنران درباره تحول معماری‌های قدیمی در InfoQ :
  https://www.infoq.com/articles/fundamentals-of-transforming-legacy-architecture

اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است 🌱