فصل پانزدهم: هنر منسوخ کردن و حذف سیستم‌های قدیمی

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

کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل پانزدهم به موضوع منسوخ‌سازی (deprecation) می‌پردازد و نشان می‌دهد که چگونه باید با برنامه‌ریزی درست، سیستم‌های قدیمی را بازنشسته کرد تا پیچیدگی سیستم کاهش یابد.

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

ایدهٔ دوم این است که چرا منسوخ‌سازی اصلاً کار سختی است. مشکل قانون هایروم (Hyrum’s Law) است که می‌گوید وقتی یک سیستم کاربران زیادی دارد، آن‌ها ناخواسته به روش‌هایی از آن استفاده می‌کنند که اصلاً پیش‌بینی نشده است. گزینه‌های پیش رو یا دست نزدن به سیستم است یا حذف کامل آن. مبادله این است که حذف یک رفتار قدیمی، وابستگی‌های پنهان را به هم می‌ریزد. برای نمونه، در گوگل گاهی مهندسان به دلیل تعلق خاطر عاطفی در برابر حذف کدهایی که خودشان نوشته‌اند مقاومت می‌کنند، در حالی که نگهداری کدهای منسوخ هزینهٔ خالص برای سازمان دارد.

ایدهٔ سوم تفاوت میان منسوخ‌سازی توصیه‌ای (advisory deprecation) و اجباری (compulsory deprecation) است. در روش توصیه‌ای، به کاربران اطلاع داده می‌شود که سیستم جدیدی آمده است اما مهلتی تعیین نمی‌شود. مشکل این است که «امید، استراتژی نیست» و کاربران به ندرت داوطلبانه مهاجرت می‌کنند. گزینه‌ها این است که یا به امید کاربران بمانیم یا مهلت مشخصی تعیین کنیم. مبادله این است که روش توصیه‌ای ملایم است اما نتیجه نمی‌دهد، در حالی که روش اجباری نیازمند اختصاص تیم تخصصی برای کمک به مهاجرت کاربران است. به عنوان مثال، اگر بدون تخصیص نیرو به تیم‌ها بگوییم باید سیستم خود را عوض کنند، فقط اصطکاک و نارضایتی ایجاد کرده‌ایم.

ایدهٔ چهارم اهمیت اخطارها و ابزارهای مناسب است. مشکل این است که انباشت اخطارهای منسوخ‌سازی باعث خستگی کاربران از هشدارها (alert fatigue) می‌شود؛ پدیده‌ای که در آن هشدارها آن‌قدر زیاد می‌شوند که افراد کلاً آن‌ها را نادیده می‌گیرند. گزینه‌ها شامل گذاشتن هشدار روی همه چیز یا استفاده هدفمند از تحلیل ایستا (static analysis) است. مبادله این است که ابزارهای خودکار باید هشدارها را دقیقاً در زمان مناسب و فقط به خطوط تازه تغییریافته اعمال کنند. به عنوان مثال، سامانهٔ Tricorder در گوگل هشدار استفاده از کدهای منسوخ را دقیقاً هنگام بازبینی کد نشان می‌دهد و راه جایگزین را پیشنهاد می‌کند.

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

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