پیچیدگی و نشانه‌های آن
___________

کتاب A Philosophy of Software Design نوشته‌ی John Ousterhout، میاد و سه نشانه (manifestation) از پیچیدگی در سیستم مطرح میکنه و اینجا میخوام این سه مورد رو باهم مرور کنیم:

- Change Amplification

یک تغییر ساده [در یک عملکرد کلی]، نیازمند تغییر در قسمت‌های مختلفه. دم دستی ترین مثال ممکن که احتمالا در ذهنتون بی‌درنگ نشست، استفاده از یک ثابته (مثل کد رنگ) که در تمام تابع‌ها داره به‌کار برده میشه و هر جا هم یک اسمی داره و ما قراره اون رو عوض کنیم. حالا یک تغییر ساده‌ی ما amplify شد و از یکی شد ۱۰۰ تا (مشابه write amplification در دیتابیس‌ها که گاهی یک رایت ساده، منجر به چسبیدن IO به سقف میشه).

- Cognitive Load

چقدر یک توسعه‌دهنده نیازه که [راجع‌به سیستم] بدونه برای این که یک تسک رو به سرانجام برسونه. هرچقدر این «دونستن» بیشتر لازم باشه، به طبع نیازمنده تا زمان بیشتری رو صرف یادگیری کنه تا تسک مذکور رو انجام بده و این تعدد نیاز به دانستن‌ها، ریسک به وجود اومدن باگ رو بیشترو بیشتر می‌کنه.

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

کاهش تعداد خط با خیال کاهش پیچیدگی در نهایت می‌تونه به افزایش cognitive load منجر بشه و مارو از اون رویای شیرین، به وسط کابوس کد‌بیس پیچیده پرتاب کنه.

- Unknown unknowns

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

unknown unknown means that there is something you need to know, but there is no way for you to find out what it is, or even whether there is an issue.

در این حالت، برای ما روشن نخواهد بود که چه کار باید بکنیم، یا اونچه که قصد انجامشو داریم اصلا کاراست یا نه.

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


پی‌نوشت:
- از عباس عزیز واقعا ممنونم بابت معرفی کتاب.

- کتاب رو دو روزه که شروع کردم و دلم میخواد تیکه‌هاییش که برام جالبه یا ممکنه برای شما جالب باشه رو چه با نقل و قول مستقیم، چه غیرمستقیم اینجا هم بنویسم.

- بجز تعریف سیستم پیچیده که به شکل تعریف نشانه‌هاش بالاتر ازش حرف زدیم و مختص به سیستم‌های نرم‌افزاری بود، بد نیست یک گریزی بزنیم به کتاب Melanie Mitchell
با عنوان «سیری در نظریه پیچیدگی» (عنوان اصلی کتاب، Complexity: A Guided Tour) که اون هم کتابیه خوندنی و توصیه‌ش میکنیم. در انتهای فصل اول کتاب، سیستم پیچیده رو به دو شکل تعریف میکنه:

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

و تعریف دوم:

سیستمی که رفتار‌های نا‌بدیهی (nontrival) و نوظهور و خود-سازمان را به‌نمایش میگذارد.

که فکر میکنم تعریف دوم، بیشتر با شرح نشانه‌هایی که از یک سیستم نرم‌افزاری دیدیم هم‌سو باشه.