فلسفه یونیکس

در یونیکس، کدها تنها برای کار راه انداختن، یا فروختن چیزی نیستند. در یونیکس قرار است همه چیز متعالی باشد. فلسفه‌ای پشت هر کار و هر اقدام وجود داشته باشد و تمام برنامه‌نویسان و توسعه‌دهندگان آن‌هم، به این نکته معتقدند. از مکلروی، خالق پایپ‌ها1 و یکی از بنیانگذاران سنت یونیکس، فلسفه یونیکس را این‌طور خلاصه می‌کند: »فلسفه یونیکس این است، برنامه‌هایی بنویسید که یک کار بکند و آن را خوب انجام دهد. برنامه‌هایی بنویسید که با هم کار کنند. برنامه‌هایی بنویسید که جریان‌های متن را مدیریت کند، چون متن یک رابط بین‌المللی است.« این فلسفه معمولا به این صورت خلاصه می‌شود‌: »یک کار بکن، اما آن یک کار را خوب انجام بده.«
کد خبر: ۲۵۹۹۰۱

راب پایک، یکی از اعضای تیم یونیکس درباره برنامه‌نویسی به‌زبان ‌C‌ در یونیکس، این‌گونه می‌نویسد: ‌ ‌

1. نمی‌توانید بفهمید برنامه کجا وقتش را صرف می‌کند. اشتباهات درست در جاهایی که انتظار ندارید رخ می‌دهند، بنابراین تا زمانی که نفهمیدید ایراد از کجاست، دست به کد خود نزنید.

2. اندازه بگیرید. تا زمانی که ابزارهای تحلیل‌تان به‌شما آماری از بازدهی نرم‌افزار نداده‌اند، دست به سریع‌تر کردن آن نزنید. ‌ ‌

3. الگوریتم‌های عجیب و غریب در داده‌های کوچک از الگوریتم‌های ساده، ‌کندتر عمل می‌کنند، درجه این الگوریتم‌ها (‌On)‌ است و معمولا این ‌n‌ کوچک است. بنابراین تا زمانی که مطمئن نشدید که ‌n‌ شما بزرگ نیست، سراغ الگوریتم‌های خاص نروید. ‌ ‌

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

5. داده‌محوری. یادتان باشد که تنها زمانی یک نرم‌افزار خوب خواهید داشت که ساختار داده‌های آن درست طراحی شده باشد. ‌ ‌

مایک گانکارز، یکی از اعضای گروه مخترع سیستم پنجره اکس2 بر اساس تجارب شخصی‌شان و همچنین بحث‌هایی که با دیگر برنامه‌نویسان می‌کردند، فلسفه یونیکس را به 9 پارامتر اساسی منتهی کردند که بدین‌شرح است:

1. کوچک زیباست. ‌ ‌

2. هر برنامه را طوری بنویسید که یک کار را خوب انجام بدهد.

3. سریع برنامه را مستند کنید.

4. قابلیت حمل را بر کارایی ترجیح دهید.

5. داده‌ها را در فایل‌های متنی ذخیره کنید.

6. از اهرم نرم‌افزاری برای پیش‌برد خود استفاده کنید.

7. از اسکریپت‌های پوسته برای افزایش تاثیر و قابلیت حمل استفاده کنید.

8. از رابط‌های کاربری محدود کننده بپرهیزید.

9. هر برنامه، خود یک فیلتر است. ‌ ‌

البته، ده پارامتر دیگر هست که وارد فلسفه یونیکسی بشود. اما بحث در مورد آن بالاست و در برخی جاها مناظره‌هایی تند انجام می‌شود. این ده پارامتر، بدین ‌شرح هستند:

1. به کاربران اجازه دهید خودشان محیط را تغییر دهند.

2. هسته سیستم کوچک و سبک باشد.

3. از حروف کوچک و کلمات کوتاه استفاده کنید.

4. چیزی را چاپ نکنید! درختان را نجات دهید.

5. سکوت طلاست.

6. موازی بیندیشید.

7. جمع تمام بخش‌ها همواره از کل بزرگتر است.

8. بدتر بهتر است.

9. به‌دنبال 90 درصد راه حل باشید.

10. سلسله مراتبی بیندیشید.

بدتر، بهتر است؟

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

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

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

آقای اریک ریموند در کتاب هنر برنامه‌نویسی یونیکس، فلسفه یونیکس را در «اصل بوسه4» (ساده و احمقانه نگه‌اش دار) خلاصه می‌کند. همچنین وی فهرستی از قوانین نوشتن برنامه، به‌سبک یونیکسی را تنظیم کرده است: ‌ ‌

قانون ماجولار بودن: برنامه‌ها جدا جدا باشند که رابطی تر و تمیز آن‌ها را به‌هم پیوند بدهد.

قانون شفافیت: شفافیت از هوشمندی بهتر است.

قانون تجمعی: برنامه‌ها را طوری طراحی کنید که به برنامه‌های دیگر وصل شوند.

قانون جداسازی: سیاست از مکانیزم جداست؛ رابط کاربری از موتور یک برنامه.

قانون سادگی: ساده‌سازی کنید؛ تنها وقتی لازم است، سراغ پیچیدگی‌ها بروید.

قانون کم‌خرجی: برنامه بزرگ را وقتی بنویسید که با هیچ روش کوتاه‌تری نشود کار کرد.

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

پی‌نوشت‌ها

 Pipe.1‌

 X Window System.2‌

 Monolithic.3‌

KISS Principle: Keep It Simple Stupid.4‌

منابع

http://www.linfo.org/unix_philosophy.html

http://www.faqs.org/docs/artu/ch01s06.html

محمدرضا قربانی

newsQrCode
ارسال نظرات در انتظار بررسی: ۰ انتشار یافته: ۰

نیازمندی ها