هنگام حفظ و بهبود سیستم های مهندسی، سازمان ها اغلب با یک تصمیم حیاتی مواجه می شوند: آیا آنها باید اجزای موجود را دوباره فعال کنند یا آنها را به طور کامل بازنویسی کنند؟ درک تفاوت ها، مزایا و معایب هر رویکرد برای تصمیم گیری شما ضروری است.

درک Refactoring

بازسازی شامل بهبود تدریجی سیستم های موجود بدون تغییر عملکرد اصلی آن است.هدف آن افزایش کیفیت کد، خوانایی و قابلیت نگهداری در حالی که حفظ رفتار سیستم است که اغلب برای کاهش بدهی های فنی و سیستم های آماده سازی برای توسعه آینده استفاده می شود.

بهبود های رفتاری و بوی کد

بازسازی معمولاً هدف " رایحه های کد" را هدف قرار می دهد – شاخص های سطحی که معمولاً با مشکلات عمیق تر در سیستم مطابقت دارند، نمونه ها شامل کد تکراری، روش های طولانی، کلاس های بزرگ و اتصال بیش از حد است.با حذف سیستماتیک این بوها، تیم ها می توانند کد را به صورت ماژولار و ابزار تست پذیر تر کنند مانند تجزیه و تحلیل کنندگان و قابلیت های بازسازی IDE (به عنوان مثال، Rename، روش استخراج خودکار) کمک بسیاری از این تحول.

وقتی که Refactor

بازسازی موثرترین زمانی است که سیستم موجود هنوز به طور ساختاری صدا است، اما بدهی فنی معتدل را جمع آوری کرده است، همچنین مناسب است که منطق کسب و کار پیچیده و به خوبی درک شده است، به عنوان بازنویسی خطر از دست دادن دانش دامنه سخت به دست آمده است. تیم هایی که به طور مداوم به عنوان بخشی از چرخه توسعه خود عمل می کنند (به عنوان مثال، "قانون پیشاهنگ") پیدا کردن کد سالم و اصلاح ضعیف است.

درک Rewriting

از سوی دیگر، بازنویسی شامل توسعه یک سیستم جدید از ابتدا یا به طور قابل ملاحظه ای اصلاح کننده در حال حاضر است، این روش معمولا زمانی انتخاب می شود که سیستم فعلی منسوخ شده، بسیار پیچیده است یا دیگر نیازهای کسب و کار را برآورده نمی کند. Rewriting می تواند یک شروع تازه را ارائه دهد، اجازه می دهد تا معماری مدرن و فن آوری ها به اجرا گذاشته شود، با این حال، همچنین به معنای دور زدن سال های رفع اشکالات، بهینه سازی، و دانش نهادی در کد قدیمی است.

Greenfield vs. Brownfield Rewrites

بازنویسی گرین فیلد با یک تخته سفید شروع می شود، ساخت سیستم در یک محیط کاملا جدید، این اغلب زمانی اتفاق می افتد که پلت فرم اصلی منسوخ شده است (به عنوان مثال، مهاجرت از Cobol به جاوا) یا زمانی که سیستم باید به طور کامل دوباره برای مقیاس پذیری دوباره مورد استفاده قرار گیرد. A Brownfield بازنویسی قطعات سیستم موجود را جایگزین می کند در حالی که دیگران در حال اجرا هستند - گاهی اوقات به عنوان یک الگوی مهاجرت ساده است.

وقتی برای بازنویسی

بازنویسی توجیه می شود زمانی که سیستم فعلی به نقطه ای رسیده است که بازسازی آن بیش از بازسازی قیمت داشته باشد.شاخص ها عبارتند از: پایه کد قابل آزمایش نیست، معماری مانع تغییرات لازم می شود (به عنوان مثال، نمی تواند به صورت افقی مقیاس پذیر باشد)، یا پشته تکنولوژی دیگر پشتیبانی نمی شود. سناریوی دیگر زمانی است که مدل کسب و کار به طور چشمگیری تغییر کرده است تا سیستم میراث نتواند بدون استفاده از یک الگوی استراتژیک جدید، سازگار شود.

مقایسه ریسک ها و هزینه ها

هر دو رویکرد پروفایل ریسک متمایز و ساختارهای هزینه ای را انجام می دهند. درک این کمک می کند تا تیم ها انتخاب خود را با تحمل ریسک سازمانی و چرخه های بودجه هماهنگ کنند.

عوامل خطر

ریسک های جبران کننده: بزرگترین خطر این است که بازسازی هرگز تمام نمی شود - چرخه بی پایان پیشرفت های کوچک می شود در حالی که مشکلات اساسی سیستم ادامه دارد، خطر دیگر "خرسندی برگشت پذیر" است، جایی که تیم انگیزه از دست می دهد زیرا پیشرفت کند و نامرئی است.

ریسک های بازنویسی: مشهورترین هشدار از مقاله جوئل Spolsky (FLT:2) چیزهایی که هرگز نباید انجام دهید، بخش I ، که او استدلال می کند که بازنویسی اغلب منجر به حمل یک باگ، جایگزین ویژگی ضعیف سال های برنامه ریسک (سیستم های مبادله ای) می شود، و ممکن است در سیستم های دیگر ریسک (سیستم های انتقال) از دست رفته و سیستم های انتقال اطلاعات بیشتر (در حال انتظار می رود.

تحلیل هزینه

بازسازی هزینه ها در طول زمان گسترش می یابد.مطالعه توسط موسسه مهندسی نرم افزار نشان داد که تعمیر یک نقص پس از انتشار هزینه 10 تا 100x بیشتر از تعمیر آن در طول طراحی - اما بازسازی دوباره باعث می شود بسیاری از نقص ها در اوایل با بهبود وضوح کد، بازنویسی نیاز به یک سرمایه گذاری بزرگ دارد: شما نیاز به re-analyze، طراحی مجدد، کد مجدد، و دوباره همه چیز را کاهش می دهد (T) به طور واقعی بازنویسی یک سیستم عامل مجوز، مگر اینکه یک بار دیگر یک بار دیگر یک سیستم عامل مجدد مجوز، یک بار دیگر می تواند از آن استفاده کند.

چارچوب تصمیم گیری برای رهبران مهندسی

انتخاب بین بازسازی و بازنویسی به عوامل مختلفی مانند پیچیدگی سیستم، اولویت های کسب و کار، منابع موجود و اهداف بلند مدت بستگی دارد. چارچوب تصمیم زیر می تواند به ارزیابی وضعیت خاص شما کمک کند.

سیستم ارزیابی سلامت

تجزیه و تحلیل سیستماتیک از کد پایه با استفاده از معیارهایی مانند پیچیدگی سیکلواتیک، پوشش کد، اتصال و چگالی نقص انجام دهید. Tools مانند SonarQube یا CodeClimate می تواند داده های عینی را ارائه دهد.اگر سیستم در حفظ قابلیت عملکرد ضعیف باشد، منطق کسب و کار پایدار است، بازسازی ممکن است به اندازه کافی باشد.اگر معماری اساسا ناقص باشد (به عنوان مثال، مونوlithic که نمی تواند یک اسپاگتی را بازنویسی کند).

اهداف تجاری Alignment

نقشه تصمیم فنی برای نتایج کسب و کار.اگر هدف سرعت بخشیدن به تحویل ویژگی در سه ماهه بعدی است، بازسازی معمولا امن تر است.اگر هدف این است که وارد بازار جدیدی شود که نیاز به عملکرد یا ویژگی های مقیاسی کاملا متفاوت دارد، بازنویسی می تواند توجیه شود. وارد کردن صاحبان محصول و ذینفعان برای روشن کردن "چرا" به عنوان مثال، یک استارت آپ ممکن است انتخاب کند به سرعت بازنویسی، در حالی که یک سیستم عامل با سیستم های خرابی بحرانی ترجیح می دهد تا از پس انداز رشد مجدد جلوگیری کند.

توانایی تیم و دانش سازمانی

بازسازی به شدت بر درک سیستم موجود متکی است.اگر نویسندگان اصلی هنوز بر تیم هستند، بازسازی کارآمد تر است.اگر کد پایه یک جعبه سیاه با مستندات کوچک است، یک بازنویسی ممکن است وسوسه انگیز به نظر برسد - اما خطر تکرار اشتباهات گذشته را در آن مورد، یک "نوشتن با حفظ" را در نظر بگیرید: ساخت سیستم جدید به طور موازی، اما قوانین کسب و کار را قبل از خواندن کد قدیمی و دقت از خواندن کد قدیمی حذف کنید.

مثال های واقعی-World

بررسی اینکه چگونه سازمان های دیگر این انتخاب را هدایت کرده اند می تواند بینش عملی ارائه دهد.

مثال: بازسازی پایگاه کمپ HEY

هنگامی که در حال توسعه سرویس ایمیل HEY، تیم Basecamp تصمیم به بازسازی کد پایه ریل های موجود به جای بازنویسی از ابتدا گرفتند، آنها به طور سیستماتیک منطق دامنه را به اشیاء خدمات استخراج کردند، پوشش تست بهبود یافته و کد مرده را حذف کردند، این به آنها اجازه داد تا محصول را در زمان نگه داشتن کد قابل نگهداری، ارسال کنند.

مثال: کتاب های تازه نوشته شده

کتاب های تازه، یک شرکت نرم افزاری حسابداری، به طور مشهور کل پلت فرم خود را از یک برنامه PHP یکپارچه به یک سیستم مدرن و مقیاس پذیر بازسازی می کند، تصمیم پس از سالها مبارزه با عملکرد و محدودیت های معماری که بازسازی ساختار لازم را حل کرد، تغییر مسیر فنی بیش از 2 سال و هزینه دهها میلیون دلار، اما آنها را قادر به خدمت به مشتریان بزرگتر و پشتیبانی از چیزی که ما تا به حال به آن اشاره نکرده ایم، اما مهم است.

مثال: مارتین فلاولر بازسازی جامعه

مارتین فالر، نویسنده کتاب نیمه داخلی بازسازی: بهبود طراحی کد موجود ، مدتها است که برای بازسازی مجدد بازنویسی مجدد حمایت می شود، او استدلال می کند که اکثر سیستم ها می توانند به طور فزاینده بهبود یابند اگر تیم ها در تست خودکار و ادغام مداوم خود سرمایه گذاری کنند. refactor] [F3] الگوهای اولیه ای که نشان می دهد که هیچ دیدگاهی از Fowler نیست.

نتیجه گیری: انتخاب درست

هر دو بازسازی و بازنویسی جایگاه خود را در مدیریت سیستم مهندسی دارند.ارزیابی دقیق از وضعیت خاص سازمان ها را به سمت موثرترین استراتژی هدایت می کند، ریسک، هزینه و آمادگی آینده را متعادل می کند: بخش هایی که نجات می یابند و تنها اجزایی را که فراتر از تعمیر هستند بازنویسی می کنند.از چارچوبی که در اینجا برای ارزیابی سلامت کد شما مشخص شده است، با اهداف رشد سریع تر و پشتیبانی از طریق مدیریت مجدد سیستم های آگاهانه، و اصلاح سیستم های پشتیبانی کارآمد تر، استفاده می کنند.