دستیار کدنویسی وقتی مفید است که همکار منضبط باشد، نه مولد جواب تصادفی. خیلی از دستیارها هنوز نامطمئن حس می‌شوند و دلیلش فقط کیفیت مدل نیست. محصول دور کار ساختار کافی ندارد. اگر دستیار بتواند هر چیزی را ویرایش کند، همه‌چیز را بخواند، و قصد را از زمینه مبهم حدس بزند، مثل دستگاه شانس خیلی سریع رفتار می‌کند. هر بار دسته را می‌کشی و امیدوار ی نتیجه این بار به کارت مربوط باشد.
این درد در تیم زود دیده می‌شود. روی قابلیت اطمینان، توجه، هزینه، و اعتماد اثر می‌گذارد. توسعه‌دهنده اگر سه بار پشت هم diff نامربوط بگیرد، ابزار را برای کار جدی کنار می‌گذارد و فقط برای سوال‌های بی‌خطر نگه می‌دارد. آن‌وقت هزینه مدل می‌ماند و اهرم می‌رود.
تجربه را عمداً تنگ کن
این الگو را وقتی می‌سازم که کار تکراری است، موفقیت تعریف دارد، و نگهداری از اول مهم است. اگر کاربرد مبهم است، اول محدوده را کوچک کن. زیرساخت عمومی دور مسئله حل‌نشده نساز.
تجربه را تهاجمی محدود می‌کنم. محدوده فضای کار را کوچک کن. کار را صریح کن. زمینه پروژه را از اول بده، نه اینکه مدل خودش در ریپو پرسه بزند. تحلیل فقط‌خواندنی را از عمل نوشتن جدا کن. کاربر وقتی دستیار خوانا و محدود است اعتماد می‌کند، حتی اگر این یعنی بیشتر «نه» بشنود. نه گفتن به ویرایش خارج از پوشه ارزان‌تر از تمیز کردن ویرایش اشتباه است.
کار را در یک جمله بنویس. شکل ورودی و خروجی را مشخص کن. کدام بخش مال مدل است و کدام در کد عادی. اگر به صورتحساب، مجوز، داده پروداکشن، یا وضعیت قابل دیدن کاربر می‌خوری، اپ با اعتبار سخت مالک پیامد بماند. مدل جایی کمک کند که کار مبهم است. برای دستیار کد، «داده پروداکشن» شامل راز داخل ریپو و فایل محلی پیکربندی هم هست. آن مسیرها پیش‌فرض بیرون فضای کار باشند.
ریتم کار: نگاه، طرح، ویرایش، تأیید
الگویی که دوست دارم کار مرحله‌ای است. اول بازرسی، بعد طرح، بعد ویرایش، آخر تأیید. دستیار باید فرض را روی سطح بیاورد، تغییر را محلی نگه دارد، و نشان دهد نتیجه را چطور سنجیده. این ریتم به کار مهندس قوی نزدیک‌تر است از تولید یک‌ضرب یک پچ بزرگ.
بازرسی یعنی فایل و تست مرتبط، نه خلاصه کل ماژول. طرح باید آن‌قدر کوتاه باشد که بشود در یک نگاه رد کرد. ویرایش اگر از پوشه اعلام‌شده بیرون زد، شکست است نه ابتکار. تأیید باید همان دستوری باشد که تیم از قبل قبول دارد. جمله مدل که «تست‌ها پاس شدند» تأیید نیست، مگر اینکه خود اجرا در لاگ باشد.
مسیر کد را کسل نگه دار. مسیر API تمیز، صف برای کار ناهم‌زمان، اعتبار خروجی تایپ‌دار، و لاگ دور گام گران. نسخه اول باید صادقانه شکست بخورد: حالت ناقص روشن، خطای قابل بازیابی، مسیر موفقیت باریک. خودمختاری قبل از استحقاق همان حس دستگاه شانس را برمی‌گرداند، فقط با کلمات مطمئن‌تر.
رد کار را نگه دار
ثبت کن دستیار به چه چیزی دست زد، کدام تست اجرا شد، و بازبینی دستی هنوز کجا لازم است. دستیار وقتی ارزش دارد که تکانه بسازد بدون اینکه حسابرسی را نابود کند. اگر فردا کسی بپرسد این خط از کجا آمد، جواب نباید «احتمالاً مدل» باشد. باید بشود به یک اجرا، یک diff، و یک تأیید انسان رسید.
پروداکشن را فراموش نکن. تلاش دوباره، مهلت، صف، محدودیت نرخ، متریک، و جمله‌ای برای توضیح رفتار ناقص. اگر گردش کار کند یا گران یا ناهماهنگ می‌شود، قبل از استفاده واقعی بگو چطور مهارش می‌کنی. تلاش دوباره روی ویرایش ناموفق اگر محدوده را هر بار بزرگ‌تر کند، هزینه را با آشفتگی ضرب می‌کند. بازگشت باید به همان کار برگردد، نه به «یک بار دیگر کل ریپو را ببین».
اشتباه‌ها و شروع کوچک
بزرگ ساختن نسخه اول چون کاربرد آینده شاید لازم داشته باشد. تعریف نکردن موفقیت، طوری که کیفیت و تأخیر و قابلیت اطمینان هدف متحرک شوند. نادیده گرفتن دست انسان، طوری که هم‌تیمی برای دخالت مجبور شود کل سیستم را مهندسی معکوس کند.
از یک کاربرد محدود شروع کن و قرارداد خروجی را صریح کن. نتیجه را قبل از وابستگی بقیه کد اعتبار کن. حداقل مشاهده را برای تأخیر، شکست، و هزینه همان گردش کار بگذار. به کاربر واقعی فقط وقتی بده که رفتار کمی‌خراب را دیدی.
هدف تقلید هم‌تیمی نابغه نیست. ساختن هم‌تیمی قابل اتکاست. این معمولاً یعنی محدوده تنگ‌تر، قرارداد روشن‌تر، و ژست جادویی کمتر. اگر کاربر نتواند قبل از فشردن دکمه بگوید دستیار حق دارد کدام فایل را عوض کند، هنوز دستگاه شانس داری، حتی اگر مدل این ماه بهتر شده باشد.
یک آزمون ساده دارم. همان کار را دو بار، با زمینه ثابت، اجرا کن. لازم نیست خروجی بیت‌به‌بیت یکی باشد. لازم است محدوده فایل و نوع تغییر یکی بماند. اگر بار دوم پوشه دیگری را باز کرد، محصول هنوز به شانس تکیه دارد و باید محدوده را در کد ببندی، نه در پرامپت مؤدبانه.
خوانا بودن مهم‌تر از جسارت است
دستگاه شانس فقط وقتی بد است که نتیجه غلط باشد؟ نه. حتی نتیجه درست، اگر نفهمی چرا این فایل عوض شد، اعتماد نمی‌سازد. دفعه بعد که غلط باشد هیچ علامتی نداری که این بار فرق کرده. برای همین فرض‌ها باید قبل از ویرایش دیده شوند. «فکر کردم این مؤلفه مسئول اعتبار است» جمله‌ای است که انسان می‌تواند در دو ثانیه رد کند. پچ دویست‌خطی همان فرض را قایم می‌کند.
جدا کردن خواندن از نوشتن این خوانایی را ممکن می‌کند. در حالت خواندن، دستیار می‌تواند بگوید چه دیده و چه پیشنهادی دارد و هیچ فایلی عوض نشود. کاربر با یک عمل جدا وارد نوشتن می‌شود، آن هم داخل محدوده اعلام‌شده. اگر محصول این دو حالت را یکی کند، هر سؤال اکتشافی ریسک ویرایش تصادفی دارد و کاربر یاد می‌گیرد سؤال نپرسد. این یعنی ابزار از کار افتاده، حتی اگر متریک استفاده بالا باشد.
خروجی را کوچک نگه دار. یک تغییر محلی که تست مشخصی را هدف گرفته، بهتر از بازآرایی همسایه است که مدل «در مسیر دیده». بازآرایی اگر لازم است، کار جدا با قرارداد جداست. قاطی کردنش با رفع باگ همان حسی را می‌دهد که دسته دستگاه را کشیده‌ای: نمی‌دانی کدام بخش جایزه است و کدام بخش هزینه.
برای تیم، قرارداد را در ریپو بگذار تا سلیقه هر توسعه‌دهنده محدوده را عوض نکند. فضای کار، حالت پیش‌فرض فقط‌خواندنی، و فرمان تأیید، سیاست‌اند نه تنظیم شخصی. دستیار منضبط آن است که اغلب سطح کوچک‌تری از حداکثر توان مدل را نشان می‌دهد. اگر محصولت همیشه حداکثر را نشان می‌دهد، داری شانس را با سرعت بیشتر می‌فروشی.