ریفکتورینگ (Refactoring) - بخش اول

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

کد تمیز

هدف اصلی ریفکتورینگ مبازه با بدهی فنی است، که در نهایت کدهای درهم و کثیف را تبدیل به کدهای تمیز و ساده و قابل فهم میکند، اما بدهی فنی چیست؟

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

احتمالا با توضیحات بالا قانع شدید که تمیزتر کد بنویسیم، اما یه کد خوب و تمیز چه ویژگی هایی دارد؟

1- کد تمیز برای توسعه دهندگان جدیدی که به تیم اضافه می شوند کاملا واضح و خواناست

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

2 – کدهایی که تمیز نوشته شده اند بلاک، متد، و کلاسی با کد تکراری ندارند

اگر شما در پروژه خود کدی داشته باشید که یک کار را انجام می دهد اما در دو یا چندجای مختلف تکرار شده است، باید گفت که مسیر بدی را رفته اید، فرض کنید سه متد دارید که نیاز به تبدیل dto یا view model به entity دارند؛ اگه شما این کار را در هر متد و بصورت جداگانه map کنید، با اضافه یا کم کردن یک property جدید باید هر سه متد را تغییر دهید، حالا موردی شبیه به این مورد را در ابعاد بزرگتر تصور کنید ، مثلا در حد بیست entity و سی dto که احتملا ممکن است با شصد یا هفتاد مدل map شوند، تغییر هر کدام از این متدها کاری تکراری و طاقت فرساست که در نهایت منجر به خستگیه مفرط برای توسعه دهنده می شود؛ حداقل برای نویسنده این پست که کاملا اینطور بوده.

3 – کدهای تمیز اغلب کم حجم هستند

متدها و کلاسهای کوچک تر فضای کمتری را از ذهن توسعه دهنده اشغال می کنند؛ کد کمتر، نگهداری کمتری را می طلبد؛ کد کمتر، باگهای کمتری را ممکن است بوجود بیاورد و در نهایت توسعه آن راحت تر است. سعی کنید تا حد امکان کدهایخود را به بخش های کوچیک تری تقسیم کنید، یک پیشنهاد این است که اجازه ندهیم تعداد خطوط متدها بیشتر از 30 خط شوند(بدون در نظر گرفتن خطوط خالی و کامنت های میان کدها) و همچنین نگذاریم تعداد کلاس هایمان بیشتر از 30 متد در خود داشته باشند و در نهایت تعداد خطوط کدهای یک کلاس بشتر از 900 خط نشوند.هر package یا dll بیشتر از 30 کلاس نداشته باشند و یک سری قواعد دیگر که در آینده به آن اشاره خواهد شد.

برای مطالعه قسمت دوم اینجا کلیک کنید.