نویسنده، پروژهی Legacy رو پروژهی موجودی که توسعه و نگهداری از اون سخت باشه تعریف میکنه. صحبت از Codebase به تنهایی نیست و جنبه‌های مختلفی- از جمله اسکریپت‌ها و ابزارهای build پروژه ، وابستگی بین سیستم‌ها، زیرساختی که نرم‌افزار روی اون اجرا میشه، مستندات پروژه و روش‌های ارتباطی بین توسعه‌دهنده‌ها یا بین توسعه‌دهنده‌ها و Stakeholderها - رو در برمیگیره و همه‌ی این فاکتورها با هم در کیفیت و Maintainability یک پروژه نقش دارند.
ویژگی‌های مشترک پروژه‌هایی که Legacy محسوب میشن:
قدمت معمولا هر پروژه‌ای به زمان نیاز داره تا به جایی برسه که نگهداری از اون دیگه واقعا سخت بشه. تا اون زمان هم توسعه‌دهنده‌های زیادی برای نگهداری از پروژه میان و میرن و در خلال این جابجایی‌ها دانش طراحی اولیه‌ی سیستم و اهدافی که توسعه‌دهنده‌ی قبلی برای نگهداری داشته هم از بین میره.
وسعت ناگفته پیداست که هر چقدر ابعاد پروژه بزرگ‌تر باشه، نگهداری از اون سخت‌تره. ◦◦ وجود کد بیشتر برای درک کردن | باگ بیشتر برای برطرف کردن | احتمال بالاتر رخ دادن Regression ◦◦ همچنین سایز پروژه روی تصمیمات مرتبط با نگهداری هم تاثیر میذاره، هرچی پروژه بزرگ‌تر باشه، جایگزینی اون سخت‌تر و پرریسک‌تره و پتانسیل بیشتری برای Legacy شدن داره.
از دیگری به ارث رسیدن همینطوری که از معنی عمومی کلمه‌ی Legacy برمیاد، چنین پروژ‌هایی معمولا از تیم یا توسعه‌دهنده‌های قبلی به ارث رسیدن. به عبارت دیگه، آدمهایی که کد اورجینال رو نوشتن با آدمهایی که از اون کد نگهداری میکنن یکی نیستن. چه بسا بین این دو، توسعه‌دهنده‌های مختلفی هم اومده و رفته باشن. معنی‌ش این میشه که هیچ راهی وجود نداره که آدم‌های فعلی بفهمن این کد چرا اینطوری کار میکنه و غالباً مجبورن اهداف و مفروضات ضمن طراحیِ آدمهایی که این کد رو نوشتن رو حدس بزنن.
مستندات ضعیف به دلیل اینکه پروژه نسل‌های متعددی از توسعه‌دهنده‌ها رو به خودش دیده، وجود مستندات دقیق و کامل به بقای طولانی‌مدت پروژه کمک زیادی میکنه. و متاسفانه تنها چیزی که ما توسعه‌دهنده‌ها بیشتر از داکیومنت نوشتن ازش بدمون میاد، آپدیت نگه‌داشتن اونه.
و میگه از اینکه اگر یه پروژه‌ای مشمول این ویژگی‌ها باشه،لزوما Legacy نیست و مثال این مورد پروژهی Kernel لینوکسه. از سال 1991 در حال توسعه‌ست، و سایز پروژه بزرگه اما به این وجود از کیفیت بسیار بالایی برخورداره و نویسنده یکی از دلایل این حجم از کیفیت رو فرهنگ ارتباط باز و بی‌پرده اونها میدونه که در این فرهنگ هر تفییری در کد، Review و با این کار موجب به اشتراک‌گذاری اطلاعات بین توسعه‌دهنده‌ها میشه.
حالا از کدِ Legacy میگیم و از فاکتورهایی که یک کد رو Legacy میکنه:
کد تست نشده و غیرقابل تست (صدای گریه‌ی حضار) همه‌مون میدونیم که مستندات فنی برای پروژه‌ها یا معمولا وجود ندارن، یا اگه وجود دارن قابل اعتماد نیستن.در این شرایط تست‌ها بهترین مکان برای پیدا کردن سرنخ‌ها در مورد رفتار سیستم و مفروضات طراحیه. تست خوب، چون با رفتار فعلی سیستم سینک نگه‌داشته میشه میتونه از مستندات هم بهتر باشه. یک توسعه‌دهنده‌ی مسئولیت‌پذیر حواسش به فیکس کردن تست‌هایی که بر اثر تغییراتش در کد Fail ، Production شده هست! و خبر بد اینکه بسیاری از پروژه‌های Legacy، تست که ندارن هیچ، با ذهنیت تست هم نوشته نشده‌اند و این موضوع اضافه کردن تست به این پروژه‌ها رو سخت‌تر میکنه.
کد انعطاف‌ناپذیر یکی از مشکلات رایج یک کد Legacy اینه که پیاده‌سازی فیچر جدید، یا تغییر دادن رفتار فعلی توش سخته. یک تغییر کوچیک باعث ویرایش کردن کد در خیلی جاهای دیگه میشه و هر کدی که ادیت بشه هم باید دوباره (بله! غالباً به صورت دستی) تست بشه.
کدی که بخاطر بدهی فنی دست‌وپا‌گیر شده هر توسعه‌دهنده‌ای بخاطر نوشتن کدی که خودش هم میدونه Perfect نیست، اما برای حالا خوبه فعلا مقصره. که البته معمولا رویکرد درستیه. داشتن کدی که کار میکنه بهتر از هیچیه. اما هر باری که یک کد برای حالا خوبه فعلا رو به پروژه اضافه می‌کنید، باید برنامه‌ای بچینید تا یه زمانی که فرصت بیشتری داشتید دستی به سر روش بکشید. هر راه حل موقتی‌ای، کیفیت Overallی پروژه رو کاهش میده و کار آینده رو سخت‌تر میکنه. میگه به بدهی فنی مثل یه وام نگاه کنید که بازپرداخت اون Refactoringه. و با یک مثال از سرنوشت شرکتی میگه که توسعه‌دهنده‌هاش در ابتدای پروژه ذهنیت مقیاس‌پذیری رو هنگام انتخاب دیتابیس نداشتند و وقتی که اقبال بهشون رو کرد و کاربرانشون از مقیاس هزار به میلیون رسید، با چاره‌اندیشی‌های موقتی سعی کردند پرفورمنس رو بالا نگه دارن و فیچر جدید توسعه بدن و در نهایت پس شد آنچه شد :))
در قسمت بعدی، به جنبه‌های دیگه‌ای که روی Legacy شدن پروژه موثر هستن می‌پردازیم و فصل مقدماتی رو تموم میکنیم.
