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