اسم بد، همون باگ بعدیه
خلاصهٔ کاملتر
نویسنده از اینجا شروع میکنه که هر بار اسم میذاریم، داریم ارتباط برقرار میکنیم: با همکار، با خودِ آیندهمون، و این روزها با مدلهای زبانی. به نظرش وقتی زبان آدم مبهمه، معمولاً یعنی خودِ فهمش هم مبهمه. مثال جالبش اینه که چرا یه مدل تو یه کدبیس تازه و تمیز عالی کار میکنه ولی چند ماه بعد تو همون پروژه گیر میکنه: مدل بدتر نشده، اسمها و اصطلاحات کدبیس، که کل context مدل همونه، مثل یه JPG بارها فشرده و خراب شدن.
به گفتهٔ نویسنده این بیشتر شبیه بسط با اتلافه تا فشردهسازی با اتلاف. مدل از روی یه طرح روشن میتونه بیرونیابی کنه و چیز درستی بسازه، ولی وقتی مدام از روی بیرونیابیِ قبلی بیرونیابی کنیم، آخرش به قصهی کاملاً ساختگی میرسیم. یعنی دووم آوردن کار با مدل تو یه کدبیس، مستقیم به این وصله که چقدر حاضری اصطلاحاتت رو کم و تمیز و دقیق کنی. تیز کردن واژگان و کم کردن پیچیدگی سیستم عملاً یه کارن.
بعد سراغ ولع «یکدستی» میره. خیلیها میپرسن قاعده چیه: مقدار اختیاری رو بذاریم maybe_thing یا thing_opt یا اصلاً تو اسم نیاریم؟ نویسنده میگه اینجور قانونها مثل Clean Code یا رژیمهای اسمدار، محصولیان که وعده میدن تا شما مجبور نباشی فکر کنی. چیزی که باید یکدست بمونه خودِ فرآینده: کد رو از بالا بخون، جای همکارت بذار خودتو، و به تقارن فکر کن. اسمهایی مثل src و dst روی صفحه به هم اشاره میکنن.
قاعدهی مرکزیش اینه: اسم رو از ذاتِ چیز بردار، نه از نیازی که باعث نوشتنش شده. مثال دومش این امضای اسکالاست که داخلش فقط اتحاد دو تا map بوده، یعنی همون template ++ values اصطلاحی:
def mergeTargetValuesIntoSourceTemplate(
template: Map[String, String],
values: Map[String, String]
): Map[String, String]نویسنده میگه چون اسم از روی نیاز ساخته شده، تابع هم فقط برای همون نیاز قابل استفاده مونده و هیچکس موقع جستجوی «ترکیب دو map» پیداش نمیکنه. همین منطق پشت created_at در برابر uploaded_at هم هست: اگه ردیف یه چیز مصنوعی داخل سیستمه، created_at کافیه، ولی اگه سند واقعی کاربره، تاریخ ساختش (مثلاً شناسنامهی ۱۹۹۵) با تاریخ آپلودش یکی نیست.
بدترین حالت رو با فیلد documentDate نشون میده. صفحهی بازبینی اونو تاریخ روی سند میدونه، مسیر ingestion که یک سال قبل نوشته شده روز رسیدن فایل رو توش میریزه، و یه قانون کهنگی هم صورتحسابهای بالای ۹۰ روز رو رد میکنه؛ یعنی برای بخشی از اسناد داره معنی اشتباه رو چک میکنه. حالا اصلاح اسم هم migration و backfill حدسی و ریسک میخواد. حرف نویسنده اینه که کشیدن نخِ یه اسم بد معمولاً به یه گرهی واقعی تو رفتار سیستم میرسه.
نکات کلیدی:
- اسم رو از ذاتِ چیز بردار نه از نیازی که باعث نوشتنش شده؛ روایت نیازت رو با اسم متغیر محلی تو callsite بگو
- DRY یعنی هر واقعیت یک جا بیان بشه؛ دو ثابت که اتفاقی هر دو ۶۴ ان، دو ثابت جدا میمونن
- قانونهای آماده مثل «هیچوقت مخفف نکن» یا «اسم کوتاه بهتره» فرار از فکر کردنن
- تقارن اسمها مهمه: جفتهایی مثل src و dst باید همدیگه رو یادآوری کنن
- اگه طرح تقریباً نهایی شده ولی هنوز نمیتونی اسمش رو بذاری، احتمالاً یه چیزی تو خودِ طرح ایراد داره
- فیلد مبهم documentDate تو مقاله نمونهایه که ابهام اسم مستقیم به باگ رفتاری رسیده
