ریفکتورینگ کد چیست؟ + مزایا و دلایل اهمیت Refactoring Code

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

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

Code refactoring چیست؟

ریفکتورینگ کد فرآیندی از ویرایش و پاکسازی کدهای برنامه است که ساختار داخلی آن را بهینه می‌کند، اما رفتار و عملکردهای خارجی آن را تغییر نمی‌دهد. این بخشی ذاتی از توسعه هر پروژه است. اگرچه لزوم بازآفرینی کد ممکن است واقعاً برای کاربران/مشتریان آشکار نباشد.

دلایل اهمیت ریفکتورینگ کد

در ادامه به دلایل اصلی می پردازیم که چرا Code refactoring مهم است و بهتر است از آن در پروژه های خود استفاده کنید:

1- قابلیت نگهداری و توسعه پذیری

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

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

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

برای واضح شدن مطلب به این مثال توجه کنید:

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

2- خوانایی کد

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

3- کارایی

یکی دیگر از اهداف بالقوه ریفکتورینگ کد، بهبود عملکرد است. بنابراین Code refactoring برنامه را قادر سازد تا سریع تر عمل کند یا از ظرفیت های سرور کمتر استفاده کند. این مزیتی است که ممکن است برای کاربران نهایی پس از بازآفرینی کد قابل لمس باشد.

4- صرفه جویی در هزینه ها

در یک نگاه بلندمدت، فعالیت های ریفکتورینگ کد با توجه به مزایای ذکر شده منجر به کاهش هزینه می‌شود. Code refactoring به ظهور عناصر طراحی قابل استفاده مجدد کمک می کند که ممکن است به سادگی برای ویژگی های جدید در آینده استفاده شوند.

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

5- پیامدهای بدهی فنی

عدم ریفکتورینگ می‌تواند منجر به افزایش بدهی فنی (Technical debt) شود. بدهی فنی زمانی به وجود می آید که تیم توسعه به دلیل کمبود زمان یا ایجاد سرعت در انجام پروژه رفع یکسری از مشکلات کد را به بعد موکول می کند. به عبارت دیگر، این نتیجه اولویت دادن به تحویل سریع نسبت به تحویل کد کامل است. هرچه بیشتر به مسائل جزئی در طول مسیر اهمیت ندهید، احتمال اینکه آنها به پیچیدگی های بزرگ تبدیل شوند، بیشتر می شود. در ادامه چند پیامد‌ اصلی و سطح بالا را می بینید که ناشی از انباشته شدن بدهی های فنی در سیستم موجود است:

• ویژگی های جدید بسیار کندتر توسعه یافته و ارائه می شوند.
• انتقال دانش به توسعه دهندگان جدید که به پروژه ملحق می شوند ناکارآمدتر است.
• برآوردها نادرست هستند که منجر به از دست رفتن زمان می شود.
• مشتری با یک ارائه توسعه نرم افزاری رو برو است که ممکن است به سختی تغییر کند.

بنابراین دیر یا زود باید این مشکلات برطرف شود تا برنامه قابلیت کار کردن و بهبود را داشته باشد.

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

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

نکات زیر بهانه خوبی است برای شروع بازسازی کد:

• زمانی که خواندن کد سخت است و پس از اتمام توسعه نرم افزار بسیار حجیم شده است.
• زمانی که کدهای تکراری در بخش های مختلف برنامه استفاده شده باشد.
• زمانی که بسیاری از عملگرهای شرطی دارای ویژگی در یک کد استفاده شده باشد.

در برابر کد کثیف، کد تمیز قرار دارد که هدف نهایی هرگونه بهبود کیفیت Code refactoring است. با توجه به تعریف کد تمیز، ریفکتورینگ کد زمانی مورد نیاز است که یکی از ویژگی های کد تمیز از جمله موارد زیر رعایت نشده باشد:

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

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

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

چه زمانی ریفکتورینگ کد نیاز نیست؟

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

به عبارت دیگر، در این موارد چون ریفکتورینگ به موقع انجام نشده باعث بروز چنین مشکلاتی شده است و نوشتن دوباره برنامه از صفر زمان و انرژی کمتری خواهد گرفت تا ریفکتورینگ این میزان از کد معیوب!

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

اگر قرار نیست برنامه شما توسعه یابد، احتمالاً ارزش ریفکتورینگ را ندارد. اما اگر ویژگی هایی قرار است تا در آینده به برنامه اضافه شود، منطقی است که ریفکتورینگ کد را همیشه در نظر داشته باشیم.

نکات و ترفندها

برخی از بهترین نکات و ترفندها وجود دارند که می‌توانند ریفکتورینگ کد را معقول تر و مؤثرتر کنند:

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

ترفند دوم: Refactoring باید با دقت برنامه ریزی و برآورد شود. ریفکتورینگ کد ممکن است برخی از مسائل غیرقابل پیش‌بینی را نشان دهد که زمان بیشتری را نسبت به آنچه انتظار می‌رفت طلب کند. بنابراین بهتر است از ابتدا زمان بیشتری را برای ریفکتورینگ در تخمین‌های قرار دهید تا انتظارات مربوط به زمان تحویل پروژه را خراب نکنید.

ترفند سوم: ریفکتورینگ باید با unit test همراه باشد. هدف از refactoring تنها پاک کردن کد نیست، بلکه حفظ عملکرد خوب سیستم نیز یکی از اهداف مهم آن می باشد. بنابراین برای بررسی، اگر چیزی خراب نشده است، استفاده از یونیت تست ضروری است. از آنجایی که نوشتن یونیت تست نیازمند زمان است، بهتر است از همان ابتدای پروژه به تعریف آن ها بپردازیم.

ترفند چهارم: تیم QA (تضمین کیفیت) باید در فرآیند بازسازی مشارکت داشته باشد. از آنجایی که refactoring نباید بر رفتار خارجی برنامه تأثیر بگذارد، این امر به درگیر کردن تیم تست برای انجام آزمایش رگرسیون – regression testing (یک نوع تست برنامه که تایید می‌کند تغییر‌ات اخیر بر روی ویژگی های موجود تاثیر منفی نمی‌گذارد) ارتباط پیدا می‌کند. هم یونیت تست و هم تست رگرسیون باید به عنوان بخشی از تلاش‌های ریفکتورینگ انجام شود. اینکار به ما اطمینان می دهد که عملکرد برنامه تحت تاثیر منفی قرار نگرفته است.

نتیجه گیری

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