آشنایی با اصل YAGNI در توسعه نرم‌افزار

مدتی پیش وقتی یکی از همکاران برنامه‌نویس از تیم ما جدا می‌شد من مسئول تحویل گرفتن کدهایی شدم که نوشته بود. با هم جلسه‌ای گذاشتیم و کدهای نوشته شده را مرور کردیم، در حین این کار من لیستی از کدهای مختلف و پراکنده‌ای که قابلیت حضور در یک کتابخانه مستقل را داشتند برداشتم. صدها خط کد که با اضافه شدن به یک کتابخانه مشترک از تکرار بیهوده آن‌ها جلوگیری می‌شد.
اغلب این کدها به برنامه‌نویسی شیرپوینت مربوط بودند. همان زمان با مجموعه‌ای از کدهای آماده مربوط به شیرپوینت در زمینه‌های مختلف آشنا شده بودم. هدف اولم این بود که همه این کدها را در کنار هم تبدیل به یک کتابخانه بزرگ بکنم که برای هر کاری در شیرپوینت بشود از آن استفاده کرد. اما همان اولین ساعاتی که شروع به آماده سازی کتابخانه کد کردم، از این کار منصرف شدم. دلیلش به یاد آوردن اصل YAGNI بود.

فقط کدی که الان لازم دارید را بنویسید

اعضای یک تیم نرم‌افزاری هر روز ده‌ها خط کد به مجموعه کدها اضافه می‌کنند تا یک یا چند feature به نرم‌افزار خروجی اضافه شود. یک راه درست برای مدیریت کدهای قابل استفاده مجدد این است که آن‌هایی که در یک حوزه هستند را در قالب یک کتابخانه کد کامپایل کرده و در صورت نیاز به کدهای موجود اضافه کنیم. اما همیشه و برای همه برنامه‌نویسان این وسوسه وجود دارد که کدهایی را تولید کنند که ممکن است در آینده به آنها نیاز پیدا کنند یا کدهایی تولید کنند که مشابه آن‌ها هست اما از نظر آن‌ها مطابق نیازشان نیست.

این ذهن ایده‌آل گرای برنامه‌نویسانی که دوست دارند همه چیز را در کلی‌ترین حالت ممکن تولید کنند و کاری کنند که در آینده بتوان به اشکال مختلف آن را سفارشی کرد باعث ایجاد دردسرهای بزرگی برای تیم و مجموعه نرم‌افزارهای تولیدی آن می‌شود.

YAGNI یا You aren't gonna need it‌ اصلی است که می‌گوید تا زمانی که نیاز نشده کدی را ننویسید. این اصل برنامه‌نویسان را تشویق به سبک نگه داشتن منطق برنامه و همچنین استفاده از کدهای موجود می‌کند. ضمناً گوشزد می‌کند که نوشتن کدهایی که ممکن است در آینده به آن‌ها نیازی پیدا شود فقط وقت تلف کردن است.

وقتی بتمن به رابین سیلی می‌زند که چرا YAGNI را رعایت نکرده، شما از مدیر پروژه‌تان انتظار دارید در صورت عدم رعایت YAGNI با شما مهربان باشد؟ ;)

دلیل مهمی که برای YAGNI آورده می‌شود این است که کدی که شما با پیش‌بینی آینده می‌نویسید به احتمال زیاد در آینده برای شما مفید نخواهد بود! چرایی این مساله هم خیلی روشن است: شما امروز و بر اساس تفکرات امروز اقدام به طراحی و پیاده‌سازی کد می‌کنید. اگر به همین صورت مساله مثلاً 6 ماه دیگر نگاه بکنید ممکن است روش متفاوتی را برای پیاده‌سازی آن در نظر بگیرید.
علاوه بر این باید در نظر گرفت که زمان و در نتیجه هزینه کلی نوشتن کدهای اضافی برای یک کتابخانه فقط شامل هزینه نوشتن کد نیست،‌ بلکه باید هزینه دیباگ و تست و احتمالاً توسعه آن در آینده (به دلیل عدم شناخت کافی از مساله‌ای که امروز آن را در اختیار نداریم!) هم زمان‌بر و هزینه‌بر است.

به همین علت لازم است همیشه تنها کدهایی را داشته باشید که از آن‌ها استفاده می‌کنید. برگردیم به داستانی که اول این مطلب برایتان گفتم. بعد از به یاد آوردن اصل YAGNI تنها کدهایی که برای عموم پروژه‌ها از آن استفاده می‌شد را به کتابخانه اضافه کردم و اولین نسخه از کتابخانه مورد نظر در زمان کوتاهی آماده شد. از آن زمان به بعد این کتابخانه 3 نسخه جدیدتر هم داشته است و در هر نسخه تعدادی تابع که از آن‌ها در پروژه‌های جدیدتر هم استفاده می‌شده اضافه شده است. کتابخانه‌ کد که می‌رفت شامل هزاران خط کد بی‌استفاده باشد تبدیل به یک کتابخانه ساده و سبک (زیر 100 کیلوبایت) شده که تنها کدهایی که مورد استفاده هستند در آن قرار گرفته. این کار باعث شده تا رفع باگ احتمالی در این کتابخانه و نگهداری کد آن بسیار ساده باشد.

دقت داشته باشید که در YAGNI سایز کد شما اهمیتی ندارد، مثلاً اگر کتابخانه اصلی شیرپوینت (Microsoft.SharePoint.dll) را در نظر بگیرید در شیرپوینت 2013 یک کتابخانه با حجمی بیش از 25 مگابایت است، اما وقتی به عنوان یک API برای کار با شیرپوینت و داده‌های ذخیره شده در آن به این کتابخانه نگاه می‌کنید، در هیچ حوزه‌ای کد اضافی نمی‌بینید. شاهد این مدعا وجود کدهایی مثل کتابخانه‌ای که در ابتدای مطلب به آن اشاره کردم هست. در واقع یک راه مطمئن شدن از اینکه اصل YAGNI را رعایت کرده‌اید این است که دیگران بتوانند روی کدهای شما کتابخانه درست کنند، اگر این‌طور نباشد یعنی شما به همه حالات ممکن فکر کرده باشید و همه توابع ممکن را نوشته باشید بدانید که بخشی از کد تولید شده شما، آنچنان بی‌کیفیت است که خیلی زود مجبور به تغییر آن خواهید شد و تغییر در کد به دلیل مسائلی مثل حفظ سازگاری با نسخه‌های قبلی یکی از هزینه‌بر ترین بخش‌های توسعه نرم‌افزار است.

اصل دیگری هم در همین راستا وجود دارد به نام KISS یا Keep it simple,stupid که در نوشته دیگری درباره آن صحبت خواهم کرد.