فصل بیست‌ودوم: تغییرات بزرگ در کدهای عظیم

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

این مسائل و روش‌های حل آن‌ها در کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل تغییر در مقیاس بزرگ (Large-Scale Change) به تفصیل بررسی شده‌اند و اهمیت این موضوع را در نگهداری سیستم‌های نرم‌افزاری نشان می‌دهند.

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

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

سومین ایده کلیدی به چالش‌های تست کردن مربوط می‌شود. اجرای تست‌ها برای تغییرات بزرگ بسیار زمان‌بر است و سیستم‌های یکپارچه‌سازی پیوسته (Continuous Integration) زیر بار سنگینی می‌روند. گزینه‌های موجود شامل اجرای تک‌تک تست‌ها یا نادیده گرفتن بخش‌هایی از آن‌هاست، اما معاوضه اصلی میان دقت تست و سرعت توسعه شکل می‌گیرد. گوگل برای حل این مسئله از قطاری موسوم به پلتفرم اتوماسیون تست TAP train استفاده می‌کند که در آن تغییرات تاییدشده با هم ترکیب می‌شوند تا مجموعه تست‌های مرتبط به صورت دسته‌ای و با بهینه‌سازی زمان اجرا بررسی شوند.

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

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

امیدوارم این مرور کوتاه به شما ایده داده باشد که چگونه می‌توان کدهای بزرگ را بدون ترس و با کمک ابزارهای مناسب در طول زمان همگام و انعطاف‌پذیر نگه داشت.