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