القوانين العبثية لعالم البرمجيات

صورة لمشغل الكاسيت كومودور 64

تم تحميل برنامج Commodore 64 من مشغل كاسيت.

هل تساءلت يومًا لماذا يخطئ الأشخاص الأذكياء مثل مطوري البرامج كثيرًا؟ هناك أناس فعلوا ذلك. في هذا المنشور نراجع بعض القوانين غير المكتوبة التي تصف سلوك المحترفين من الحوسبة.

كان أول جهاز كمبيوتر لي هو Commodore 64. كان ما يقرب من 30 كيلو من ذاكرة الوصول العشوائي للنظام ، مما ترك 32 كيلو بايت لمعالجة الكلمات والألعاب والمحاسبة للأعمال العائلية ، وكل ما أفعله تقريبًا مع جهاز الكمبيوتر 6 جيجابايت الذي أملكه الآن. هذا يترك السؤال مفتوحًا. هل المعدات الحالية تلبي احتياجات البرنامج ، أم أن البرنامج يستخدم المزيد من موارد الأجهزة لأنها متوفرة؟

في الإنصاف ، الألعاب ليست متشابهة ، والرسومات ليست بنفس الجودة أيضًا ، وكان من المستحيل مشاهدة الأفلام والاستماع إلى الموسيقى. ومع ذلك ، لا يسع المرء إلا أن يفكر في ذلك هناك برامج تطلق إصدارات وتستهلك المزيد والمزيد من الموارد دون المساهمة بأي شيء جديد.

ها هي الأسباب.

قانون زاوينسكي

جادل جيمي زاوينسكي ، مطور في Netscape ، بذلك يتضمن كل برنامج ميزات حتى يصبح قادرًا على قراءة رسائل البريد الإلكتروني. إذا لم ينجح ، يحل محله آخر قادر على ذلك.

عندما صرح بذلك ، كانت النكتة أنه كان يشير إلى برامج لم يكن المقصود منها في الأصل أن تكون عملاء بريد. لم يعد الأمر مضحكًا عندما تم اكتشاف أن العديد من التطبيقات على Google Play تطلب الإذن للوصول إلى مكونات الهاتف وبيانات المستخدم التي لم تكن بحاجة إليها للقيام بعملهم.

فسر البعض ذلك على أنه جزء من محاولات التجسس على المستخدمين. لكن من المحتمل أن تكون الطبيعة البشرية أن تفعل شيئًا لمجرد أنه يمكن القيام به.

ينطبق مبدأ بيتر على البرمجيات

اشتهر لورانس بيتر بقوله أنه في التسلسل الهرمي ، يرتفع الشخص حتى يصل إلى منصب يكون فيه غير كفء بشكل واضح. لكن كان لديه أيضًا الوقت ليقول شيئًا عن المشاريع المعقدة:

"سيصبح المشروع المعقد معقدًا جدًا بحيث لا يمكن فهمه حتى من قبل مطوريه."

المبدأ الأقل مفاجأة

نُشر هذا المبدأ في مجلة IBM Systems Journal في عام 1984 ، وينص على ما يلي:

"إذا تسببت الميزة المطلوبة في مفاجأة كبيرة ، فقد يكون من الضروري إعادة تصميم الميزة."

وبعبارة أخرى، إذا كان جزء من البرنامج أو كله مختلفًا تمامًا عما اعتاد المستخدم عليه ، فإن أفضل ما يمكن فعله هو إعادة التصميم. المثالي هو السعي لتحقيق التحسينات التدريجية الكبيرة بما يكفي لتكون مثيرة للإعجاب ، ولكنها صغيرة بما يكفي لتبقى مألوفة للمستخدم.

سيء للغاية لم يأخذ Shuttleworth ذلك في الاعتبار عندما أصدر Unity.

قانون علم الحشرات السيبرنيتيك

كان أول خطأ (خطأ) في تاريخ الكمبيوتر حقيقيًا. طارت فراشة في أحد مرحلات كمبيوتر MARK II مما تسبب في حدوث عطل.

استمرارًا للاستعارة ، ينص قانون علم الحشرات السيبراني على ذلك سيكون هناك دائما خطأ آخر.

هذا شيء يعرفه جميع مستخدمي الكمبيوتر. بغض النظر عن مقدار اختبار نظام التشغيل ، فهناك دائمًا خطأ يتم اكتشافه عندما يكون الوقت قد فات.

قانون كيرنيغان

Linux Adictos يحتوي على مكون إضافي مثبت للتأكد من أننا نحن المؤلفون نكتب بطريقة صديقة لمحركات البحث. لقد كرهته منذ اليوم الأول. أي محاولة للكتابة مع قليل من الطيران الأدبي يتم استنكارها على الفور بدائرة حمراء. مع مرور الوقت اعتدت على ذلك ونادرًا ما أضطر إلى إجراء تعديلات.

يحدث نفس الشيء للمبرمجين ، في كثير من الأحيان يكونون مهتمين بإظهار قدرتهم على البرمجة أكثر من كتابة كود أبسط يسهل فهمه والحفاظ عليه.

صور بثلاثة أحجام من الأقراص المرنة.

لأكثر من عقد من الزمان ، كانت الأقراص المرنة هي الوسيلة الأساسية لتوزيع البرامج.

ومن ثم ينص قانون Kernighan على ما يلي:

"التصحيح هو ضعف صعوبة كتابة الكود في المقام الأول. لذا ، إذا قمت بكتابة التعليمات البرمجية بأكبر قدر ممكن من الذكاء ، فأنت بحكم التعريف لست ذكيًا بما يكفي لتصحيحها ".

قاعدة 90/90

يعرف أي شخص بدأ مشروعًا ربحيًا في الحياة الواقعية أن كل مشروع سيستغرق ضعف الوقت ولديه ضعف التكلفة المدرجة في الميزانية ، لتحقيق نصف الربح المتوقع.

عالم الكمبيوتر له أشكاله المختلفة لهذا القانون. على سبيل المثال ، قال توم كارجيل:

يمثل أول 90 بالمائة من الكود أول 90 بالمائة من وقت التطوير. تمثل نسبة 10 بالمائة المتبقية من الكود نسبة 90 بالمائة الأخرى من وقت التطوير ".

ألم يكن واضحا؟ ربما يساعد قانون هوفستاتر:

"يستغرق الأمر دائمًا وقتًا أطول مما تتوقع ، حتى مع مراعاة قانون هوفستاتر."

أعتقد أن مطوري Ubuntu و Fedora يجب أن يعرفوا ذلك. أو تذكرها على الأقل كل 6 أشهر.

قانون بروك

عادة ما تواجه مشاريع البرمجيات مفتوحة المصدر مشكلتين ؛ التمويل ونقص المتعاونين. ما لم تكن الثانية ليست مشكلة. وفقا لبروك:

"إن إضافة العمالة إلى مشروع برمجي متأخر عن الجدول الزمني سيعيده إلى الوراء أكثر."

إنه مفهوم ، فليس فقط المبرمجون الجدد هم من يحتاجون إلى السرعة. سيكون هناك المزيد لتوثيقه ، والمزيد من البيروقراطية لإبقاء الجميع في حالة تزامن ، ومن المحتمل أن تكون هناك معارك.

وبالطبع لا يمكننا أن ننسى أمر الصديق باركنسون وتصريحه بذلك لا يهم مقدار المساحة الفارغة التي تبدأ بها. ستحتاج دائمًا إلى المزيد. كان يشير إلى مساحة المكتب ، لكن الشيء نفسه ينطبق على ذاكرة الوصول العشوائي ومساحة القرص.


اترك تعليقك

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

*

*

  1. المسؤول عن البيانات: AB Internet Networks 2008 SL
  2. الغرض من البيانات: التحكم في الرسائل الاقتحامية ، وإدارة التعليقات.
  3. الشرعية: موافقتك
  4. توصيل البيانات: لن يتم إرسال البيانات إلى أطراف ثالثة إلا بموجب التزام قانوني.
  5. تخزين البيانات: قاعدة البيانات التي تستضيفها شركة Occentus Networks (الاتحاد الأوروبي)
  6. الحقوق: يمكنك في أي وقت تقييد معلوماتك واستعادتها وحذفها.

  1.   جسوهادين بيريز قال

    نص ممتاز. مفهومة وفلسفية وأدبية. واحدة من أفضل ما قرأته من linuxer. تهانينا.

  2.   دييجو جيرمان جونزاليس قال

    شكرا جزيلا لتعليقك لك

  3.   مانويل أوتسوي قال

    كل شيء حقيقي جدًا ، منذ سنوات عديدة كنت مبرمجًا وشهدت العديد من تلك المواقف. تهانينا. أنا أتابعك من شيكاغو.

    1.    دييجو جيرمان جونزاليس قال

      شكرا جزيلا

  4.   FAMM قال

    مبادئ تنطبق على أي وظيفة تقريبًا