مبدأ بيتر للبرمجيات

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

من المعروف جيدًا في الصناعة أنه قاتل صامت للمشاريع ، ولكن بحلول الوقت الذي تظهر فيه الأعراض ، غالبًا ما يكون قد فات الأوان لفعل أي شيء حيال ذلك ^{[ بحاجة لمصدر ]} . يمكن للمديرين الجيدين تجنب هذه الكارثة من خلال إنشاء ممارسات تشفير واضحة حيث يتم تجنب التعليمات البرمجية والتصميمات المعقدة بشكل غير ضروري.

تم استخدام الاسم في كتاب FAQs C ++ ، وهو مشتق من مبدأ بيتر  - نظرية حول عدم الكفاءة في المنظمات الهرمية.

الأسباب

فقدان التكامل المفاهيمي

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

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

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

عدم كفاءة المبرمج

يفهم مطورو البرمجيات الجيدون أهمية التواصل مع الأشخاص عبر التواصل مع الحاسوب، وفقًا لـ اكتمال الرمز بواسطة ستيف ماكونيل . في المتوسط ، يقضي 85 بالمائة من وقت المبرمج في التواصل مع الناس ، بينما يقضي 15 بالمائة فقط في التواصل مع الحاسوب. يقضي مبرمجو الصيانة من 50 إلى 60 في المائة من وقتهم في محاولة لفهم الكود الذي يتعين عليهم صيانته وسيحصل البرنامج ، في المتوسط ، على 10 أجيال من مبرمجي الصيانة في حياته.

قلة خبرة المبرمج

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

المراجع

• بروكس ، ف. ، الرجل الأسطوري ، شهر أديسون ويسلي لونجمان إنك ، 1995.
• McConnell، S.، Code Complete ، Microsoft Press، 1993
• فاولر ، إعادة بيع ديون ، أديسون ويسلي ، 2000