نجات پروژهٔ نیمه‌کاره: بازنویسی کنیم یا ترمیم؟ چطور بدون عجله تصمیم بگیریم
برنامه‌نویس قبلی رفته، کد نیمه‌کاره است و سیستم کند و شکننده شده. اولین وسوسه «همه‌چیز را از اول بنویسیم» است. این نوشته می‌گوید اول چه چیزی را باید بررسی کنی، سه مسیر چه هزینه‌ای دارند و چطور در یک روز بفهمی کدام برای تو درست است.
این وضعیت برای بیشتر کسانی که چند سال نرم‌افزار سفارش داده‌اند آشناست: برنامه‌نویس قبلی رفته یا قابل‌دسترس نیست، سیستم کار می‌کند ولی کند و شکننده است، هر تغییر ساده یک چیز دیگر را خراب می‌کند، و کسی دقیقاً نمی‌داند چرا.
وسوسهٔ اول تقریباً همیشه یکی است: «بیاییم همه‌چیز را از اول بنویسیم، تمیز.» گاهی درست است. اغلب نه. و فهمیدن اینکه کدام است، یک روز بررسی می‌خواهد، نه یک هفته بحث.
اول: ببین دقیقاً چه چیزی داری
قبل از هر تصمیمی، فهرست «موجودی» بساز. اگر چیزی از این فهرست کم است، همین الان مهم‌ترین کار است:
- کد منبع: کجاست؟ آیا نسخهٔ کاملی از آن، با تاریخچهٔ تغییرات، دست توست؟
- دیتابیس: پشتیبان دارد؟ آخرین بار کِی گرفته شده؟ آیا کسی تا حالا بازیابی‌اش را آزموده؟
- دسترسی‌ها: سرور، دامنه، حساب درگاه پرداخت، حساب پیامک، سرویس‌های ابری. به نام چه کسی هستند؟
- مستندات: هر چیزی نوشته شده؟ حتی یک فایل متنی دربارهٔ اینکه چطور اجرا می‌شود.
- سیستم زنده: الان کجا اجرا می‌شود و کاربرها واقعاً با آن کار می‌کنند؟
اگر پشتیبانی از دیتابیس نداری، قبل از هر چیز دیگری یکی بگیر. بازنویسی و ترمیم هر دو می‌توانند به داده‌ها آسیب بزنند، و داده چیزی است که جایگزین ندارد.
سه مسیر
۱. ترمیم: همین را درست کنیم
کد را نگه می‌داری، مشکل‌ها را یکی‌یکی پیدا و رفع می‌کنی، چیزهای ضروری را تست می‌گذاری و کم‌کم سیستم را قابل‌اعتماد می‌کنی.
وقتی درست است: سیستم اصولاً کار می‌کند و مشکل‌هایش مشخص و محدودند: چند صفحهٔ کند، چند اشکال تکراری، کمبود تست. ساختارش قابل‌فهم است، فقط شلوغ شده.
۲. بازنویسی تدریجی: تکه‌تکه جایگزین کن
سیستم قدیمی را نگه می‌داری و هر بار یک بخش را با نسخهٔ تازه عوض می‌کنی، در حالی که کار ادامه دارد. کاربرها هیچ وقت وقفه‌ای نمی‌بینند و هر مرحله ارزش قابل‌دیدنی دارد.
وقتی درست است: بخش‌هایی از سیستم واقعاً بد هستند ولی بقیه‌اش قابل‌قبول؛ یا وقتی نمی‌توانی سیستم را برای ماه‌ها متوقف کنی. این معمولاً بهترین توازن است، هرچند در ظاهر جذابیت «از اول» را ندارد.
۳. بازنویسی کامل
ساخت یک سیستم جدید از صفر، و روزی که آماده شد، جابه‌جایی.
وقتی درست است: پایهٔ کار ایراد اساسی دارد (مدل داده‌ای که نمی‌شود اصلاح کرد، تکنولوژی منسوخ‌شده‌ای که دیگر کسی بلد نیست)، یا سیستم آن‌قدر کوچک است که بازنویسی‌اش ارزان است. و فقط وقتی که کسی کاملاً بفهمد سیستم قدیمی چه می‌کند، چون بازنویسی یعنی دوباره فهمیدن هر قاعدهٔ کوچکی که سال‌ها داخل کد نشسته.
چرا بازنویسی کامل معمولاً گران‌تر درمی‌آید
سیستم قدیمی، با همهٔ زشتی‌اش، چیزی را دارد که سیستم تازه ندارد: سال‌ها بازخورد از کاربرهای واقعی. داخل آن کد زشت، صدها تصمیم کوچک پنهان است: «اگر مشتری این‌طور بود، آن کار را بکن»، «این فیلد گاهی خالی است». هیچ‌کدام مستند نیستند، و در بازنویسی باید دوباره پیدا شوند، معمولاً از راه اشکال‌هایی که کاربرها گزارش می‌دهند.
این یعنی بازنویسی کامل هیچ‌وقت «فقط ساخت» نیست؛ «ساخت به‌علاوهٔ یادگیری مجدد همهٔ قواعد قدیمی» است. این را می‌شود در برآورد منظور کرد، ولی اغلب فراموش می‌شود.
چطور در یک روز بفهمی کدام مسیر
از یک برنامه‌نویس بخواه (چه من، چه هر کس دیگر) یک بررسی یک‌روزه انجام بدهد و این‌ها را بگوید:
- سیستم در چه وضعی است؟ چند مشکل واقعی پیدا کرد و چقدر جدی؟
- آیا کد قابل‌فهم است، یا هر قطعه‌اش به همهٔ قطعه‌های دیگر وابسته است؟
- چه چیزهایی تست دارند؟ (اگر هیچ، هر تغییری ریسک است.)
- خطرهای امنیتی آشکار دارد؟ (نسخه‌های قدیمی کتابخانه‌ها، رمزهای داخل کد.)
- کدام مسیر را پیشنهاد می‌کند و چرا، و هزینه و ریسک هر کدام را چطور می‌بیند؟
خروجی این روز یک تخمین صادقانه است. اگر کسی بدون دیدن کد قیمت یک بازنویسی کامل را بگوید، به او شک کن.
اگر برنامه‌نویس قبلی در دسترس نیست
مهم‌ترین چیز، دسترسی‌هاست، نه رضایت. بررسی کن حساب‌های اصلی (دامنه، سرور، مخزن کد) به نام چه کسی هستند. اگر به نام او هستند و جواب نمی‌دهد، همین اولین ریسک بزرگ توست؛ قبل از هر کار فنی باید راهی برای کنترل آن‌ها پیدا کنی.
اگر قراردادی نوشته بودی، بند مالکیت و دسترسی‌ها را نگاه کن. اگر نبود، راهنمای قرارداد می‌گوید دفعهٔ بعد چه چیزی را از اول بنویسی.
ده سؤال هنگام تحویل‌گرفتن پروژه از کسی دیگر
- کد کامل و تاریخچه‌اش را داریم؟
- چطور روی کامپیوتر محلی اجرا می‌شود؟ (و آیا واقعاً اجرا می‌شود؟)
- چه سرویس‌های بیرونی دارد و حسابشان به نام کیست؟
- رمزها و کلیدها کجا نگه‌داری می‌شوند؟ داخل کد نیستند؟
- دیتابیس چه ساختاری دارد و پشتیبان آن چقدر قدیمی است؟
- چه کارهایی خودکار و زمان‌بندی‌شده انجام می‌شود؟
- آخرین بار کِی روی سرور به‌روزرسانی امنیتی انجام شد؟
- چه اشکال‌های شناخته‌شده‌ای هست که کسی هنوز درستش نکرده؟
- چه چیزی در سیستم هست که فقط برنامه‌نویس قبلی می‌دانست؟
- اگر امشب سرور خراب شود، چقدر طول می‌کشد دوباره بالا بیاید؟
اگر برای چند تا از این‌ها جواب نداری، پروژه‌ات الان به‌جای برنامه‌نویس، به یک آدم احتیاج دارد که این‌ها را روشن کند؛ و هنوز زمان انتخاب بین ترمیم و بازنویسی نرسیده.
جمع‌بندی
پروژهٔ نیمه‌کاره معمولاً یک فاجعه نیست؛ یک موجودی ناروشن است. اول روشنش کن، داده‌ها را پشتیبان بگیر، بعد بین ترمیم، بازنویسی تدریجی و بازنویسی کامل انتخاب کن، و تا وقتی بررسی نشده، هیچ‌کدام را قطعی نکن. اگر در همین وضعیتی هستی، بنویس چه داری و چه اذیتت می‌کند؛ ویزارد بریف پروژه گزینهٔ «نجات پروژهٔ نیمه‌کاره» را هم دارد و اولین قدم همان بررسی است.