YAGNI: آشنایی با قانونی که در فرآیند توسعهٔ نرم‌افزار باید از آن‌ اجتناب کرد

YAGNI: آشنایی با قانونی که در فرآیند توسعهٔ نرم‌افزار باید از آن‌ اجتناب کرد

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

اولین کسی باشید که به این سؤال پاسخ می‌دهید

چگونه کدهای غیرضروری را تشخیص دهیم؟
در یک کلام، بایستی به حس ششم خود اعتماد کنید! به عنوان مثال، ایجاد یک کلاس یا اینترفیس با تنها یک به اصطلاح ساب‌کلاس ممکن است این ذهنیت را به‌ وجود آورد که بعداً به ساب‌کلاس‌های بیشتری نیاز است اما در عوض با تمرین و کدنویسی زیاد به این نتیجه می‌رسید که ساب‌کلاس دوم را نباید ایجاد کرد مگر اینکه واقعاً به آن نیاز داشته باشیم. بلوک زیر که با زبان ++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 موقعیت‌های به مراتب بیشتری را شامل می‌شود که برخی از مهم‌ترین آن‌ها عبارتند از:

- کدی که در غیر از موارد تست، هرگز اجرا نمی‌شود.
- کلاس‌هایی که طراحی شده‌اند تا به عنوان ساب‌کلاس مورد استفاده قرار گیرند در حالی که واقعاً یک ساب‌کلاس نیستند.
- پارامترها، متغیرها و مواردی که همیشه مقداری ثابت دارند.

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

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

منبع