مسعود بهرامی
Breakthrough Refactoring یعنی چه و چرا اهمیت دارد؟
Breakthrough Refactoring یک اصطلاح کلیدی در دنیای بهبود کدهای legacy است که معمولاً روی یک نکته دست میگذارد: در بسیاری از سیستمها، شما نمیتوانید با refactoring معمولی یا صرفاً چند تکنیک کوچک به نتیجه برسید. مشکل آنقدر عمیق است که نیاز به یک تغییر بنیادین در نحوهی کار دارید؛ یعنی شکستن بنبست در refactoring.
این رویکرد میگوید:برای اینکه واقعاً پیشرفت کنید باید مانع اصلی را پیدا کنید. سپس با یک حرکت یا سری حرکات هدفمند، توانایی توسعه و تغییر را به سیستم برگردانید- بعد از ایجاد این breakthrough، refactoringهای بعدی بسیار سریعتر و امنتر میشوند.
نه فقط Refactoring بزرگ
نکتهی مهم در اینجا این است که Breakthrough Refactoring فقط Refactoring بزرگ نیست. در نگاه سطحی ممکن است کسی فکر کند breakthrough یعنی یک refactor بزرگ و پرریسک یا بازنویسی کامل سیستم.
اما منطق breakthrough دقیقاً خلاف این است. breakthrough معمولاً یک تغییر تاکتیکی با اثر استراتژیک است. یعنی کاری میکنید که هزینههای اصلی فهم/تغییر را کاهش میدهد و از آن لحظه به بعد، refactor کردن آسان میشود.
علت بنبست در legacy code چیست؟
برای اینکه درباره breakthrough حرف بزنیم، باید ریشهی مشکل را تشخیص دهیم. بنبستهای رایجی در حین فرآیند ریفکتور کردن کد لگسی ممکن است وجود داشته باشد، از جمله:
- نبود تست و عدم مشاهده پذیریون(observable) سیستم: قتی نمیدانید سیستم چه میکند، هر تغییر مثل قمار است. این باعث میشود refactoring نتواند شروع شود یا هر شروعی متوقف شود.
- وابستگیهای شدید (Tightly Coupled Code): اگر منطق کسبوکار، ورودی/خروجی، دیتابیس، لاگینگ، یا سرویسهای بیرونی را درهم قفل کرده باشد، جدا کردن بخشها سخت میشود.
- رفتارهای پنهان و سناریوهای خاص: کد ممکن است “ظاهراً” ساده باشد اما در شرایط خاص چیزهای عجیب انجام دهد. بدون ابزارهای کنترل، خطاها دیر ظاهر میشوند.
- عدم توانایی در اندازهگیری (No Metrics for Change): اگر نتوانید اثر تغییر را بسنجید، نمیدانید کجا پیروزی است و کجا شکست.
- پیچیدگی ساختاری: سخت شدن فهم سیستم گاهی ریشه نه فقط در وابستگی، بلکه در معماری داخلی است: جریان کنترل پیچیده، شرطهای تو در تو، یا سطوح مختلف در هم.
breakthrough معمولاً چگونه ایجاد میشود؟
در اکثر چارچوبها (خصوصاً آنهایی که از مسیر کتابهای legacy و refactoring میآیند)، میتوانیم یک یک الگوی غالب را مشاهده کنیم:
گام ۱) کشف bottleneck اصلی: به جای refactor کردن از هر کجا، اول باید مشخص کنید چرا تغییر کند/ترسناک شده است.
- مثلاً آیا تست نمیتوانید بنویسید؟ پس مشکل اصلی تست ناپذیر بودن سیستم است.
- آیا تغییر باعث شکستهای ناخواسته میشود؟ پس مشکل نبود safety net است.
- آیا کد قابل خواندن نیست؟ پس مشکل اصلی جریان/ساختار است.
گام ۲) ایجاد قابلیت تغییر (Enabling Change): اینجاست که breakthrough رخ میدهد. یک یا چند اقدام انجام میدهید که امکان حرکت را فراهم کند.
- مثل: جدا کردن ورودی/خروجی و ایجاد نقطههای قابل کنترل
- ساخت تستهای Characterization برای ثبت رفتار
- استخراج ماژولها یا ایجاد boundaries
- جایگزینی dependency ها برای تستپذیر کردن سیستم.
گام ۳) سپس refactoringهای معمولی شروع میشوند: بعد از اینکه bottleneck برداشته شد، refactoring به کار روزمره تبدیل میشود. شما میتوانید: روشهای بهتر را جایگزین کدهای نامناسب کنید، کد را به ساختار تمیزتر نزدیک کنید و بدهی فنی را مرحلهای کاهش دهید.
فرض کنید سیستم یک کلاس بزرگ دارد که هم منطق کسبوکار را دارد، هم دسترسی به دیتابیس، هم validationهای پیچیده، هم تبدیل مدلها.اگر بخواهید مستقیم شروع کنید به تمیز کردن متد، احتمالاً هیچ کاری درست پیش نمیرود. چون: نمیدانید چه خروجیهایی باید باشن، تست نوشتن سخت است چون DB درگیر است و با تغییر کوچک، چند نقطه دیگر میشکنند. در این سناریو
Breakthrough ممکن است میتواند این سناریو باشد:
- اول boundary ایجاد کنید: دسترسی DB را جدا کنید (مثلاً با Repository یا یک abstraction)
- سپس با Characterization tests رفتار را در سناریوهای کلیدی ثبت کنید
- بعد آرام آرام منطق کسبوکار را استخراج کنید (Extract Method / Extract Class)
- در نهایت کد ساختارمند میشود و تغییرهای بعدی سریعتر و کمریسکتر میشوند.
در این مثال، breakthrough نه تمیزکاری نهایی بلکه قابل تست شدن و جدا شدن مسئولیتها است.
چارچوب عملی برای Breakthrough Refactoring
در یک پروژه واقعی، معمولاً breakthrough refactoring را میتوان با یک نقشهی عملی اینطور انجام داد:
تحلیل سریع و انتخاب محدوده:
ابتدا یک بخش کوچک اما نماینده انتخاب کنید: Module یا یک مسیر مهم- هدف: شکست خوردن کل سیستم نیست؛ هدف: ایجاد یک اهرم تغییر (leverage) است.
ثبت رفتار فعلی (Characterization)
چند تست روی رفتارهای مهم بنویسید، لازم نیست ایدهآل باشند؛ در عوض بسیار مهم و حیاتی است است دقیق باشن، این تستها سپر تغییر میشوند و خیلی سریع به شما بازخورد کیدهند.
مهندسی برای تستپذیری
وابستگیها را مدیریت کنید. با refactorهای کمریسک boundaries ایجاد کنید و تا جایی که ممکن است کنترل ورودیها و زمان/خروجیها را به دست بگیرید.
refactor های ساختاری هدفمند
حالا breakthrough زمینه را فراهم کرده؛ پس میتوانید سراغ: تقسیم مسئولیتها، کاهش پیچیدگی، تمیزکاری کنترل جریانو نهایتا حذف کد تکراری با Extract و Composition بروید.
توسعهی تکرارپذیر
تبدیل breakthrough را به یک رویه و فرهنگ تیمی تبدیل کنید. بعد از اینکه breakthrough موفق شد، یک الگو برای افراد و تیم خودتا بسازید که شامل موارد زیر باشد. در دفعات بعدی سعی کنید همین الگو را تمرین کنید:
- چطور تست characterization مینویسیم؟
- چطور boundary ایجاد میکنیم؟
- چه معیارهایی داریم که بگوییم سیستم قابل refactor شده؟
چالشها و ریسکهای Breakthrough Refactoring
شبیه هر رویکرد دیگری باید گفت که این رویکرد هم علیرغم مزیتهایی که برای ما به همراه دارد فارغ از چالش هم نیست. شاید بتوان بصورت خلاصه این چالشها رو بصورت تیتروار شامل موارد زیر دانست:
- انتخاب اشتباه bottleneck: اگر گلوگاه اصلی را درست نشناسید، breakthrough واقعی اتفاق نمیافتد.
- بیش از حد بزرگ کردن محدوده breakthrough: باید هدفمند باشد، نه اینکه بصورت چشم بسته تمامی بخشهای یک سرویس یا ماژول رو بخواهیم به یکباره ریفکتور کنیم.
- نبود حمایت تیمی: اگر فرهنگ تیم اجازهی تغییرات کوچکِ ایمن را ندهد، breakthrough سخت میشود.
- تستهای شکننده: تستهای ضعیف یا وابسته به جزئیات غیر ضروری، breakthrough را کند میکنند.
breakthrough بدون تغییر ذهنیت تیم هم شکست میخورددر نهایت، breakthrough refactoring صرفاً یک تکنیک نیست؛ یک پیام به تیم است: ما به جای ترس از تغییر، با ابزار و گامهای کنترلشده جلو میرویم.
اول رفتار را امن میکنیم، بعد ساختار را بهبود میدهیم.
سرعت واقعی از توانایی تغییر امن میآید، نه از تلاش برای کامل کردن از همان ابتدا.
Breakthrough Refactoring به جای اینکه شما را به refactor کردنِ صرفاً زیباسازانه محدود کند، به دنبال یک هدف بنیادی است: بازگرداندن توان تغییر. این رویکرد با شناسایی گلوگاههای اصلی (معمولاً تستپذیری، جداسازی وابستگیها، و عدم مشاهدهپذیری) و اجرای یک سری حرکتهای هدفمند، بنبست را میشکند. سپس با فراهم شدن امنیت و کنترل، refactoringهای بعدی به شکل پایدار و تکرارپذیر ادامه مییابد.
