5 نکته و ترفند برای کدنویسی عامل
تصویر توسط ناشر
مقدمه
کدنویسی عامل تنها زمانی «هوشمندانه» به نظر میرسد که تفاوتهای صحیح را ارائه کند، آزمایش را پشت سر بگذارد، و ردپایی از کاغذ باقی بگذارد که میتوانید به آن اعتماد کنید. سریعترین راه برای انجام این کار این است که از درخواست از یک نماینده برای “ساخت یک ویژگی” خودداری کنید و شروع به ارائه گردش کاری به آنها کنید که نمی توانند از آن فرار کنند.
این گردش کار باید وضوح (آنچه تغییر می کند)، شواهد (آنچه اتفاق افتاده) و مهار (آنچه می تواند لمس کند) را مجبور کند. نکات زیر الگوهای مشخصی هستند که می توانید آنها را در کار روزانه خود با کارگزاران کد بگنجانید، چه از یک عامل CLI، یک کمک کننده IDE یا یک الگو با استفاده از یک ابزار سفارشی استفاده کنید.
1. از یک نقشه مخزن برای جلوگیری از Refactor های کور استفاده کنید
عوامل زمانی که توپولوژی پایه کد شما را درک نمی کنند، عمومی می شوند. آنها به طور پیش فرض از Refactor های گسترده استفاده می کنند زیرا نمی توانند به طور قابل اعتماد درزهای صحیح را پیدا کنند. به نماینده یک کارت مخزن بدهید که کوتاه، صاحب نظر و در قسمتهای مهم باشد.
یک عکس فوری قابل خواندن توسط ماشین از ساختار پروژه و نقاط ورودی کلیدی خود ایجاد کنید. آن را زیر چند صد خط نگه دارید. زمانی که پوشه های اصلی تغییر کرد، آن را به روز کنید. سپس قبل از هر کدنویسی، کارت را داخل عامل قرار دهید.
در اینجا یک ژنراتور ساده وجود دارد که می توانید نگه دارید tools/repo_map.py:
از آنجایی که pathlib واردات مسیر INCLUDE_EXT = {“.py”، “.ts”، “.tsx”، “. برو”، “.جاوا”، “.rs”} SKIP_DIRS = {“node_modules”، “.git”، “فاصله”، “ساختن”، “__pycache__”} ریشه = مسیر(__سپرده__).حل کند().پدر و مادر[1] خطوط = [] برای ص در مرتب شده است(ریشه.rglob(“*”)): اگر هر(بخش در SKIP_DIRS برای بخش در ص.قطعات): ادامه اگر ص.is_file() و ص.پسوند در INCLUDE_EXT: گزارش دهید = ص.نسبت_به(ریشه) خطوط.اضافه کردن(خ(گزارش دهید)) چاپ کنید(“\n”.ملحق شدن(خطوط[:600])) |
بخش دومی را اضافه کنید که نام فایل های واقعی “داغ” باشد، نه همه چیز. مثال:
امتیاز ورودی:
api/server.ts(مسیریابی HTTP)core/agent.ts(برنامه ریزی + تماس ابزار)core/executor.ts(سفارش دونده)packages/ui/App.tsx(پوسته جلویی)
کنوانسیون های کلیدی:
- هرگز فایل های تولید شده را تغییر ندهید
dist/ - همه پایگاه داده پاس می نویسد
db/index.ts - پرچم های ویژگی در آن موجود است
config/flags.ts
این امر فضای جستجوی عامل را کاهش می دهد و از بازنویسی “مفید” نیمی از مخزن به دلیل گم شدن آن جلوگیری می کند.
2. تغییرات را ابتدا با بودجه متفاوت اعمال کنید
ماموران از ریل خارج می شوند وقتی آنها مانند یک انسان با مدت نامحدود ویرایش می کنند. آنها را مجبور کنید مانند یک مشارکت کننده منضبط رفتار کنند: راه حلی پیشنهاد کنید، آن را کوچک نگه دارید و هدف را توضیح دهید. یک نکته مفید یک بودجه تفاضلی است، یک محدودیت صریح در ردیفهایی که در هر تکرار تغییر میکنند.
از یک گردش کار مانند زیر استفاده کنید:
- عامل یک طرح و لیستی از فایل ها را تولید می کند
- عامل فقط یک تفاوت یکپارچه ایجاد می کند
- شما پچ را اعمال می کنید
- تست های اجرا شده
- پچ بعدی فقط در صورت لزوم
اگر حلقه عامل خود را ایجاد کنید، مطمئن شوید که آن را به صورت مکانیکی اجرا می کنید. مثالی از شبه منطق:
MAX_CHANGED_LINES = 120 دف count_changed_lines(unified_diff: خ) -> بین المللی: برگشت مجموع(1 برای دو برابر کردن در unified_diff.خطوط تقسیم() اگر دو برابر کردن.شروع می شود((“+”، “-“)) و نه دو برابر کردن.شروع می شود((“+++”، “—“))) اصلاح شد = count_changed_lines(تفاوت) اگر اصلاح شد > MAX_CHANGED_LINES: افزایش دهد ValueError(f“تفاوت خیلی بزرگ: خطوط {تغییر شده” اصلاح شدند”) |
برای گردش کار دستی، محدودیت را در درخواست خود وارد کنید:
- فقط تفاوت یکپارچه را نشان دهید
- محدودیت سخت: 120 ردیف در کل اصلاح شده است
- بدون قالب بندی یا تغییر شکل نامربوط
- اگر به موارد بیشتری نیاز دارید، توقف کنید و پچ دوم را بخواهید
عوامل به خوبی به محدودیت های قابل اندازه گیری پاسخ می دهند. “آن را به حداقل برسانید” مبهم است. “120 خط تغییر کرد” قابل اجرا است.
3. نیازمندی ها را به آزمون های پذیرش اجرایی تبدیل کنید
درخواست های مبهم می توانند مانع از ویرایش صحیح صفحه گسترده شما توسط یک نماینده شوند، چه رسد به ایجاد کد صحیح. سریعترین راه برای به ثمر رساندن یک نماینده، هر مدل طراحی آنشامل ترجمه الزامات به آزمایش قبل از اجرا است. آزمایش را به عنوان قراردادی در نظر بگیرید که نماینده باید از آن پیروی کند، نه به عنوان یک افزونه که تمام تلاش خود را انجام می دهد.
یک مدل سبک وزن:
- یک تست شکست بنویسید که رفتار ویژگی را نشان دهد
- تست را اجرا کنید تا مطمئن شوید که به دلیل درستی ناموفق است
- اجازه دهید تا عامل اجرا شود تا تست انجام شود
مثال در پایتون (pytest) برای یک محدود کننده جریان:
واردات زمان از آنجایی که myapp.حد نرخ واردات SlidingWindowLimiter دف test_allows_n_requests_per_window(): آهک = SlidingWindowLimiter(محدود کردن=3، window_seconds=1) تایید کردن آهک.اجازه می دهد(“u1”) تایید کردن آهک.اجازه می دهد(“u1”) تایید کردن آهک.اجازه می دهد(“u1”) تایید کردن نه آهک.اجازه می دهد(“u1”) زمان.بخواب(1.05) تایید کردن آهک.اجازه می دهد(“u1”) |
عامل اکنون یک هدف عینی دارد. اگر “فکر می کند” انجام شده است، آزمایش تصمیم می گیرد.
این را با بازخورد ابزار ترکیب کنید: عامل باید مجموعه آزمایشی را اجرا کند و نتیجه دستور را بچسباند. این یکی از الزامات یک طبقه کامل از موفقیت های مطمئن اما نادرست را از بین می برد.
قطعه سریعی که به خوبی کار می کند:
- مرحله 1: تست ها را بنویسید یا اصلاح کنید
- مرحله 2: تست ها را اجرا کنید
- مرحله 3: تا زمانی که تست ها قبول شوند اجرا کنید
همیشه دستورات دقیقی را که اجرا کردید و خلاصه آزمایش نهایی را وارد کنید.
اگر تست ها شکست خوردند، شکست را در یک پاراگراف توضیح دهید و سپس تصحیح کنید.
4. یک مرحله “Rubber Duck” برای تشخیص مفروضات پنهان اضافه کنید
عوامل در مورد شکل داده ها، مناطق زمانی، رسیدگی به خطا و همزمانی فرضیات بی صدا دارند. شما می توانید این فرضیات را بیان کنید با یک لحظه “اردک لاستیکی” اجباری، درست قبل از کدنویسی.
سه چیز را به ترتیب بپرس:
- مفروضات ساخته شده توسط عامل
- چه چیزی می تواند این فرضیات را از بین ببرد؟
- چگونه می خواهیم آنها را تأیید کنیم؟
مختصر و واجب باشد. مثال:
- قبل از کدنویسی: 5 فرض را فهرست کنید
- برای هر یک: یک مرحله اعتبار سنجی با استفاده از کد یا گزارش های موجود
- اگر فرضیه ای قابل تایید نیست، یک سوال روشن کننده بپرسید و متوقف شوید
این یک مکث ایجاد می کند که اغلب از تعهدات بد معماری جلوگیری می کند. همچنین به شما یک بازرسی بازبینی ساده می دهد. اگر با فرضی موافق نیستید، میتوانید آن را قبل از اینکه عامل کدی را که آن را ترکیب میکند بنویسد، تصحیح کنید.
یک پیروزی رایج، تشخیص سریع تناقضات قرارداد داده است. مثال: عامل فرض می کند که مهر زمانی است ISO-8601اما API میلیثانیهها را برمیگرداند. که عدم تطابق می تواند به لغو اشتراک «رفع اشکال» تبدیل شود. اردک لاستیکی او را بیرون می کشد.
5. خروجی عامل را با دستور العمل های اجرا قابل تکرار کنید
کدنویسی عامل در تیم ها ناموفق است زمانی که هیچ کس نمی تواند کاری که عامل انجام داده را بازتولید کند. این مشکل را با نیاز به دستور العمل اجرا حل کنید: دستورات دقیق و یادداشت های محیطی مورد نیاز برای تکرار نتیجه.
یک قرارداد ساده را بپذیرید: هر اجرای عامل با a خاتمه می یابد RUN.md قطعه ای که می توانید آن را در توضیحات روابط عمومی جای گذاری کنید. باید شامل پیکربندی، دستورات و نتایج مورد انتظار باشد.
مدل:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | ## دستور را اجرا کنید محیط زیست: – سیستم عامل: – زمان اجرا: (گره/پایتون/برو نسخه) سفارشات: 1) <سفارش دهید> 2) <سفارش دهید> مورد انتظار: – آزمایشات: <خلاصه> – مخمل خواب دار: <خلاصه> – دستی بررسی کنید: <چی دارد کلیک کنید یا حلقه> مثال برای الف گره API تغییر دهید: ## دستور را اجرا کنید محیط زیست: – گره 20 سفارشات: 1) npm اینجا 2) npm تست کنید 3) npm اجرا کنید مخمل خواب دار 4) گره اسکریپت ها/دود.js مورد انتظار: – آزمایشات: 142 عبور کند – مخمل خواب دار: 0 خطاها – دود: “درسته” چاپ شده است |
این باعث می شود کار نماینده قابل حمل باشد. این همچنین به شما اجازه می دهد تا استقلال صادقانه را حفظ کنید. اگر عامل نتواند یک دستور اجرای تمیز تولید کند، احتمالاً این تغییر را انجام نداده است.
نتیجه گیری
وقتی با آن مانند مهندسی رفتار کنید نه محیط، کدگذاری عامل به سرعت بهبود می یابد. کارت های ریپو سرگردانی کور را متوقف می کنند. تفاوت بین وصله ها امکان بررسی تغییرات را فراهم می کند. آزمایش اجرایی الزامات مبهم را به اهداف عینی تبدیل می کند. یک ایست بازرسی اردک لاستیکی مفروضات پنهان را قبل از اینکه به اشکال تبدیل شوند، آشکار می کند. دستور العمل های اجرایی کل فرآیند را برای هم تیمی ها قابل تکرار می کند.
این ترفندها از توانایی های عامل نمی کاهد. آن را تیز می کنند. استقلال زمانی مفید می شود که محدود، قابل اندازه گیری و مرتبط با بازخورد واقعی ابزارها باشد. این زمانی است که یک نماینده چشمگیر به نظر نمی رسد و کار حمل و نقل را شروع می کند که می توانید آنها را ادغام کنید.
