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

Refactoring در برنامه نویسی چیست؟

ریفکتورینگ یا Refactoring در برنامه نویسی به فرآیند بازسازی یا بازساخت کد گفته می‌شود به طوری که عملکرد اصلی آن تغییر نکند. هدف از Refactoring بهبود ساختار داخلی کد با ایجاد تغییرات کوچک بسیار (بدون تغییر رفتار خارجی کد) است. برنامه نویسان کامپیوتر کد را برای بهبود طراحی، ساختار و پیاده سازی نرم افزار بازسازی می‌کنند. بازسازی کد خوانایی کد را بهبود می‌بخشد و پیچیدگی‌ها را کاهش می‌دهد و همچنین می‌تواند به توسعه دهندگان نرم افزار کمک کند تا خطاها یا آسیب پذیری‌های پنهان در نرم افزار خود را پیدا کنند. بسیاری از محیط‌های ویرایش اولیه از بازسازی‌های ساده مانند تغییر نام یک تابع یا متغیر در کل سورس کد پشتیبانی می‌کنند. مارتین فاولر، که پدر Refactoring به حساب می‌آید، بسیاری از بهترین شیوه‌ها را از سراسر صنعت توسعه نرم‌افزار در فهرست خاصی از بازسازی‌ها ادغام کرد و روش‌هایی را برای پیاده‌سازی آنها در کتاب خود Refactoring: Improving the Design of Existing شرح داده است.

کد کثیف و Refactoring

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

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

هدف از Refactoring چیست؟

بازساخت کد دارای مزایای بسیاری است؛ از جمله:

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

چه زمانی باید از Refactoring استفاده کرد؟

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

چالش‌های استفاده از Refactoring چیست؟

با وجود تمام مزایای گفته شده، چالش‌هایی با فرآیند Refactoring همراه هستند. برخی از این موارد عبارتند از:

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

روش‌های مختلف Refactoring

سازمان‌ها می‌توانند از تکنیک‌های Refactoring در موارد مختلف استفاده کنند. این روشها عبارتند از:

• روش قرمز، سبز: این روش پرکاربرد بازسازی کد در توسعه Agile شامل سه مرحله است؛ ابتدا برنامه نویسان تعیین می‌کنند که چه چیزی باید توسعه یابد، سپس پروژه خود را تست کرده و در نهایت کد را مجددا اصلاح می‌کنند تا بهبود پیدا کند.

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

نکات استفاده از Refactoring  در برنامه نویسی

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

def student():
    getgrades()
    # details
    name = input()
    class = input() 

این کلاس را با استفاده از فرآیند Refactoring به صورت زیر نوشت:

def student():
    getgrades()
    getdetails()
def getdetails():
    name = input()
    class = input() 

در اینجا Refactoring در عملکرد کلی برنامه تاثیری نمی‌گذارد، اما باعث تمیزی و درک بهتر کد می‌شود. جزییات مربوط به هر دانشجو در  یک تابع مقداردهی می‌شود و یکدست بودن کد را حفظ می‌کند.

چه زمانی باید Refactoring را متوقف کرد؟

نقطه توقف مناسب برای دستیابی کد تمیز چیست؟ چک لیست زیر می‌تواند به شما کمک کند تا تعیین کنید چه زمانی کدتان تمیز است:

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

جمع بندی

در این مقاله درمورد Refactoring در برنامه نویسی صحبت کردیم. برای Refactoring باید برنامه ریزی درستی داشته باشید؛ در غیر این صورت ممکن است وقت گذاشتن برای Refactoring وقت گیر و دشوار باشد. توسعه دهندگان باید محدوده و اهداف پروژه را در فرآیند ریفکتورینگ بدانند. این امر به جلوگیری از تأخیر و کار اضافی کمک می‌کند. Refactor کد در مراحل اولیه باعث می‌شود تا توسعه‌ دهندگان بتوانند اشکالات احتمالی را پیدا کنند و همچنین مراحل نیازسنجی را بهتر طی کنند. اما به خاطر داشته باشید که ایرادات نرم افزار را به طور جداگانه رفع کنید. Refactoring برای رفع نقص‌های نرم افزاری نیست؛ عیب یابی و رفع اشکال باید جداگانه انجام شود. آیا تاکنون تجربه‌ای در Refactoring داشته‌اید؟ می‌توانید آن را با ما و سایر دوستان سون لرنی مطرح کنید. برخی منابع :

• https://www.techtarget.com/searchapparchitecture/definition/refactoring
• https://refactoring.com