تیم کلود کد چگونه کد را بررسی می کند

قبلا گفته بودیم که کلود حدود 90 درصد از کدهای خود کلود کد را می نویسد. بنابراین چگونه کد را در حجمی که آن را تولید می کنیم بررسی کنیم؟ آیا کسی دیگر کد می خواند؟ و اگر چیزی بشکند، چه کسی آن را می گیرد؟

این پست جریان بررسی کد در تیم Claude Code و چگونگی تکامل آن را پوشش می دهد. از ژوئن تا سپتامبر، درخواست‌های کشش ادغام‌شده به پایگاه کد کلود کد بیش از دو برابر شد در حالی که سهمی که باید برگردانده می‌شد بیش از 40 درصد کاهش یافت.

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

هنگامی که نماینده ها کد می نویسند، تعداد تغییرات به سرعت بالا می رود. در monorepo آنتروپیک، تغییرات فرود در روز از حدود 2500 در ماه می به بیش از 30000 در سپتامبر امسال رسید.

Claude Code در مخزن خود زندگی می کند، جدا از monorepo، اما فشار زیادی را نیز می بیند. هنگامی که شما در حال ارسال این سریع، دستی، بررسی کد خط به خط هستید، اگر غیرممکن نباشد، بسیار دشوار است.

این مقاله عمدتا بر روی یافتن و رفع مشکلات تمرکز دارد، اما ما در پایان به کار دوم باز خواهیم گشت.

ما فکر می کنیم "آیا یک انسان کد را خوانده است؟" یک پروکسی نادقیق برای این است که "چه چیزی ممکن است با این تغییر مشکل داشته باشد، و کدام چک - خودکار یا انسانی - برای گرفتن آن مناسب است؟"

پرسیدن آن سوال نیز با انجام بررسی تغییر کرد. پیش از این، بررسی دروازه ای در انتهای راه بود: کد را بنویسید، یک روابط عمومی باز کنید، منتظر همکار خود باشید.

اکنون، مرور به طور مداوم اجرا می‌شود، بیشتر شبیه بررسی املا در حین نوشتن. اکثر تغییرات قبل از اینکه از انسان خواسته شود حداقل یک بار توسط کلود بررسی و اصلاح شده است. این بیشتر اشتباهات روتین را جلب می کند و توجه تیم را برای سؤالات و بررسی های سطح بالاتر حفظ می کند.

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

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

بنابراین هدف این است که اکثر درخواست‌های کششی در مخازن کلود کد (CLI، برنامه‌های دسکتاپ و وب و برنامه‌های تلفن همراه) با حداکثر یک انسان در حلقه، که می‌تواند نویسنده باشد، ادغام شوند، بدون افزایش در بازگشت‌ها یا حوادث. برای اندازه‌گیری زمان انسانی، تأییدیه‌های انسانی را به ازای هر PR (میانگین و صدک 95)، نظرات انسانی، و مدت زمانی که یک روابط عمومی برای یک فرد منتظر می‌ماند، ردیابی می‌کنیم. نرخ‌های بازگشت و تصادف، نرده محافظ هستند: اگر افزایش یابد، ما در زمان انسان صرفه‌جویی نکرده‌ایم، بلکه فقط آن را جابه‌جا کرده‌ایم.

یک تغییر معمولی، از لپ‌تاپ یک مهندس (یا جلسه کلود در اسلک)، از چندین لایه بازبینی کد عبور می‌کند.

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

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

بوریس چرنی، که کلود کد را ایجاد کرده است، ارائه راهی برای تأیید کار به کلود را احتمالا مهمترین چیز برای به دست آوردن نتایج خوب می‌داند. او تخمین می‌زند که نتیجه نهایی را دو تا سه برابر بهتر می‌کند و می‌نویسد: "تأیید برای هر دامنه متفاوت به نظر می‌رسد. ممکن است به سادگی اجرای دستور bash یا اجرای مجموعه آزمایشی یا آزمایش برنامه در یک مرورگر یا شبیه‌ساز تلفن باشد."

هنگامی که بازبینی خودکار همچنان همان چیزی را پرچم‌گذاری می‌کند، آن را در منبع رفع می‌کنیم: در مهارت، با قانون پرز، یا با به‌روزرسانی فایل‌های آموزشی مانند:

هر درخواست کششی قبل از اینکه شخص نگاه کند، یک بررسی کلود دریافت می کند. تفاوت را در برابر کل مخزن و قصد اعلام شده PR می خواند و می پرسد: آیا تغییر مشکل آن را حل می کند، با سیستم سازگار است یا چیز دیگری را خراب می کند؟

در رفع اشکال، به دنبال علت اصلی است. نسخه عمومی، Code Review for Claude Code، اکنون به طور کلی در برنامه های Team و Enterprise در دسترس است و /code-review یک نسخه سبک تر را به صورت محلی اجرا می کند.

وقتی پیش‌نمایش تحقیق را راه‌اندازی کردیم، سهم روابط عمومی‌های داخلی که نظرات بررسی اساسی را دریافت می‌کردند از 16 درصد به 54 درصد رسید. بیشتر روابط عمومی ها با بیش از 1000 خط، یافته ها را دریافت می کنند، و اغلب موارد کوچک تمیز باز می گردند. مدیران هر مخزن را روی Quick، Standard یا Deep تنظیم می‌کنند. Deep ارزش آن را دارد که یک باگ از دست رفته بیشتر از زمان بررسی اضافی باشد.

یافته ها قبل از اینکه انسان آنها را بررسی کند توسط عوامل دیگر تأیید می شود. چندین عامل به طور همزمان به دنبال باگ می گردند. سپس یک گروه جداگانه به هر یافته رای می‌دهد، و تنها در صورتی پست می‌شود که تعداد زیادی از آنها موافق واقعی بودن آن باشند. یافته هایی که فقط در مورد سبک، تشخیص یا پاکسازی هستند حذف می شوند. ما A/B آن فیلترها را قبل از نگهداری آنها روی PR خودمان آزمایش کردیم. آنچه باقی می ماند به عنوان نظرات درون خطی مرتب شده بر اساس شدت نشان داده می شود. هر کدام با برچسب مهم، Nit یا از قبل موجود هستند، بنابراین اشکالی که PR معرفی نکرده است به نظر تقصیر نویسنده نیست.

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

امنیت نیز بررسی خودکار خود را دریافت می کند. یک PR نمی تواند ادغام شود در حالی که هیچ یافته ای از بررسی اشکال یا بررسی امنیتی هنوز باز است. شما یا آن را درست می کنید یا با یک دلیل کوتاه تاپیک را می بندید، که چگونه مثبت کاذب را پاک می کنید.

اگر commit بعدی مشکل را برطرف کند، یافته به خودی خود پاک می شود. می‌توانید همین مورد را با بررسی امنیتی منبع باز GitHub Action یا فرمان /security-review تنظیم کنید. راه اندازی در بررسی های امنیتی خودکار در Claude Code پوشش داده شده است.

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

اصلاح اسناد و تغییر به‌روزرسانی خودکار خطرات متفاوتی دارند، بنابراین بررسی‌های متفاوتی دریافت می‌کنند.

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

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

هر کسی که این تغییر را تحریک کرده باشد، در حال انجام آن است. در یک PR نوشته شده توسط نماینده، شخصی که نماینده را هدایت می کند به عنوان یکی از بازبینان مورد نیاز به حساب می آید، درست مثل اینکه خودش کد را تایپ کرده باشد.

تایید یک تعهد خاص را پوشش می دهد. اگر زمینی جدید متعهد شود که سیستم نمی تواند آن را تضمین کند، مانند فشار یک عامل یا ادغام شخصی که با دست حل شده است، تأیید باید دوباره داده شود.

صف ادغام هر بررسی را با تغییر اعمال شده مجددا در برابر main اجرا می کند، بنابراین دو PR که به طور جداگانه عبور می کنند نمی توانند در یک اصلی شکسته ترکیب شوند. رفتار جدید معمولا ابتدا در پشت پرچم برای کارمندان آنتروپیک ارسال می شود و استفاده زیاد ما اغلب قبل از اینکه کاربران انجام دهند، رگرسیون را نشان می دهد. انتشارات عمومی ابتدا به آخرین کانال بروید. کانال پایدار آن را دنبال می کند.

برخی از اشتباهات همچنان برطرف خواهند شد، بنابراین آخرین لایه مربوط به گرفتن سریع آنها است. پرچم ها بدون استقرار خاموش می شوند. Claude Code یک چرخش در حین تماس هفتگی دارد و بررسی‌های رخداد می‌پرسند کدام لایه باید مشکل را تشخیص دهد.

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

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

روند بررسی کد ما به طور مداوم در یک حلقه بهبود می یابد.

هر حادثه ای در حال حاضر یک ارزش است. این تیم PRهای گذشته را که باعث بروز حوادث می‌شدند، با اصلاح و بازگردانی آن‌ها جمع‌آوری کردند و مهندسانی داشتند که آن کد را می‌دانند، هر اشکال و محل زندگی آن را تأیید می‌کنند. بازبینی کننده هر روز بر خلاف آن مجموعه اجرا می کند.

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

وقتی نویسنده یک عامل باشد، نویز هزینه بیشتری دارد. یک فرد می تواند در عرض چند ثانیه یک nit را تکان دهد. یک نماینده آن را برطرف می کند، به این معنی که یک تعهد دیگر و یک دور بررسی دیگر.

بررسی باید همگرا شود. یک نویسنده عامل و یک بازبین نماینده می توانند یکدیگر را به طور نامحدود مشغول نگه دارند. یک CLI PR یک شبه بیش از پنجاه دور بررسی و اصلاحات را پشت سر گذاشت تا نویسنده آن را متوقف کند.

زمانی که ما git blame را بر روی چیزی که بازبین مدام پرچم گذاری می کرد، اجرا کردیم، حدود 59 درصد از آن کدهایی بود که از اولین پاس بازبینی وجود داشت. بازبین به ندرت باگ های جدیدی پیدا می کرد، در هر دور چند اشکال قدیمی دیگر پیدا می کرد.

خودمون بدترش کردیم ما عادت کرده بودیم که چندین راند را به طور پیش فرض اجرا کنیم، زیرا هر پاس چیز جدیدی پیدا می کند. این می تواند در یک تغییر مخاطره آمیز ارزشمند باشد، اما نه در هر روابط عمومی. این تیم اکنون دور به گذر را در کنار فراخوان دنبال می کند و بازبینی مجدد را تغییر داده است:

عوامل بازبینی همچنین هر شب کدهای موجود را اجرا می‌کنند و به ما کمک می‌کنند باگ‌های قدیمی را قبل از اینکه در جای دیگری ظاهر شوند پیدا کنیم.

بیرون کشیدن یک مهندس ارشد از کار عمیق برای گرفتن یک اشتباه روتین بسیار بیشتر از یک بررسی خودکار هزینه دارد. در آنتروپیک، مشاغل ما از خواندن هر تفاوت به تصمیماتی که ماشین‌ها در آنها بد هستند تغییر کرده است:

دومین کار بازبینی کد همیشه گسترش درک کد پایه بوده است. خواندن تفاوت یک هم تیمی این است که چگونه یاد می گیرید چه چیزی تغییر کرده است و چگونه مهره ها جا می گیرند. اگر ماشین‌ها بیشتر خواندن را انجام می‌دهند، چگونه کسی کد را یاد می‌گیرد؟

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

برخی از ما یک قدم فراتر می‌رویم و از کلود می‌خواهیم یک مصنوع کوچک بسازد که آن بخش از کد را تجسم می‌کند و به روشی که آن شخص دوست دارد یاد می‌دهد.

اگر هدف این است که توجه انسان را به خوبی صرف کنیم، این کار خواندن تفاوت های بی اهمیت را خط به خط شکست می دهد. تغییر کپی یک خطی تقریبا هیچ چیز را به شما یاد نمی دهد. توضیح دهنده ماژولی که می خواهید تغییر دهید، چیزهای زیادی به شما می آموزد. فرهنگ پیش‌فرض ما برای کار بر روی کانال‌های باز Slack نیز به ما کمک می‌کند، زیرا می‌بینید که دیگران در حین ساخت آن چه چیزی می‌سازند.

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

مالکیت نیز مشترک است. بسیاری از تیم در کانال‌های باز کار می‌کنند که در آن هر کسی می‌تواند ببیند دیگران چه چیزی می‌سازند، موضوعی را انتخاب کند، یا کلود را به یک شکاف نشان دهد، و بازخورد از افرادی می‌آید که مالک کد نیستند. این باز بودن بخش بزرگی از کیفیت بالا بدون دروازه در هر خط است.

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

از آنجایی که کد برای نوشتن سریع بود، بستن PR به نظر ضرر نمی رسد. ترفند این است که یک جهت متفاوت در موضوع مطرح کنید، نه به عنوان یک نظر مسدود کننده در یک PR تمام شده.

بسیاری از قطعات برای انجام این کار با تیم خود امروز وجود دارد.

در اطلاعیه Code Review آمده است که تأیید درخواست کشش هنوز یک تماس انسانی است. محصول یافته ها را پست می کند، نه تاییدیه ها. مخازن خود ما فراتر رفته و به مالکان اجازه می دهد تصمیم بگیرند که کدام تغییرات کم خطر تنها در چک های خودکار ادغام شوند و این خط به حرکت خود ادامه می دهد.

وقتی مروری چیزی را از دست می‌دهد، ما می‌پرسیم مدل چه چیزی در جلوی خود ندارد و اصلاح را در یک CLAUDE.md، یک مهارت یا یک بررسی جدید قرار می‌دهیم. هدف تغییر نکرده است: زمان کمتری برای انسان برای هر تغییر، و عدم بازگشت بیشتر از قبل.

اگر تیم شما به نمایندگان اجازه می‌دهد درخواست‌های کشش را باز کنند، مایلیم بشنویم که کدام چک‌ها را خودکار کرده‌اید، کدام‌ها هنوز به یک نفر نیاز دارند، و فکر می‌کنید چه اشتباهی داریم.

با تشکر از اما وب، مایکل سگنر و امی روترهام برای نقدهایشان.