نمط مضاد

النمط المضاد في هندسة البرمجيات وإدارة المشاريع وعمليات الأعمال هو استجابة شائعة لمشكلة متكررة غير فعالة عادةً وتخاطر بأن تكون غير منتجة للغاية. ^{[1] [2]} تم صياغة المصطلح في عام 1995 بواسطة مبرمج الكمبيوتر أندرو كونيغ ، مستوحى من كتاب أنماط التصميم (الذي يسلط الضوء على عدد من أنماط التصميم في تطوير البرمجيات التي اعتبرها مؤلفوها موثوقة وفعالة للغاية) ونشر لأول مرة في مقالته في مجلة البرمجة الشيئية الموجهة . ^[3] كما وثقت ورقة أخرى في عام 1996 قدمها مايكل أكرويد في مؤتمر Object World West أنماطًا مضادة. ^[3]

ومع ذلك، كان كتاب AntiPatterns الصادر عام 1998 هو الذي عمل على نشر الفكرة وتوسيع نطاقها خارج مجال تصميم البرمجيات لتشمل بنية البرمجيات وإدارة المشاريع. ^[3] وقد قام مؤلفون آخرون بتوسيعها منذ ذلك الحين لتشمل الأنماط البيئية والتنظيمية والثقافية المضادة. ^[4]

وفقًا لمؤلفي أنماط التصميم ، هناك عنصران أساسيان للنمط المضاد الذي يميزه عن العادة السيئة، أو الممارسة السيئة، أو الفكرة السيئة:

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

الدليل على ما يتم استخدامه بشكل شائع هو "قاعدة الثلاثة" المشابهة لتلك الخاصة بالأنماط: لكي يكون نمطًا مضادًا، يجب أن يكون قد تم مشاهدته يحدث ثلاث مرات على الأقل. ^[5]

يمكن أن يكون توثيق الأنماط المضادة طريقة فعالة لتحليل مساحة المشكلة والحصول على المعرفة المتخصصة. ^[6]

في حين أن بعض أوصاف الأنماط المضادة توثق فقط العواقب السلبية للنمط، فإن التوثيق الجيد للأنماط المضادة يوفر أيضًا بديلاً أو وسيلة لتحسين النمط المضاد. ^[7]

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

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

انتشر المصطلح في ورقة بحثية عام 1997 تحمل نفس الاسم كتبها بريان فوت وجوزيف يودر، والتي حددت المصطلح على النحو التالي:

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

ربما لم يتم تحديد الهيكل العام للنظام بشكل جيد أبدًا.

إن كان الأمر كذلك، فقد يكون قد تآكل إلى حد لا يمكن التعرف عليه. إن المبرمجين الذين يتمتعون بقدر ضئيل من الحس المعماري يتجنبون هذه المستنقعات. ولا يرضى بالعمل على مثل هذه الأنظمة إلا أولئك الذين لا يهتمون بالهندسة المعمارية، وربما يشعرون بالراحة مع الجمود الذي يفرضه العمل اليومي المتمثل في سد الثغرات في هذه السدود الفاشلة.

—  بريان فوت وجوزيف يودر، كرة الطين الكبيرة. المؤتمر الرابع حول أنماط لغات البرامج (PLoP '97/EuroPLoP '97) مونتيسيلو، إلينوي، سبتمبر 1997

وقد نسب فوت ويودر إلى بريان ماريك الفضل في ابتكار مصطلح "كرة الطين الكبيرة" لهذا النوع من الهندسة المعمارية. ^[8]

تتضمن أنماط إدارة المشاريع المضادة المضمنة في كتاب الأنماط المضادة ما يلي :

• Blowhard Jamboree (فائض من خبراء الصناعة)
• شلل التحليل
• هندسة Viewgraph (قضاء وقت طويل جدًا في إعداد العروض التقديمية وعدم وجود وقت كافٍ على البرنامج الفعلي)
• الموت بسبب التخطيط (على نحو مماثل، الكثير من التخطيط)
• الخوف من النجاح (مخاوف غير عقلانية عند اقتراب موعد الانتهاء من المشروع)
• كوز الذرة (صعوبات مع الناس)
• العنف الفكري (الترهيب من خلال استخدام المصطلحات أو التكنولوجيا الغامضة)
• الإدارة غير العقلانية (العادات الإدارية السيئة)
• الدخان والمرايا (الاستخدام المفرط للعروض التوضيحية والنماذج الأولية من قبل مندوبي المبيعات)
• رميها فوق الحائط (فرض ممارسات هندسة البرمجيات العصرية على المطورين دون موافقة)
• تدريبات مكافحة الحرائق (فترات طويلة من الرتابة تتخللها أزمات قصيرة)
• العداوة (الصراعات بين المديرين)
• البريد الإلكتروني خطير (المواقف الناتجة عن رسائل البريد الإلكتروني غير المدروسة). ^[4]

• رائحة الكود  – سمة برمجة الكمبيوتر
• رائحة التصميم  – مصطلح في برمجة الكمبيوتر
• النمط المظلم  – تصميمات خادعة لواجهة المستخدم
• قائمة فلسفات تطوير البرمجيات
• قائمة الأدوات لتحليل الكود الثابت
• تعفن البرمجيات  – عملية تدهور البرمجيات
• مبدأ بيتر في البرمجيات  – مصطلح هندسي لمشروع معقد فاشل
• نموذج عدم نضج القدرة
• ISO/IEC 29110 : ملفات تعريف دورة حياة البرمجيات والمبادئ التوجيهية للكيانات الصغيرة جدًا (VSEs)
• معضلة المبتكر  – كتاب 1997 من تأليف كلايتون م. كريستنسن

• كونيغ، أندرو (مارس-أبريل 1995). "الأنماط والأنماط المضادة". مجلة البرمجة الشيئية . 8 (1): 46-48.
  • أعيد طبعه لاحقًا في: Rising, Linda (1998). The Patterns handbook: techniques, strategies, and applications. Cambridge, UK: Cambridge University Press. p. 387. ISBN 0-521-64818-1النمط المضاد يشبه تمامًا النمط، إلا أنه بدلاً من الحل فإنه يعطي شيئًا يبدو ظاهريًا مثل الحل، ولكنه ليس كذلك .
• لابلانت، فيليب أ.؛ نيل، كولين ج. (2005). الأنماط المضادة: التعريف وإعادة الهيكلة والإدارة . منشورات أورباخ. رقم ISBN 0-8493-2994-9.
• براون، ويليام جيه؛ مالفو، رافائيل سي؛ ماكورميك، هايز دبليو؛ توماس، سكوت دبليو. (2000). هدسون، تيريزا هدسون (محرر). الأنماط المضادة في إدارة المشاريع . جون وايلي وأولاده . رقم ISBN 0-471-36366-9.
• ستاميلوس، يوانيس (يناير 2010). "أنماط معاكسة لإدارة مشروعات البرمجيات". مجلة الأنظمة والبرمجيات . 83 (1): 52-59. doi :10.1016/j.jss.2009.09.016.

• النمط المضاد في ويكي ويكي ويب