چگونه تصمیم میگیریم چه زمانی بازسازی (Refactor) کنیم و چه زمانی بازنویسی (Rewrite) کنیم
هر توسعهدهندهای با این لحظه روبرو میشود.
پایگاه کد (Codebase) کند است. اضافه کردن ویژگیهای جدید خیلی طول میکشد. نیروهای جدید برای درک سیستم با مشکل مواجه هستند. در نهایت، کسی پیشنهاد بازنویسی کامل (Full rewrite) را میدهد.
تیم معمولاً به دو گروه تقسیم میشود. یک گروه میخواهد از صفر شروع کند. گروه دیگر از شکست بازنویسیهای گذشته میترسد. هر دو طرف استدلالهای معتبری دارند.
بازنویسی یک راهکار جادویی نیست. اغلب بیشتر از آنچه برنامهریزی شده زمان میبرد. در نهایت مجبور میشوید همزمان از دو سیستم نگهداری کنید. حتی ممکن است همان اشتباهات را در نسخه جدید تکرار کنید.
بازنویسی در این موارد خاص منطقی است:
• مدل دادهها اساساً برای کسبوکار اشتباه است. • تکنولوژی منسوخ شده و هیچ بهروزرسانی امنیتی ندارد. • نیازهای کسبوکار چنان تغییر کردهاند که سیستم اصلی از رده خارج شده است. • هیچکس در تیم فعلی نمیداند سیستم چگونه کار میکند.
حتی در این صورت هم، از جایگزینی یکباره (big bang replacement) استفاده نکنید. از الگوی strangler fig استفاده کنید. سیستم جدید را قطعه به قطعه در کنار سیستم قدیمی بسازید.
در بیشتر مواقع، شما در واقع به بازسازی (Refactor) نیاز دارید.
بازسازی (Refactoring) زمانی انتخاب درستی است که:
• هنوز هم بتوانید ویژگیهای جدید اضافه کنید، حتی اگر این کار کند باشد. • تیم کد فعلی را درک میکند. • آشفتگی محدود به ماژولهای خاصی است. • کسبوکار نمیتواند عرضه ویژگیهای جدید را متوقف کند.
قبل از انتخاب، بپرسید چرا کد بد شده است.
اگر مشکل بدهی فنی (technical debt) است، بدترین بخشها را بازسازی کنید. اگر مشکل کمبود بازبینی کد (code review) یا فرهنگ ضعیف است، بازنویسی کمکی نخواهد کرد. شما فقط با همان عادتهای قدیمی، یک آشفتگی جدید خواهید ساخت.
قبل از تصمیمگیری، این سوالات را بپرسید:
• آیا میتوانیم بدترین بخشها را به صورت مجزا اصلاح کنیم؟ • آیا مدل دادهها برای نیازهای فعلی کسبوکار مشکل دارد؟ • اگر از نو شروع کنیم، چه دانشی را از دست خواهیم داد؟ • آیا کسبوکار پایداری لازم برای مدیریت یک دوره انتقال طولانی را دارد؟
شروع دوباره حس خوبی دارد. اما تمام کردن بازنویسی، بخش سخت ماجراست. در بیشتر مواقع، یک برنامه بازسازی ساختاریافته، ایمنتر و مؤثرتر است.
Source: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk