سود:
- امکان راه اندازی یک شبکه ایمنی آزمایشی که رفتار فعلی را قبل از بازسازی مجدد ثبت می کند
- امکان درخواست تغییرات کوچک، تک مرحله ای و حفظ رفتار و اعتبارسنجی هر مرحله از هوش مصنوعی
- توانایی شناسایی و اولویت بندی بدهی های فنی در زمینه کسب و کار
Refactoring بهبود ساختار داخلی یک کد بدون تغییر رفتار خارجی آن است: خوانایی تر، ساده تر و قابل نگهداری تر کردن آن. از سوی دیگر، بدهی فنی یک سازش طراحی است که به خاطر یک راه حل سریع ایجاد شده و در طول زمان "با بهره" پرداخت می شود - هر گوشه ای که امروز برش دهید فردا به عنوان یک کاهش سرعت یا باگ بازخواهد گشت. هوش مصنوعی دستیار قدرتمندی است که کارهای بازسازی مکرر و مکانیکی را سرعت می بخشد. اما یک قانون طلایی برای بازسازی وجود دارد و هوش مصنوعی به تنهایی نمی تواند آن را تضمین کند: رفتار نباید تغییر کند.
در این بخش، ما یاد میگیریم که چگونه با هوش مصنوعی بازسازی ایمن انجام دهیم: مراحل کوچک و برگشتپذیر، محافظت با آزمایش، تشخیص بوی کد و اولویتبندی بدهیهای فنی. نکته مهم این است: این موفقیت در آزمون ها است، نه حرف هوش مصنوعی که ثابت می کند رفتار حفظ شده است.
قانون طلایی بازسازی مجدد: رفتار ثابت می ماند
چیزی که بازسازی را خطرناک می کند، تغییر ناآگاهانه رفتار در حین گفتن "من در حال بهبود هستم" است. رها کردن یک لبه هنگام ساده کردن یک شرط، شکستن ترتیب هنگام تبدیل یک حلقه، از دست دادن یک عارضه جانبی هنگام تقسیم یک تابع - همگی کد "با ظاهر تمیز" اما شکسته را ایجاد می کنند.
به همین دلیل است که آزمایش یک پیش نیاز برای بازسازی است: قبل از تغییر، باید تست هایی داشته باشید که رفتار موجود را نشان دهد. این آزمایشها یک «شبکه ایمنی» هستند. اگر در حین ریفکتورینگ به طور تصادفی چیزی بشکنید، آنها می شکنند و به شما هشدار می دهند. اگر تست ندارید، ابتدا تستهایی بنویسید که رفتار موجود را اصلاح میکنند (همانطور که در بخش 5 یاد گرفتیم) - اینجاست که هوش مصنوعی شروع به کار میکند.
احتیاط: بازسازی با کمک هوش مصنوعی بدون شبکه آزمایشی یکی از موذیترین منابع اشکال است. گفتن "من رفتار را حفظ کردم" آسان است. گواه این است که همان تست ها قبل و بعد از تغییر قبول می شوند.
گام به گام: جریان Refactoring ایمن
- شبکه ایمنی را راه اندازی کنید. اجازه دهید تستهایی وجود داشته باشد که رفتار فعلی کدی را که شما دوبارهسازی میکنید، ثبت کند. اگر نه، ابتدا آنها را یادداشت کنید (و ببینید که چگونه میگذرند).
- بو را نام ببرید چه چیزی را بهبود می دهید و چرا؟ "این تابع 3 کار انجام می دهد"، "همان منطق در 4 مکان تکرار می شود"، "نام ها گمراه کننده هستند".
- قدم های کوچک و تک مرحله ای را بخواهید. از هوش مصنوعی یک تبدیل بخواهید (به عنوان مثال فقط «این تابع را به نصف تقسیم کنید»)، نه اینکه کل فایل را بازنویسی کند.
- تست ها را اجرا کنید. بعد از هر قدم اگر سبز است ادامه دهید، اگر قرمز است آن را پس بگیرید.
- Diff را بخوانید. خط به خط تأیید کنید که تغییر واقعاً رفتار را حفظ می کند. ممکن است هنگام گفتن اینکه هوش مصنوعی "فقط ساختار" است، لغزش منطقی وجود دارد.
- به قطعات کوچک ترکیب کنید. PRهای بزرگ یکباره بازسازی هم پرخطر و هم غیرقابل بررسی هستند.
سه کیف کوچک
مورد 1 - عملکرد 220 خط ایمن تقسیم می شود. یک تیم دارای عملکرد پردازش سفارش 220 خطی بود. اول 14 تست نوشته شد (با کمک هوش مصنوعی) که رفتار فعلی را ثبت کرد، همه آنها قبول شدند. سپس توسط هوش مصنوعی تابع به 5 تابع کوچکتر تقسیم شد. بعد از هر مرحله تست ها اجرا شد. دو آزمایش در یک مرحله شکسته شد - هوش مصنوعی بازگشت را در یک جعبه لبه از دست داده بود. آزمایشات فوراً متوجه این موضوع شدند و آن را برطرف کردند. بدون شبکه، خطا میتوانست به تولید برسد.
مورد 2 - فاجعه بدون شبکه آزمایشی. یک توسعهدهنده دیگر یک ماژول محاسبه تاریخ را که هیچ آزمایشی با هوش مصنوعی نداشت، «پاکسازی» کرد. کد بهتر به نظر می رسید، اما سال کبیسه را اشتباه محاسبه می کرد. این اشکال دو هفته بعد با شکایت مشتری ظاهر شد. زیان بسیار بیشتر از زمان صرفه جویی شده از بازسازی بود. درس: بازسازی بدون آزمایش یک قمار است.
مورد 3 - اولویت بندی بدهی فنی. یک تیم 30 یا بیشتر امتیاز «قابل بهبود» را به هوش مصنوعی اختصاص داد و هر یک از آنها در محور «تغییر فرکانس × ریسک × تلاش» امتیاز گرفتند. در جدول به دست آمده، یک ماژول زشت که به ندرت لمس می شد، در واقع اولویت پایینی داشت، در حالی که یک ماژول با پیچیدگی متوسط که مرتباً تغییر می کرد، اولویت بالایی داشت. تیم انرژی خود را به جای مناسب هدایت کرد.
چهار قالب قابل کپی
تشخیص بوی کد و اولویت بندی:
در این کد، کاندیدای بازآفرینی لیست «بو» میدهد: عملکرد طولانی، تکرار (DRYViolation)، نام گمراهکننده، وضعیت تودرتو عمیق، عارضه جانبی پنهان، شماره جادویی. برای هر کدام: مکان، چرایی مشکل، گام کوچک پیشنهادی، خطر تخمینی (کم/متوسط/بالا). هنوز کد را تغییر ندهید، فقط برنامه ریزی کنید.{{code}}
تحول یک مرحله ای و حفظ رفتار:
فقط این کار را انجام دهید: {{تبدیل تک، به عنوان مثال. این تابع را به 3 تابع با نام کوچکتر تقسیم کنید}}. رفتار قابل مشاهده، امضا و مقادیر بازگشتی را تغییر دهید. در 1 جمله بنویسید چرا هر چیزی که تغییر دادید رفتار را حفظ می کند.{{کد}}
توری ایمنی قبل از ریفکتور (تست مشخصه):
تست هایی بنویسید که رفتار فعلی این تابع را نشان می دهد (درست است یا نه). هدف این است که متوجه شویم آیا رفتار در طول بازسازی تغییر می کند. شامل ورودی های معمولی + لبه. انتظارات را بر اساس خروجی فعلی تابع بنویسید.{{function}}
ایجاد سابقه بدهی فنی (بازگشت):
لیست بوهای زیر را در جدول اولویت بندی بریزید: ماده، ناحیه تحت تأثیر، فراوانی تغییر (دانش من: {{...}})، خطر، تلاش تخمینی، اولویت توصیه شده. تاثیر زیاد + کم تلاش را در بالا قرار دهید. {{smell_list}}
اعلان ضعیف / اعلان قوی
ضعیف: "این کد را پاک کنید و آن را بهتر کنید."
Strong: "این تابع 90 خطی را به 3 عملکرد کوچکتر با مسئولیت واحد تقسیم کنید، بدون تغییر رفتار خارجی و امضای آن. عوارض جانبی (DB می نویسد) را به ترتیب فعلی نگه دارید. من آزمایش هایی دارم، رفتار باید ثابت بماند. تفاوت را بیان کنید و در یک جمله توضیح دهید که چرا هر تقسیم رفتار حفظ می کند. [کد]."
نسخه قدرتمند؛ این نیاز به یک دگرگونی خاص دارد، صراحتاً یک محدودیت رفتاری و امضایی را تحمیل میکند و نیاز به توجیه دارد. درخواست های مبهم مانند «بهتر انجام بده» منجر به تغییرات کنترل نشده و مخاطره آمیزی می شود.
نوع بازسازی
قابلیت اطمینان هوش مصنوعی
پیش نیاز
تغییر نام دهید
بالا
آیا دامنه درست است؟
تقسیم کارکرد
متوسط به بالا
Testnet یک الزام است
تکرار را به اشتراک بگذارید
متوسط
تفاوت رفتار ممکن است پنهان باشد
تغییر الگوریتم/ساختار
پایین
آزمایش گسترده + اعتبارسنجی انسانی
بازآرایی معماری
پایین
به رهبری انسان، با پشتیبانی از هوش مصنوعی
مدیریت بدهی فنی، نه بازنشانی آن
بدهی فنی همه چیز بد نیست. گاهی اوقات وام گرفتن آگاهانه (برای انجام یک تحویل) تصمیم درستی است. هدف حذف بدهی نیست، بلکه قابل مشاهده و قابل مدیریت کردن آن است. هوش مصنوعی در شناسایی و اولویتبندی بدهی سریع است، اما تصمیمگیری «کدام بدهی باید پرداخت شود و کدام باید رها شود» به زمینه تجاری نیاز دارد: این ماژول هر چند وقت یکبار تغییر میکند، روی چند نفر تأثیر میگذارد، چه خطری دارد؟ این تصمیم توسط تیمی گرفته می شود که پایه کد و محصول را می شناسد. هوش مصنوعی فقط گزینه ها را روشن می کند.
نکته: روابط عمومی بازسازی خود را از روابط عمومی که شامل تغییر رفتار هستند جدا نگه دارید. اینکه بتوانید بگویید "این روابط عمومی فقط یک بازسازی است، رفتار یکسان است" بررسی را آسان تر می کند و به شما امکان می دهد در صورت بروز مشکل به سرعت علت را محدود کنید.
اشتباهات رایج
- بازسازی بدون شبکه آزمایشی شما چیزی ندارید که ثابت کنید این رفتار حفظ شده است.
- این به معنای "پاک کردن کل پرونده" است. تغییرات بزرگ و کنترل نشده خطا را پنهان می کند و قابل بررسی نیست.
- پذیرش Diff بدون خواندن آن. هوش مصنوعی ممکن است زمانی که میگوید «فقط ساختار» از منطق خارج شده باشد.
- اشتباه گرفتن بازسازی مجدد با تغییر رفتار. انجام هر دو در روابط عمومی یکسان، ردیابی علت اصلی را غیرممکن می کند.
- تلاش برای رفع هر بو. کد زشتی که به ندرت تغییر می کند، اغلب اولویت پایینی دارد. انرژی را به مکانی که مرتباً تغییر می کند اختصاص دهید.
به طور خلاصه
تنها قاعده بازسازي اين است كه رفتار ثابت بماند و گواه اين امر آزمايش هاست. هوش مصنوعی در تشخیص بوی کد، تحولات یک مرحله ای و اولویت بندی بدهی های فنی قدرتمند است. اما باید شبکه ایمنی را راه اندازی کنید، تست ها را اجرا کنید و بعد از هر مرحله تفاوت را بخوانید. گام های کوچک و قابل برگشت بردارید. تمایز بازسازی مجدد از تغییر رفتار؛ و اجازه دهید تیمی که زمینه کسب و کار را می شناسد تصمیم بگیرد که کدام بدهی را بپردازد.
وظیفه کاربردی
تابعی را از پایه کد خود انتخاب کنید که برای شما طولانی یا پیچیده به نظر می رسد. ابتدا آزمایش هایی را چاپ کنید که رفتار فعلی آن را با الگوی "شبکه ایمنی" نشان می دهد و ببینید که آیا همه آنها موفق می شوند یا خیر. سپس تابع را به یک روش واحد (مثلاً تقسیم به نصف) با الگوی «تحول یک مرحلهای و حفظ رفتار» بازسازی کنید و دوباره تستها را اجرا کنید. اگر تستی خراب شد، دلیل آن را پیدا کنید. اگر اصلاً خراب نشد، خط به خط تفاوت را بخوانید تا تأیید کنید که رفتار واقعاً حفظ شده است.
چک لیست
- [ ] من می دانم که refactoring نباید رفتار را تغییر دهد و آزمایش هایی برای اثبات آن وجود دارد.
- [ ] من در حال راه اندازی یک شبکه ایمنی هستم که رفتار فعلی را قبل از Refactor نشان می دهد.
- [ ] من تحولات کوچک و یک مرحله ای از هوش مصنوعی می خواهم، نه یکباره بزرگ.
- [ ] بعد از هر مرحله تست ها را اجرا می کنم و تفاوت را می خوانم.
- [ ] من به بازآفرینی روابط عمومی جدا از روابط عمومی تغییر رفتار ادامه می دهم.
- [ ] من بدهی فنی را در زمینه کسب و کار در اولویت قرار می دهم، نه کورکورانه تلاش برای صفر کردن.