واحد 4 / 12

بازنگری کد، اصلاح مجدد و بدهی فنی

سود:

  • امکان استفاده از هوش مصنوعی به عنوان چشم دوم در بررسی کد برای خوانایی، منطق و امنیت
  • امکان برنامه ریزی مراحل بازسازی با پشتیبانی هوش مصنوعی بدون ایجاد اختلال در رفتار کد پیچیده
  • امکان تأیید بررسی و ویرایش توصیه‌های هوش مصنوعی با آزمایش و مقایسه کنترل نسخه

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

در این بخش، نحوه استفاده از هوش مصنوعی را به روشی ساختاریافته برای بررسی کد، نحوه تعمیر کدهای پیچیده بدون شکستن رفتار آن، و نحوه مدیریت بدهی فنی (تصمیمات کد سریع اما پرهزینه) خواهیم دید.

مفاهیم: بدهی فنی: تصمیمات کدی که امروز برای سرعت اتخاذ می شود و تعمیر و نگهداری را در آینده دشوار می کند. بوی کد: الگوهایی که خود خطا نیستند اما مشکلاتی را نشان می دهند (توابع بسیار طولانی، کدهای تکراری). رگرسیون: زمانی که یک تغییر چیزی را که قبلاً کار می کرد می شکند.

استفاده از هوش مصنوعی در بررسی کد ساختاریافته

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

  1. دامنه را بدهید. چه کد، چه باید کرد، در چه زمینه ای کار می کند.
  2. محور اولویت را مشخص کنید. اول دقت و امنیت، دوم خوانایی.
  3. اصلاح بتن را بخواهید. "چرا مشکل" و "رفع توصیه شده" برای هر یافته.
  4. شما یافته ها را تأیید می کنید. هوش مصنوعی نیز مثبت کاذب تولید می کند. هر یافته را در برابر کد و آزمایش بررسی کنید.

درخواست بررسی ساختاریافته: "عملکرد زیر را مانند یک مهندس ارشد بررسی کنید. یافته‌ها را به ترتیب اهمیت فهرست کنید و آنها را با این برچسب‌ها علامت بزنید: منطق/امنیت [جدی]، مورد/عملکرد [متوسط] لبه، خوانایی/نام [پایین]. برای هر یافته: چرا بپرسید، پیشنهادهای دقیق را انجام دهید. قالب‌بندی دقیق، ابزارهای خودکارسازی را انجام ندهید. کد: [کد]"

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

احتیاط: فقط به این دلیل که هوش مصنوعی می گوید "مشکلی نیست" دلیلی بر عدم وجود مشکل نیست. هوش مصنوعی می تواند منفی های کاذب تولید کند. می تواند یک مسئله امنیتی واقعی را دور بزند. مکمل های بررسی هوش مصنوعی، نه جایگزین، بررسی انسانی و تست امنیتی. در کد امنیتی حیاتی، مهندس صالح حرف آخر را می زند.

بازسازي مجدد تست شده

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

  1. رفتار فعلی را مورد آزمایش قرار دهید. در غیر این صورت، از هوش مصنوعی بخواهید که یک "تست مشخصه" (تست که رفتار فعلی را همانطور که هست نشان می دهد) ایجاد کند.
  2. در مراحل کوچک آن را برطرف کنید. آزمایش باید در هر مرحله سبز بماند.
  3. بعد از هر مرحله آن را اجرا کنید. رگرسیون را زودتر بگیرید.

اعلان طرح بازسازی ایمن: "عملکرد 60 خطی زیر بیش از حد انجام می دهد و خواندن آن سخت است. می خواهم بدون تغییر رفتار آن را مجدداً اصلاح کنم. ابتدا: لیست موارد آزمایشی را که برای قفل کردن رفتار فعلی نیاز دارم. سپس: دوباره سازی را به مراحل کوچک تقسیم کنید، هر یک از آنها را می توان در حالی که تست ها سبز هستند اجرا کرد. هنوز کد اولیه طرح را ننویسید."

اعلان ضعیف / اعلان قوی

ضعیف: "این کد را بهتر کنید." (نتیجه: مشخص نیست چه چیزی باید بهبود یابد؛ هوش مصنوعی تغییرات دلخواه ایجاد می‌کند، می‌تواند رفتار را بی‌صدا تغییر دهد.) قوی: "این تابع محاسبه پرداخت را برای خوانایی مجدد اصلاح کنید. محدودیت: رفتار باید دقیقاً یکسان باقی بماند، مقادیر برگردانده نباید تغییر کنند. تابع طولانی را به توابع کاربردی معنی‌دار تقسیم کنید، اعداد جادویی را به نام‌های رفتار با ثابت افزایش دهید. [کد]"

اعلان قدرتمند به وضوح بیان می کند که "رفتار باید دقیقاً یکسان بماند" و آنچه باید بهبود یابد. بدون این محدودیت، هوش مصنوعی می تواند منطق را به نام "بهبود" تغییر دهد و یک رگرسیون خاموش ایجاد کند.

مدیریت بدهی فنی

رویکرد

در کوتاه مدت

در دراز مدت

نادیده گرفتن بدهی

پیشرفت سریع

فلج نگهداری، کند شدن تیم

همه چیز را دوباره بنویس

توسعه ویژگی های ایستاده

بازده نامشخص، ریسک بالا

بازسازی اندازه گیری شده، محافظت شده در برابر آزمایش

کندی جزئی

سرعت پایدار

سالم‌ترین راه سوم است: بدهی را قابل مشاهده کنید (آن را در یک لیست دنبال کنید)، از جایی شروع کنید که بیشتر به آن آسیب می‌زند، و هر اصلاح را آزمایش کنید. هوش مصنوعی کمک خوبی برای شناسایی و اولویت بندی اقلام بدهی است، اما اینکه کدام بدهی باید پرداخت شود، یک تصمیم تجاری است.

موارد کوچک

مورد 1 - رگرسیون خاموش. یک توسعه‌دهنده به هوش مصنوعی می‌گوید که «این عملکرد را ساده‌سازی کند». هوش مصنوعی یک شرط را به اشتباه ترجمه می کند و محاسبه بازگشت خراب است. از آنجایی که هیچ آزمایشی وجود ندارد، خطا پس از 3 هفته با شکایت مشتری رخ می دهد. تیم همان کار را انجام می دهد و ابتدا یک تست شخصیت پردازی می نویسد و در اولین اجرا با یک تست قرمز خطا را می گیرد.

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

مورد 3 - مثبت کاذب. هوش مصنوعی می گوید: «این متغیر هرگز استفاده نمی شود، آن را حذف کنید». با این حال، به طور غیر مستقیم از طریق یک مکانیسم بازتاب متغیر استفاده می شود. اگر مهندس پیشنهاد را در مقابل تست تأیید نمی کرد، حذف می شد و خطای زمان اجرا رخ می داد. هر یافته هوش مصنوعی باید قبل از اجرا تایید شود.

اشتباهات رایج

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

به طور خلاصه

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

وظیفه کاربردی

یک خط 40-70 را انتخاب کنید، عملکردی تا حدی پیچیده که دارید (یا باید هوش مصنوعی تولید کند). ابتدا دستور بررسی ساختاریافته را دنبال کنید و یافته ها را به صورت [ بحرانی]/[متوسط]/[کم] مرتب کنید. حداقل یک یافته را در برابر کد به صورت دستی تأیید کنید. سپس، با درخواست طرح بازسازی ایمن، ابتدا تست های مشخصه سازی را تولید و اجرا کنید، سپس در مراحل کوچک بازسازی را اعمال کنید و بررسی کنید که تست ها در هر مرحله سبز باقی می مانند.

چک لیست

  • [ ] من بررسی را با برچسب های اولویت (بحران/متوسط/کم) ساختار دادم.
  • [ ] من حداقل یک یافته هوش مصنوعی را در برابر کد/تست تأیید کرده ام.
  • [ ] من رفتار فعلی را قبل از refactoring آزمایش کردم.
  • [ ] من تغییرات را در مراحل کوچک انجام دادم و در هر مرحله آزمایش هایی را انجام دادم.
  • [ ] من محدودیت "رفتار باید به همان صورت باقی بماند" را در فرمان مشخص کردم.
  • [ ] من تأیید کرده ام که یافته های امنیتی نیاز به تایید انسانی دارند.