ما ۰.۱ ثانیه توی اجرا صرفه‌جویی کردیم، ولی ۳ روز از عمر تیم رو به باد دادیم!

چند وقت پیش توی پروژه‌ای بودم که یکی از بچه‌ها وسواس عجیبی روی سرعت داشت. ما یه کد تر‌ و تمیز داشتیم که کار میکرد. ولی این همکارم گفتش که: "نه، این تابعی که نوشتی کنده! بذار پرفورمنسش رو ببرم بالا."

شروع کرد به تغییرات عجیب به بهانه‌ی اینکه فراخوانی توابع سربار (Overhead) داره، توابعِ کوچیک و خوانا رو حذف کرد و همه رو ریخت توی یه تابعِ. شرط‌های if/else شفاف رو تبدیل کرد به یک خط محاسبه‌ی ریاضی پیچیده تا CPU کمتری مصرف بشه.

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

نتیجه؟ کاربر نهایی اصلا متوجه اون سرعت ناچیز نشد (چون گلوگاه اصلا اونجا نبود). اما چند وقت بعد، وقتی بیزینس یه تغییر کوچیک خواست، ما فلج شدیم.

کدی که قبلا توی ۱۰ دقیقه ادیت میشد، حالا شده بود یه میدون مین. هیچ‌کس نمیفهمید اون خط طولانی ریاضی دقیقا داره چی‌کار میکنه. ما خوانایی رو قربانی یه سرعت توهمی کرده بودیم.

اینجا بود که یاد جمله‌ی معروف دونالد کنوث افتادم: "بهینه‌سازی زودهنگام (Premature Optimization)، ریشه‌ی تمام دردسرهاست."

ما داشتیم دقیقا همین مصیبت رو سر خودمون میاوردیم و قانونِ طلایی Uncle Bob رو فراموش کرده بودیم:

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

ما یاد گرفتیم بهینه‌سازی واقعی این نیست که کد رو فشرده کنی. بهینه‌سازی واقعی اینه که کدی بنویسی که نفر بعدی (یا خود ۶ ماه بعدت) بتونه راحت بخونه و توسعه‌ش بده.