فصل اول کتاب با یه مقدمه‌ی آشنا شروع میشه:
میگه تصور کنید یه روز صبح میرید سرکار، قهوه‌تون رو میریزید، و سری به بلاگ‌های تکنولوژی میزنین و شروع به خوندن یه مقاله از فلان شرکت میکنید که اونها چطوری زبان برنامه‌نویسی X رو با پایگاه داده‌ی Y و ابزار داده‌ی Z ترکیب کردن تا دنیا رو زیر و رو کنند و وقتی میفهمین که شما حتی «زمان» برای امتحان کردن هیچ یک از این تکنولوژیها توی پروژه خودتون رو ندارید، چه برسه به اینکه از اونها برای بهبود محصول‌تون استفاده کنید قلبتون هزار تیکه میشه. چرا؟ چون که وظیفه‌ی ناجذابِ نگهداری از بی‌نهایت خط کدِ بدون تستِ داکیومنت نشده‌ی غیر قابل درکِ Legacy به شما سپرده شده. این کد قبل از اینکه شما اولین خطِ کدِ !Hello World خودتون رو بنویسید تو Production بوده و ده‌ها توسعه‌دهنده اومدن و رفتن. نصف روز کاری رو صرف Review کردن Commitها میکنید تا یک وقت منجر به پسرفت و شکست نشه و نصف دیگه به برطرف کردن Bug میگذره و دردناک‌ترین قسمت ماجرا اینجاست که هر چی زمان میگذره و کد بیشتری به این Codebase شکننده اضافه میشه، اوضاع بد و بدتر میشه.
در ادامه میفرمایند که ناامید نشین! اول از همه یادتون باشه که تنها نیستین. نصف توسعه‌دهنده‌ها بیشتر زمان‌شون رو صرف دست و پنجه نرم کردن با کد موجود میکنن تا نوشتن کد جدید ، و اکثریت قریب به اتفاق توسعه‌دهنده‌ها هم مجبورن به نحوی با نوعی از کد Legacy سر و کله بزنن. دوم اینکه، صرف نظر از اینکه چقدر در نظر اول بعید به نظر بیاد، اما همیشه امیدی برای احیا کردن یک پروژه‌ی Legacy هست. و این کتاب - Re-Engineering Legacy Software نوشته‌ی Chris Birchall - دقیقا با همین هدف نوشته شده.
در فصل اول و مقدماتی، به بیان نمونه مشکلاتی که سعی در حل کردن اونها داره می‌پردازه و طرحی برای دمیدن روح تازهای در کالبد بی‌جان پروژه‌ی Legacy میریزه و از این میگه که کلا Legacy چیه و در چه سطوحی دیده میشه و مظاهر و مصادیق اون چیه.
و در آخر، من تصمیم گرفتم گزیده‌ای از این کتابِ جذاب رو با شما به اشتراک بذارم.
قسمت بعد | در باب خصوصیات پروژه‌ای که آن را Legacy می‌نامیم | قسمت اول |
