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