در این مقاله می خواهیم تا به بررسی مجدد کد یا  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