نگاهی به پدیده «مهندسی بیش‌ازحد» در پروژه‌های نرم‌افزاری

نگاهی به پدیده «مهندسی بیش‌ازحد» در پروژه‌های نرم‌افزاری

تورزا مگ – بارها دیده شده که تیم‌های نرم‌افزاری، به‌جای حل ساده و سریع یک مسئله، سراغ معماری‌های عظیم و پیچیده می‌روند. این پدیده که در ادبیات مهندسی نرم‌افزار با عنوان «مهندسی بیش‌ازحد» (Over-engineering) شناخته می‌شود، یکی از رایج‌ترین تله‌هایی است که برنامه‌نویسان و تیم‌های فنی در آن گرفتار می‌شوند.

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

در این مقاله، نشانه‌ها، ریشه‌ها، هزینه‌های پنهان و اصول مقابله با این پدیده، بر اساس تجارب مستند صنعت نرم‌افزار، بررسی می‌شود.

نشانه‌های کلاسیک: از کجا بفهمیم در دام over-engineering افتاده‌ایم؟

۱. بهینه‌سازی زودهنگام (Premature Optimization)

مورد رایج: تیم‌های نرم‌افزاری هفته‌ها زمان صرف بهینه‌سازی یک کوئری جستجو می‌کنند. ایندکس‌های ترکیبی طراحی می‌شود، کش لایه‌ی دوم پیاده‌سازی می‌گردد، حتی بخش‌هایی به زبان C++ بازنویسی می‌شود. نتیجه: زمان پاسخ از ۲۵ میلی‌ثانیه به ۸ میلی‌ثانیه کاهش می‌یابد. مشکل اینجاست که تعداد کل رکوردهای دیتابیس در آن زمان ۱۲۰ عدد بوده و ترافیک واقعی روزانه ۴۰۰ درخواست ساده داشته است.

هیچ کاربری تفاوت ۱۷ میلی‌ثانیه را حس نمی‌کند، اما تیم انرژی و زمان خود را صرف کاری کرده که می‌توانست صرف تحویل دو قابلیت اصلی دیگر شود. بدتر آنکه کد بهینه‌شده آنقدر پیچیده می‌شود که هر تغییر کوچکی در مدل داده، نیازمند روزها کار است.

اصل مشهور دونالد کروث (Donald Knuth) در اینجا مصداق کامل دارد: «اول درستش کن، بعد سریعش کن. و فقط وقتی سریعش کن که اندازه گرفتی واقعاً کند است.»

۲. سندروم «شاید بعداً لازم شود»

این سندروم، ریشه‌ی بسیاری از معماری‌های عجیب و غریب است. تیم‌ها با خود می‌گویند: «الان که ساده است، اما چه می‌شود اگر فردا…» و فهرستی از سناریوهای خیالی تهیه می‌کنند:

• «شاید بعداً پشتیبانی چندزبانگی کامل نیاز شود» → پس از اول سیستم ترجمه‌ی پویا با fallback پیچیده نوشته می‌شود.
• «شاید یک روز از مونگو به پستگرس مهاجرت کنیم» → ORM آنقدر لایه‌بندی می‌شود که دیگر کسی نمی‌فهمد چطور یک کوئری ساده بنویسد.
• «شاید ترافیک به یک میلیون کاربر برسد» → همین امروز خوشه‌ی کوبرنتیز روی سه منطقه‌ی جغرافیایی راه‌اندازی می‌گردد.

واقعیت آماری: حدود ۸۰٪ این «شایدها» هرگز رخ نمی‌دهند. و اگر هم رخ دهند، کسب‌وکار آنقدر بزرگ شده که توانایی پرداخت هزینه‌ی بازآرایی (Refactoring) را دارد. تلاش برای حل مشکلات احتمالی پنج سال بعد، معمولاً به اتلاف منابع منجر می‌شود.

۳. افراط در استفاده از الگوهای طراحی (Design Patterns)

مشاهده‌ی الگوهایی مانند AbstractFactoryProxyObserverSingleton در کدهایی که فقط سه کلاس ساده دارند، یک نشانه‌ی هشدار است. الگوهای طراحی ابزارهای قدرتمندی محسوب می‌شوند، اما کاربرد بی‌دلیل آنها، کد را غیرقابل خواندن و تغییر می‌کند.

یک اصل معمارانه: به ازای هر اینترفیس جدید، باید پرسید: «آیا واقعاً به چندین پیاده‌سازی نیاز داریم؟» اگر فقط یک راه برای انجام کار وجود دارد، همان تابع ساده کافی است.

ریشه‌های روانی و سازمانی مهندسی بیش‌ازحد

دلایل رایج گرفتاری در این تله عبارتند از:

• ترس از قضاوت همکاران: نگرانی از اینکه کسی بگوید «این کد آماتوری است».
• لذت حل مسئله‌ی فنی: گاهی حل یک چالش معماری (مثل همگام‌سازی کش‌ها) برای توسعه‌دهنده لذت‌بخش‌تر از تحویل قابلیت تجاری است.
• تقلید از شرکت‌های بزرگ: مطالعه‌ی معماری نتفلیکس یا گوگل و تلاش برای پیاده‌سازی مشابه، بدون درنظرگرفتن مقیاس واقعی پروژه.

اصول طلایی نجات از مهندسی بیش‌ازحد

اصل ۱: YAGNI — You Aren’t Gonna Need It

این اصل از برنامه‌نویسی چابک (Extreme Programming) می‌گوید: تنها و تنها چیزی ساخته شود که همین الان به آن نیاز داریم، نه چیزی که حدس زده می‌شود بعداً به کار آید.

آزمون عملی: پیش از نوشتن هر خط کد اضافی، این پرسش‌ها مطرح شوند:

• آیا یک کاربر واقعی همین هفته به این قابلیت نیاز دارد؟
• اگر این ویژگی نوشته نشود، آیا واقعاً چیزی از کار نمی‌افتد؟
• آیا می‌توان پاسخگوی نیاز امروز را با ۲۰ درصد کار داد و ۸۰ درصد باقی را برای «وقتی واقعاً لازم شد» نگه داشت؟

مثال کاربردی: فرض شود API نوشته می‌شود که امروز فقط یک کلاینت (مثلاً فرانت‌اند وب) دارد. نسخه‌ی اول بدون احراز هویت پیشرفته، بدون rate limiting لایه‌ای، و بدون نسخه‌بندی نوشته شود. وقتی کاربر دوم آمد و به احراز هویت نیاز پیدا کرد، آن زمان افزوده شود. در بدترین حالت، اضافه کردن آن یک روز زمان می‌برد.

اصل ۲: KISS — Keep It Simple, Stupid

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

راهکارهای عملی برای ساده‌نویسی:

• استفاده از کتابخانه‌ها و فریمورک‌های استاندارد، مگر اینکه دلیل قانع‌کننده‌ای برای اختراع چرخ وجود داشته باشد.
• نوشتن توابع کوتاه و تک‌منظوره (Single Responsibility).
• نام‌گذاری واضح به گونه‌ای که کد نقش مستند را ایفا کند.
• در صورت نیاز به کامنت برای توضیح پیچیدگی، ذکر دلیل و تاریخ.

اصل ۳: قانون سه‌نکته (Rule of Three) برای انتزاع

راهنمای عملی برای زمان مناسب بازآرایی:

• بار اول: کد فقط پاسخگوی نیاز فعلی باشد. هیچ انتزاع اضافی.
• بار دوم: اگر مشابه کد در جای دیگر نیاز شد، کپی شود. هنوز زمان انتزاع نیست.
• بار سوم: اگر الگو برای بار سوم تکرار شد، آن زمان یک انتزاع مشترک (کلاس، تابع، ماژول) ساخته شود.

این قانون از «انتزاع زودهنگام» جلوگیری می‌کند و تضمین می‌نماید الگوی واقعاً تکراری شناسایی شده است.

اصل ۴: انتزاع زودهنگام نیز ریشه‌ی بدی‌هاست

تغییر جمله‌ی معروف کنوت: «بهینه‌سازی زودهنگام ریشه‌ی همه‌ی بدی‌هاست»، اما تجربه نشان می‌دهد انتزاع زودهنگام (Early abstraction) نیز به همان اندازه مخرب است. هر لایه‌ی انتزاعی هزینه‌ی درک و نگهداری دارد. اگر فقط یک پیاده‌سازی وجود دارد، اینترفیس نوشته نشود.

هزینه‌های پنهان over-engineering

۱. افزایش زمان ورود اعضای جدید به تیم: یک کد ساده با سه کلاس، توسط یک تازه‌وارد در یک روز قابل درک است. یک کد over-engineered با ۱۵ الگو و ۸ لایه، ممکن است هفته‌ها زمان برای فهم نیاز داشته باشد.

۲. مقاومت در برابر تغییر: هرچه سیستم پیچیده‌تر باشد، ترس از تغییر بیشتر می‌شود. سرانجام اضافه کردن یک فیلد ساده به دیتابیس نیازمند تغییر در پنج فایل مختلف و سه روز تست خواهد بود.

۳. اشکال‌زدایی سخت‌تر: وقتی خطایی در لایه‌ی پنجم انتزاع رخ می‌دهد، استک‌تریس آنچنان عمیق است که ردیابی محل واقعی خطای کسب‌وکار دشوار می‌شود.

۴. اتلاف بودجه و زمان تحویل: مهم‌تر از همه، صرف میلیون‌ها تومان هزینه‌ی توسعه‌ای که می‌توانست صرف قابلیت‌های ارزش‌آفرین برای کسب‌وکار شود.

چه زمانی مهندسی بیش‌ازحد «شدیداً لازم» است؟

برای انصاف، باید گفت مواردی وجود دارد که همان «آرپی‌جی زدن به پشه» منطقی است. اما نه برای یک پشه‌ی معمولی؛ بلکه وقتی پشه ناقل مالاریا باشد و در منطقه‌ای با میلیون‌ها پشه زندگی کند. شرایطی که over-engineering هوشمندانه ضرورت پیدا می‌کند:

• سیستم‌های زمان واقعی با خطای صفر: مثل تجهیزات پزشکی، کنترل ترافیک هوایی، یا ربات‌های صنعتی. در اینجا ایمنی بر سادگی اولویت دارد.
• سیستم‌هایی با مقیاس عظیم اثبات‌شده: اگر امروز یک میلیون کاربر فعال روزانه وجود دارد و رشد ۲۰۰٪ سالانه، طراحی برای مقیاس منطقی است.
• نرم‌افزارهای کتابخانه‌ای با کاربری گسترده: کتابخانه‌ای که هزاران پروژه از آن استفاده می‌کنند، نیازمند انعطاف‌پذیری بیشتر است.
• زمانی که هزینه‌ی تغییر بعدی نجومی است: مثل سیستم‌های embedded با آپدیت سخت فریم‌ور.

برای اکثر پروژه‌های معمولی وب یا موبایل، «ساده‌ترین راهی که کار کند» بهترین راه است.

تمرین عملی: چگونه از over-engineering جلوگیری کنیم؟

قبل از شروع کدنویسی:

• تهیه‌ی یک سند یک‌صفحه‌ای با عنوان «حداقل نیازهای فعلی». هر چیزی خارج از آن برای فازهای بعدی نگهداری شود.
• توافق تیمی بر این مبنا که «معماری ساده‌ی امروز پذیرفته شده است و در صورت نیاز بعداً تغییر خواهد کرد».
• استفاده از تکنیک «پرسش‌های معکوس»: برای هر تصمیم فنی که به نظر آینده‌نگر می‌آید، پرسیده شود «اگر این کار را نکنیم، بدترین اتفاق چیست؟» اگر پاسخ «هیچ اتفاق بدی نمی‌افتد، فقط بعداً باید یک روز وقت گذاشت»، آن تصمیم گرفته نشود.

حین کدنویسی:

• پیش از افزودن هر لایه‌ی انتزاعی، ابتدا همان نیاز با کد خطی و ساده پیاده‌سازی شود. سپس در صورت تکرار واقعی، انتزاع انجام گردد.
• تعیین حداکثر طول برای توابع و کلاس‌ها (مثلاً ۵۰ خط). عبور از این حد، معمولاً نشانه‌ی انجام چند کار همزمان یا پیچیدگی بیش‌ازحد است.
• بازبینی کد با این پرسش که «آیا یک توسعه‌دهنده‌ی جدید با سه ماه سابقه می‌تواند این کد را درک کند؟»

در فرآیند بازبینی کد (Code Review):

• بازبین، در مواجهه با لایه‌های اضافه، بپرسد: «آیا راه ساده‌تری وجود ندارد؟ به جای X چرا از Y استفاده نشده است؟»
• نویسنده، در صورت استفاده از یک الگوی طراحی، در کامنت پول‌ریکوئست توضیح دهد که «این الگو به دلیل نیاز به … استفاده شده است». در صورت ناتوانی در ارائه‌ی توضیح قانع‌کننده، بهتر است از آن الگو صرف‌نظر شود.

جمع‌بندی: کد خوب، کدی است که مسئله را حل کند، نه کدی پر از نشان‌های افتخار فنی

بسیاری از توسعه‌دهندگان با تجربه، روزگاری شیفته‌ی معماری‌های چندلایه، الگوهای عجیب و بهینه‌سازی‌های زودهنگام بوده‌اند. اما پس از سال‌ها و مشاهده‌ی پروژه‌هایی که به دلیل همین پیچیدگی‌ها با شکست مواجه شده‌اند، به این جمع‌بندی رسیده‌اند که هنر واقعی در ساده‌سازی است. همان‌طور که آنتوان دو سنت‌اگزوپری گفته است: «کمال زمانی به دست می‌آید که دیگر چیزی برای افزودن نمانده باشد، نه زمانی که چیزی برای گرفتن نمانده باشد.» در معماری نرم‌افزار، «کمتر» اغلب «بیشتر» است.

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