آشنایی با مفهوم YAGNI در کدنویسی

آشنایی با مفهوم YAGNI در کدنویسی

پیش از این در مقاله‌ای تحت عنوان راه‌کارهای گوگل جهت تست نرم‌افزار در سرویس‌ بهداشتی! گفتیم که تعدادی از Googlerها (دولوپرهای گوگل) گروهی تحت‌عنوان Google Testing Grouplet تشکیل داده‌اند که هدفش اصلی‌شان تمرکز بر فرایند تست نرم‌افزار است که در این مقاله هم قصد داریم یکی دیگر از استراتژی‌های کدنویسی این گروه را بررسی کنیم.

اکثر هزینه‌های توسعهٔ نرم‌افزار، صرف نگهداری و ریفکتورینگ کدهای آن می‌شود و این در حالی است که یکی از راه‌های کاهش هزینه‌های نگهداری نرم‌افزار این است که کدی را بنویسید که واقعاً به آن نیاز دارید. این اصل تحت عنوان YAGNI شناخته می‌شود (YAGNI برگرفته از عبارت You Aren`t Gonna Need It به معنای «شما به آن احتیاج نخواهید داشت» است).

چگونه کدهای غیرضروری را تشخیص دهیم؟
در یک کلام، بایستی به حس ششم خود اعتماد کنید! به عنوان مثال، ایجاد یک کلاس پایه‌ای یا یک اینترفیس با تنها یک زیرکلاس (Sub-class) ممکن است این ذهنیت را به‌ وجود آورد که بعداً به زیرکلاس‌های بیشتری نیاز است. در عوض با تمرین و کدنویسی زیاد به این نتیجه می‌رسید که «زیرکلاس دوم را ایجاد نکن مگر اینکه واقعاً به آن نیاز داشته باشی!» کدهای ++C زیر تعداد زیادی YAGNI را درون خود جای داده‌ است:

class Mammal { ...
  virtual Status Sleep(bool hibernate) = 0;
};
class Human : public Mammal { ...
  virtual Status Sleep(bool hibernate) {
    age += hibernate ? kSevenMonths : kSevenHours;
    return OK;
  }
};

زمان دولوپرهایی که وظیفهٔ نگهداری از سورس‌کدها را بر عهده دارند با درک، مستندسازی و تست هر دو کلاس گرفته می‌شود اما این در حالی است که در عمل فقط به یکی از این کلاس‌ها نیاز داریم. این کد وقتی که مقدار hibernate برابر با True باشد یا حتی اگر تمام جاهایی که این کلاس فراخوانی شده مقدار False پاس داده شده باشد یا وقتی که Sleep اروری بازگرداند (گرچه چنین چیزی بعید است)، برنامه را کنترل و اجرا می‌کند. این نتیجه‌ای غیرضروری برای کد ما است که هرگز به مرحله‌ٔ اجرا نمی‌رسد. حذف این موارد کد را ساده‌تر می‌کند:

class Human { ...
  void Sleep() { age += kSevenHours; }
};

برخی دیگر از موارد YAGNI را می‌توان به شکل زیر بیان‌ کرد:
- کدی که در غیر از موارد تست، هرگز اجرا نمی‌شود (یا کدی که همان اول کار غیرفعال می‌شود).
- کلاس‌هایی که طراحی شده‌اند تا یک زیرکلاس باشند در حالی که واقعاً یک زیرکلاس نیستند.
- متدهای public (عمومی) یا private (خصوصی) یا فیلدهایی که می‌توانند خصوصی باشند.
- پارامترها، متغیرها و مواردی که همیشه مقداری ثابت دارند.

به طور کلی در هر کدی می‌توان ردپای YAGNI را حس کرد و اغلب موارد با یک نگاه به سورس‌کد می‌توان آنها را یافته و حذف کرد. حال نوبت به‌ نظرات شما می‌رسد. به‌ نظر شما آیا راه‌کارهایی از این دست می‌توانند به دولوپرها در بهبود فرایند‌های کاری‌شان کمک کنند؟ نظرات و دیدگاه‌های خود را در این رابطه با ما و سایر کاربران سکان به اشتراک بگذارید.

منبع


علی‌اکبر محمدی