تولد یک مکتب فکری در آزمایشگاه‌های بل

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

تاریخچه سیستم عامل یونیکس و آزمایشگاه بل

اصول چهارگانه و ثبت نام رسمی

داگ مک‌ایلروی، مخترع مکانیزم پیپ در یونیکس، در سال 1978 سبک رفتاری توسعه‌دهندگان این اکوسیستم را در چهار اصل کلیدی مستند کرد:

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

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

قدرت ترکیب‌پذیری و زنجیرهٔ ابزارها

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

اتصال ابزارهای خط فرمان یونیکس به هم

درس تاریخ: چرا دستور cat الگو شد؟

برای درک عمیق «انجام یک کار به‌خوبی»، می‌توان به دستور cat نگاه کرد. این دستور کار ساده‌ای دارد: محتوای چند فایل متنی را در خروجی چاپ می‌کند. سادگی ظاهری آن به این معناست که هزاران ابزار دیگر می‌توانند از این خروجی خام برای فیلتر کردن، کپی کردن یا تجزیه‌وتحلیل داده استفاده کنند. نویسندگان در مقاله سال 1984 خود، این رویکرد را در تقابل با سیستم‌هایی مانند CP/M قرار دادند که تمام عملیات مدیریت فایل را در یک محیط واحد و تو در تو متمرکز می‌کردند. نتیجهٔ آن مقایسه واضح بود: تمرکزگرایی شاید در ظاهر کار را ساده‌تر نشان بدهد، اما انعطاف‌پذیری و قابلیت نگهداری بلندمدت را به‌شدت کاهش می‌دهد.

خطر تورم قابلیت‌ها و درس امروز

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

وراثت یونیکس در معماری مدرن نرم‌افزار

امروزه اصول شکل‌گرفته در سال‌های اولیهٔ رایانش، فراتر از خط‌دستور و سیستم‌عامل‌های کلاسیک رخنه کرده‌اند. معماری‌های میکروسرویس که در آن هر سرویس فقط مسئولیت یک خاصیت عملیاتی را بر عهده دارد، مستقیم‌ترین بازتاب همین فلسفه است. حتی توسعهٔ ابزارهای DevOps و کانتینرها نیز بر همین پایه استوارند: هر اپلیکیشن یا ابزار باید یک کار اصلی را با بالاترین کیفیت انجام دهد و از طریق API یا استریم‌های استاندارد با دیگر مؤلفه‌ها در تعامل باشد.

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