پیچیدگی ذاتی و پیچیدگی تصادفی

دو مفهوم "Essential Complexity" و "Accidental Complexity" اولین بار توسط فرد بروکس (Fred Brooks)، برنده جایزه تورینگ، در مقاله معروفش No Silver Bullet در سال ۱۹۸۶ مطرح شد. بروکس دو نوع پیچیدگی رو تعریف کرد:

1. پیچیدگی ذاتی Essential Complexity که از خود دامنه مسأله و مشکل نشأت گرفته میشه و بدون کاهش محدوده مسأله حذف شدنی نیست.
2. پیچیدگی تصادفی Accidental Complexity که توسط خود راه‌حل ایجاد میشه، مثل استفاده از یک فریم‌ورک (Framework)، پایگاه داده، یا زیرساخت‌های دیگر...

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

مثلاً کانتینرها (Containers) رو در نظر بگیرید که قرار بود میزبانی از اپلیکیشن‌ها ما رو راحت کنه. ولی بعدتر نیاز به ارکستریتور (Orchestrator) داشتیم و کار به Kubernetes رسید. و حالا بیشتر زمان خودمون رو صرف نوشتن فایل‌های YAML میکنیم تا کدنویسی واقعی.

پیچیدگی ذاتی مستقیماً به فضای مشکل مربوط میشه، چون از خود مشکل ناشی میشه. ولی پیچیدگی تصادفی بیشتر به فضای راه‌حل مرتبط هست، چون از ابزارها و روش‌هایی که برای حل مشکل استفاده می‌کنیم، میاد.

بیاید برای نمونه یک مثال واقعی رو بررسی کنیم: یک گزارش که قبلاً ماهانه تولید میشد، حالا باید به صورت بلادرنگ (Real-Time) اجرا بشه. بعد از چند ماه تیم توسعه، تخمین زد که تکمیل این قابلیت حداقل ۶ ماه دیگه زمان میبره و ۱ میلیون پوند هزینه داره. دلیلش هم این بود که دیتابیس تراکنشی (Transactional Database) بهینه نبود و باید از روش‌هایی مثل شاردینگ (Sharding)، توزیع جغرافیایی (Geographical Distribution)، و تکرار داده‌ها (Replication) استفاده میشد.

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

خیلی وقت‌ها ما توسعه‌دهنده‌ها عاشق اصولی مثل DRY هستیم و به دنبال انتزاع‌هایی هستیم که کدمون رو شیک‌تر کنه. ولی گاهی این انتزاع‌ها کاملاً غیرضروریه. این همون چیزی هست که بهش میگن
Over-Engineering

پس قانون کلی اینه که پیچیدگی ذاتی رو بپذیریم و پیچیدگی تصادفی رو کم کنیم، و معمولاً این پیچیدگی تصادفی به خاطر مهندسی بیش از حد (Over-Engineering) به وجود میاد.

دسته‌بندی پیچیدگی‌ها کمک می‌کنه قبل از حل مسأله بفهمیم که با چه سطحی از پیچیدگی روبرو هستیم. یک چارچوب خیلی معروف برای این کار هست به اسم Cynefin که توسط Dave Snowden و Mary Boone در یک مقاله در سال ۲۰۰۷ معرفی شد.

ابزارهایی مثل DDD، EventStorming و Event Sourcing به ما کمک می‌کنن پیچیدگی‌های رو بهتر مدیریت کنیم.