# فلسفة يونكس

فلسفة يونكس، أصلها من أعمال كين ثومبسون، وهي مجموعة من المبادئ الثقافية والمناهج الفلسفية لتطوير برامج حاسوب بسيطة ونمطية تعتمد هذه الفلسفة على خبرة خبرات كبار المطورين الطلائعيين لنظام تشغيل يونكس. كان لمطوري يونكس الأوائل دورٌ هام في إدخال مفاهيم النمطية وإعادة الاستخدام في ممارسة هندسة البرمجيات، مما أدى إلى ظهور حركة "الأدوات البرمجية". تؤكد فلسفة يونكس على بناء برامج صغيرة، بسيطة، نظيفة وعلى شكل وحدات، وقابلة للتطوير والتوسيع يسهل صيانتها وتعديل الغاية منها من قبل مطورين غير أولئك الذي كتبوها. بمرور الوقت، وضع كبار مطوري يونكس (والبرامج التي تعمل عليه) مجموعة من المعايير الثقافية لتطوير البرمجيات. أصبحت هذه المعايير بنفس أهمية وتأثير تقنية يونكس نفسها، وأُطلق عليها اسم "فلسفة يونكس".
تُشدد فلسفة يونكس على بناء كود برمجي بسيط ومختصر وواضح ونمطي وقابل للتوسيع، بحيث يسهل صيانته وإعادة استخدامه من قبل مطورين آخرين غير أولئك الذين قاموا بإنشاءه. تُفضل فلسفة يونكس قابلية التركيب والتجميع بدلاً من التصميم المتكامل الضخم.

## المنشأ

تتمثل فلسفة يونكس كما وثقها دوغلاس ماكلروي في مجلة بيل سيستم التقنية عام ١٩٧٨ في الآتي:
* اجعل كل برنامج يقوم بمهمة واحدة على أكمل وجه. لإنجاز مهمة جديدة، ابدأ من الصفر بدلًا من تعقيد البرامج القديمة بإضافة "ميزات" جديدة.
* توقع أن يصبح مخرج كل برنامج مدخلًا لبرنامج آخر، لم يُكتشف بعد. لا تُثقل المخرج بمعلومات زائدة. تجنب تنسيقات الإدخال الجدولية أو الثنائية الصارمة. لا تُصر على الإدخال التفاعلي.
* صمم وابنِ البرمجيات، حتى أنظمة التشغيل، ليتم تجربتها مبكرًا، يُحبذ خلال أسابيع. لا تتردد في التخلص من الأجزاء الرديئة وإعادة بنائها.
* استخدم أدوات عوضاً من المساعدة غير الماهرة لتخفيف مهمة برمجية، حتى لو اضطررت إلى الانحراف لبناء تلك الأدوات، وتوقع التخلص من بعضها بعد الانتهاء من استخدامها.
وقد لخصها لاحقًا بيتر إتش. سالوس في "ربع قرن من يونكس" عام ١٩٩٤م في الآتي:
* اكتب برامج تقوم بمهمة واحدة وتؤديها على أكمل وجه.
* اكتب برامج تعمل معًا.
* اكتب برامج للتعامل مع تدفقات النصوص، لأنها واجهة عالمية.
في ورقة يونكس الخاصة بهما عام ١٩٧٤م، اقتبس ريتشي وثومبسون اعتبارات التصميم التالية:
* اجعل كتابة البرامج واختبارها وتشغيلها أمرًا سهلًا.
* الاستخدام التفاعلي بدلًا من المعالجة التدفقية.
* توفير وأناقة التصميم بسبب قيود الحجم ("الخلاص من خلال المعاناة").
* نظام مكتفٍ ذاتيًا: تتم صيانة جميع برمجيات يونكس تحت يونكس.

## الأجزاء
### بيئة برمجة يونكس

في مقدمتهما لكتابهما الصادر عام ١٩٨٤ بعنوان "بيئة برمجة يونكس"، قدم كل من برايان كيرنيغان وروب بايك، وهما من مختبرات بل، وصفًا موجزًا لتصميم وفلسفة يونكس:
وكتب المؤلفان أيضًا أن هدفهما من هذا الكتاب هو "نقل فلسفة برمجة يونكس".

### تصميم البرامج في بيئة يونكس

في أكتوبر عام ١٩٨٤، نشر كل من برايان كيرنيغان وروب بايك ورقة بحثية بعنوان "تصميم البرامج في بيئة يونكس". في هذه الورقة، انتقدوا التراكم المتزايد لخيارات وميزات البرامج الموجودة في بعض أنظمة يونكس الحديثة مثل 4.2BSD و System V، وشرحوا فلسفة يونكس لأدوات البرمجيات، حيث تؤدي كل أداة وظيفة عامة واحدة:
يقارن المؤلفان أدوات يونكس مثل الأمر cat بمجموعات البرامج الأكبر المستخدمة من قبل أنظمة أخرى.

### إفعل شيئاً واحداً وأتقنه

كما ذكر ماكلروي، وهو مبدأ مقبول عمومًا في مجتمع يونكس، يُفترض دائمًا أن تتبع برامج يونكس مفهوم "اِفْعَلْ شَيْئًا وَاحِدًا وَأَتْقِنْهُ" (Do One Thing And Do It Well - DOTADIW). توجد مصادر محدودة للاختصار DOTADIW على الإنترنت، لكن يُناقَش هذا المفهوم بإسهاب خلال تطوير وتعبئة أنظمة التشغيل الجديدة، خاصةً في مجتمع لينكس.
استشهد باتريك فولكردينغ، قائد مشروع سلاكوير ، بمبدأ التصميم هذا في انتقاد لبنية systemd، حيث ذكر أن "محاولة التحكم في الخدمات والمآخذ والأجهزة ووحدات التخزين، إلخ، كلها داخل عملية كبرنامج خفي (daemon) واحدة تتعارض مع مفهوم يونكس المتمثل في فعل شيء واحد وإتقانه."

### قواعد يونكس السبعة عشر لإريك ريموند

في كتابه "فن برمجة يونكس" الذي نُشر لأول مرة عام ٢٠٠٣، لخص إريك إس. ريموند (المدافع عن المصادر المفتوحة والمبرمج) فلسفة يونكس بمبدأ "اجعلها بسيطة، يا غبي". وقدم سلسلة من قواعد التصميم:
* بناء برامج نمطية (وحدات منفصلة)
* كتابة برامج قابلة للقراءة (سهلة الفهم)
* استخدام التركيب (تجميع البرامج الصغيرة لإنشاء برامج أكبر)
* فصل الآليات عن السياسات (فصل طريقة العمل عن القرارات)
* كتابة برامج بسيطة
* كتابة برامج صغيرة
* كتابة برامج شفافة (واضحة العمل)
* كتابة برامج قوية (متحملة للأخطاء)
* جعل البيانات معقدة عند الحاجة، وليس البرنامج
* البناء على المعرفة المتوقعة للمستخدمين المحتملين
* تجنب المخرجات غير الضرورية
* كتابة برامج تفشل بطريقة يسهل تشخيصها (معرفة سبب الخطأ)
* توفير وقت المبرمج أهم من توفير وقت الجهاز
* كتابة برامج مجردة تُنشئ الكود بدلاً من كتابة الكود يدوياً
* عمل نموذج أولي للبرنامج قبل إصداره
* كتابة برامج مرنة ومفتوحة
* جعل البرنامج والبروتوكولات قابلة للتوسيع.

### ملاحظات بايك حول البرمجة بلغة C

يقترح روب بايك القواعد التالية كمبادئ أساسية للبرمجة، ومع ذلك، يمكن اعتبارها أيضًا أفكارًا جوهرية لفلسفة يونكس:
* القاعدة الأولى: لا يمكنك تحديد أي جزء من البرنامج سيستهلك الجزء الأكبر من الأداء. نظرًا لأن الاختناقات غالبًا ما تظهر في أماكن مفاجئة، يجب ألا تقوم بتضمين أي شيء لزيادة السرعة قبل أن تُثبت مكان وجود الاختناق.
* القاعدة الثانية: قِس وقت تشغيل البرنامج. لا تعمل على تحسين السرعة إلا بعد قياسها، وحتى بعد ذلك، فقط عندما يستهلك الجزء الذي يتم فحصه جزءًا كبيرًا من وقت الحساب.
* القاعدة الثالثة: الخوارزميات المعقدة تكون بطيئة عندما يكون حجم بيانات الإدخال n صغيرًا (انظر نظرية التعقيد)، وهذا هو الوضع الطبيعي. للخوارزميات المُحسّنة تكاليف ثابتة كبيرة. ما لم تكن تعلم أن n سيأخذ قيمًا كبيرة بشكل متكرر، يجب عليك تجنب الخوارزميات المُحسّنة. (وحتى عندما يصبح n كبيرًا، تنطبق القاعدة الثانية أولاً.)
* القاعدة الرابعة: الخوارزميات المعقدة أكثر عرضة للأخطاء من الخوارزميات البسيطة وأكثر صعوبة في التنفيذ. استخدم الخوارزميات البسيطة وهياكل البيانات البسيطة.
* القاعدة الخامسة: البيانات أكثر أهمية. إذا اخترت هياكل البيانات الصحيحة وتم تصميم كل شيء جيدًا، فستظهر الخوارزميات دائمًا تقريبًا من تلقاء نفسها. هياكل البيانات هي الموضوع المركزي في البرمجة، وليست الخوارزميات.
* القاعدة السادسة: لا توجد قاعدة سادسة.
تُكرر القاعدتان 1 و 2 المبدأ الشهير لدونالد إي. كنوث: "التحسين المُبكر هو أصل كل شر". صاغ كين تومبسون القاعدتين 3 و 4 على أنهما "استخدم القوة الغاشمة عند الشك"؛ هذه القواعد هي أمثلة على مبدأ KISS (اجعلها بسيطة، أيها الغبي). القاعدة 5 مأخوذة من فريد بروكس، الذي ذكرها في كتاب "أسطورة الشهر-الرجل" وغالبًا ما تُصاغ على أنها "اكتب كودًا غبيًا يستخدم بيانات ذكية". القاعدة 6 مأخوذة من مسرحية بروس من مونتي بايثون فلاينج سيركس (الحلقة 22).

### مايك جانكارس: فلسفة يونكس

في عام ١٩٩٤، نشر مايك جانكارس، العضو في فريق هندسة يونكس في شركة ديجيتال إكوبمينت كوربوريشن (UEG)، كتاب "فلسفة يونكس" بناءً على تجربته في تطوير نظام (Ultrix) في شركة DEC في الثمانينيات ومناقشاته مع زملائه. وهو أيضًا عضو في فريق تطوير نظام النوافذ X ومؤلف مدير نوافذ Ultrix (uwm).
يركز الكتاب على نقل نظام يونكس إلى أجهزة كمبيوتر مختلفة خلال "حروب يونكس" في الثمانينيات ويصف فلسفته التي تنص على أن قابلية النقل يجب أن تكون أكثر أهمية من كفاءة استخدام واجهات غير قياسية للأجهزة وأجهزة الرسوميات.
المبادئ الأساسية التسعة التي يرى أهميتها هي:
* البساطة جمال.
* اجعل كل برنامج يقوم بمهمة واحدة على أكمل وجه.
* أنشئ نموذجًا أوليًا في أقرب وقت ممكن.
* اختر قابلية النقل على الكفاءة.
* خزّن البيانات في ملفات نصية بسيطة.
* استخدم قوة البرمجيات لصالحك.
* استخدم نصوص واجهة سطر الأوامر لزيادة القوة وقابلية النقل.
* تجنب واجهات المستخدم الاحتكارية.
* اجعل كل برنامج مُرشِّحًا (filter).

### مبدأ "الأسوأ أفضل"

يرى ريتشارد بي. غابرييل أن إحدى المزايا الرئيسية لنظام يونكس كانت تجسيده لفلسفة تصميم أسماها "الأسوأ أفضل"، حيث تكون بساطة كل من الواجهة والتنفيذ أكثر أهمية من أي سمات أخرى للنظام - بما في ذلك صحة واتساق واكتمال المخرجات. يرى غابرييل بأن نمط التصميم هذا له مزايا تطورية رئيسية، على الرغم من أنه يشكك في جودة بعض النتائج.
على سبيل المثال، في الأيام الأولى، استخدم يونكس نواة متجانسة (مما يعني أن عمليات المستخدم نفذت استدعاءات نظام النواة جميعها على مكدسة المستخدم). إذا تم إرسال إشارة إلى عملية أثناء حظرها على إدخال/إخراج طويل الأجل في النواة، فإن التعامل مع الموقف كان غير واضح. لا يمكن تنفيذ معالج الإشارة عندما تكون العملية في وضع النواة، مع وجود بيانات حساسة للنواة على المكدس.

### مكإلوري: ربع قرن من يونكس

دوجلاس مكإلوري، لخص فلسفة يونكس، عندما كان رئيسا لمختبرات بيل ومشاركا في تطوير «انابيب يونكس» بالآتي: