'%3e%3crect%20width='24'%20height='24'%20transform='translate(1568%20947)'%20fill='%23dbdbdb'/%3e%3cg%20transform='translate(1466%20765)'%3e%3cpath%20d='M2.875,5.75A2.875,2.875,0,1,1,5.75,2.875,2.879,2.879,0,0,1,2.875,5.75Zm0-5A2.125,2.125,0,1,0,5,2.875,2.13,2.13,0,0,0,2.875.75Z'%20transform='translate(111.125%20188.625)'%20fill='%230b032d'/%3e%3cpath%20d='M8.965,4.25a.378.378,0,0,1-.375-.375C8.59,2.15,6.83.75,4.67.75S.75,2.15.75,3.875a.378.378,0,0,1-.375.375A.378.378,0,0,1,0,3.875C0,1.74,2.095,0,4.67,0S9.34,1.74,9.34,3.875A.378.378,0,0,1,8.965,4.25Z'%20transform='translate(109.33%20195.125)'%20fill='%230b032d'/%3e%3cpath%20d='M0,0H12V12H0Z'%20transform='translate(108%20188)'%20fill='none'%20opacity='0'/%3e%3c/g%3e%3c/g%3e%3c/svg%3e){kind=small}
گرچه در دنیای واقعی هر کسب‌وکار بسیاری از مفاهیم اصطلاحاً Interchangeable هستند، اما حداقل روی کاغذ می‌توان به تفاوت‌های آن‌ها اشاره کرد که در همین راستا در این پست قصد دارم دیدگاه شخصی‌ام رو در ارتباط با تفاوت‌های مابین Refactoring با Restructuring در صنعت توسعهٔ نرم‌افزار بیان کنم اما برای درک بهتر این موضوع، شاید بد نباشد این مفاهیم را به صنعت خودروسازی نسبت دهیم تا سهل‌الفهم‌تر شوند!
آشنایی با Refactoring با Restructuring در خودروسازی
برای شروع، بیاییم مقایسه‌ای داشته باشیم مابین صنعت خودروسازی داخل با صنعت خودروسازی کشور مورد علاقه‌ام آلمان (اگر شما هم علاقمند به فرهنگ آلمانی هستند، شاید مطالعهٔ مقالهٔ چگونه با پیروی از فرهنگ کاری آلمانی‌ها، در زندگی کاری و حرفه‌ای خود به موفقیت برسیم! خالی از لطف نباشد.)
خب ما شاهد نوآوری در بهبود پیکان بودیم تا جایی که یاد دارم نهایت خلاقیت این بود که چراغ‌های جلو و عقب پیکان بزرگ‌تر شد و پس از مدتی هم ورژن سپر جوشن بیرون آمد که استقبال چندانی هم نشد و امروزه هم می‌بینیم که پراید رو می‌آیند یک فیچر خیلی کوچک بهش اضافه می‌کنن و اسمش رو می‌کنن مثلاً پراید صد و نمی‌دونم چند و چند میلیون می‌گذارن روی قیمتش. در واقع، کارهایی از این دست رو می‌تونم بهشون بگم Refactoring بدین معنا که تغییرات کوچک صورت می‌گیرد اما به هیچ وجه کن فیکون نمی‌کنن بلکه نسبت به نسخهٔ قبلی کمی بهتر می‌شه.
حال برسیم به خودرویی مثل بنز که نسبت به رقیب دیرینه‌اش بی‌ام‌وِ در خصوص سرمایه‌گذاری روی امنیت شهره هست. دست‌اندرکاران عرضهٔ بنز علاوه بر Refactoring یا به عبارتی آیرودینامیک‌تر کردن ظاهر خودرو، افزودن یکسری آپشن جدید و چیزهایی از این دست، روی Restructuring این برند نیز سرمایه‌گذاری می‌کنند (به یاد داشته باشیم که حرف W در الفبای آلمانی «وِ» تلفظ می‌شود و از آنجا که BMW یک خودروی آلمانی است، پس بهتر آن است که مثل آلمانی‌ها تلفظش کنیم نه مثل بریتانیایی‌ها و بگوییم بی‌اودَبلیو. به عبارتی، کورکورانه چند نفری که فکر می‌کنن اگر بگن بی‌ام‌دبلیو خیلی باکلاس هستن رو دنبال نکنیم!)
در ارتباط با اینکه Restructuring در خودرو چه مفهومی می‌تواند داشته باشد، می‌شود گفت ری‌دیزاین سیستم تعلیق، بازنگری در سیستم سوخت‌رسانی، بازطراحی جعبه‌دهنده، اِعمال تغییرات در شاسی، چکش‌کاری موتور برای کاهش مصرف سوخت و ... به Restructuring تعلق دارند تا جایی که خیلی اوقات قطعات یدکی این خودروهای تراز اول به قول دولوپرها Backward Compatible نیست به طوری که مثلاً خودروی سال 2019 با خودروی سال 2015 از زمین تا آسمان تغییرات ساختاری پیدا کرده است.
به طور خلاصه، در ساخت خودرو Refactoring شامل تغییرات جزئی است که منجر به بهبود مستمر (کایزن) می‌شوند اما Restructuring به تغییراتی اشاره دارد که آن‌ها هم منجر به بهبود مستمر خودرو می‌شوند اما در عین حال اساسی هستند.
آشنایی با Refactoring با Restructuring در کدنویسی
خب اگر بخواهیم سریع برویم سر اصل مطلب، در حین کدنویسی حتی تغییر نام یک فایل نیز Refactoring است و از جمله دیگر کارهایی که زیر این چتر قرار می‌گیرند می‌توان به تغییر نام متغیرها، متدها، کلاس‌ها، نحوهٔ کوئری زدن به شکلی بهینه‌تر، هندل کردن بهتر ارورها و اکسپشن‌ها، انتخاب پیام‌های خطای ملماوس‌تر و چیزهایی از این دست اشاره کرد. به طور خلاصه، مجموعه اقداماتی که منجر به بهبود مستمر سورس‌کد می‌شوند.
اما وقتی صحبت از Restructuring به میان می‌آید، یعنی مثل همان خودروسازان آلمانی قرار است تغییرات زیرساختی و پایه‌ای در نرم‌افزار یا اپلیکیشن اِعمال کنیم (آخرش ما تفاوت نرم‌افزار با اپلیکیشن رو نفهمیدیم🤔) به طوری که مثلاً اِعمال درست الگوهای طراحی و یا پیاده‌سازی قوانین SOLID همگی ما به عنوان توسعه‌دهنده رو مجبور می‌کنن تا بسیاری از ساختارهای غیربهینه، غیراصولی و هیئتی قدیمی را شکسته و همه چیز را از نو بنا کنیم و همان‌طور که از نام Restructuring مشخص است، استراکتچر یا ساختار نرم‌افزار را از نو می‌چینیم و نیاز به توضیح هم نیست که این کار در صنعت نرم‌افزار بسیار پرهزینه است!
به طور مثال، گاهی در این پروسه مجبور به تغییر در ساختار دیتابیس می‌شویم که پیش در این در مقالهٔ تجربه‌ای در ارتباط با Schema Migration به بیان این موضوع پرداختم (البته فراموش نکنیم که اینجا همون بحث Interchangeable بودن این دو مفهوم سر باز می‌کنه چون از یک بُعد می‌توان تغییر را ساختار دیتابیس رو Refactoring تلقی کرد.)
برای درک بهتر این موضوع، پیش از پایان این بحث یک مثال از دنیای واقعی در ارتباط با این دو مفهوم می‌زنم. فرض کنیم توسعه‌دهندهٔ یک فروشگاه آنلاین هستیم که در آن یک کلاس داریم که اصطلاحاً می‌شود بهش گفت god class یا به عبارتی «ارباب کلاس‌ها» که مسئول انجام همه کاری است؛ از شیر مرغ گرفته تا جان آدمیزاد (توجه داشته باشید که اسم گاد با حرف g نوشته شد نه با G با این تفسیر که god به معنی الهه است اما God به معنای خدای یکتا) و یا متدهایی داریم که ده الی دوازده پارامتر ورودی می‌گیرند 😲 که با تغییر کلاس مذکور به چند کلاس تخصصی بدین صورت که هر کلاس مسئول انجام یک کار خاص است و یا تفکیک متدها به چندین متد کوچک و جمع‌وجور در واقع دست به Refactoring پروژه زده‌ایم.
حال فرض کنیم که برای برقرار کردن امکان صحبت کردن بین ماژول‌های مختلف این فروشگاه آنلاین تاکنون از RESTful API استفاده می‌کردیم اما با عرضهٔ پروژهٔ اپن‌سورس GraphQL توسط فیسبوک قصد مهاجرت به این فناوری را داریم که مسلماً نیاز به اِعمال یکسری تغییرات ساختاری خواهیم داشت و اینجاست که می‌توان گفت داریم دست به Restructuring می‌زنیم.
سخن پایانی
تجربهٔ شخصی‌ام در این حوزه می‌گه که وقتی Refactoring می‌کنیم، ممکن هست چند صد خط کد اضافی رو پاک کنیم و مثلاً الگوریتمی که در یکصد خط کد عملی می‌شد رو با چهل خط پیاده‌سازی کرد اما وقتی پای Restructuring به میان می‌آید، درد و خونریزی 🤕 بیشتری رو باید متحمل شویم چرا که اساساًً گاهی اوقات مجبور خواهیم شد تا یکسری ماژول، پلاگین و یا کامپوننتی که روزها صرف نوشتنشون کردیم رو Shift + Delete کنیم!
ممنون که وقت گذاشتید. جای نظر، انتقاد و پیشنهاد شما در بخش کامنتینگ است.