النظرية التي كانت موجودة بالفعل
كل عيب من عيوب MOAD كان له حل معروف قبل عقود من اكتشافه المنهجي في 2026. لم تستمر العيوب لأن أحداً لم يكن يعرف أفضل. بل استمرت لأن المعرفة ليست نفسها الاكتشاف.
MOAD-0001: list.contains بتعقيد O(N²)
دونالد كنوث، 1973. فن برمجة الحاسوب، المجلد 3: الترتيب والبحث. جداول التجزئة للبحث بتعقيد O(1) محددة بالكامل، مع التحليل، في 1973. الفرق بين البحث الخطي O(N) والبحث بالتجزئة O(1) — موثق، مُصاغ، ومُستشهد به على نطاق واسع. أصدرت Java HashSet في الإصدار 1.0 (1996). أصدرت Python النوع set كنوع أساسي في 2.4 (2004). كان الحل موجوداً منذ 30 عاماً قبل أن يصبح أسلوباً افتراضياً في كل بيئة.
ريتشارد هامينغ، 1986. محاضرات مختبرات بيل (نُشرت لاحقًا بعنوان The Art of Doing Science and Engineering، 1997). شرح هامينغ صراحةً التعقيد الخوارزمي، والفرق بين الصحيح والفعّال، وخطر بناء أنظمة تعمل على نطاق صغير لكنها تفشل على نطاق واسع. أطلق على ذلك "التصميم للمشكلة التي تراها اليوم، وليس للمشكلة التي ستواجهها غدًا."
MOAD-0002: اقتران حالة عالمية مشتركة
ديفيد بارناس، 1972. 'On the Criteria To Be Used in Decomposing Systems into Modules.' CACM، ديسمبر 1972. جادل بارناس بأن الوحدات يجب أن تُقسَّم بناءً على إخفاء المعلومات — كل وحدة تمتلك حالتها الخاصة، ولا توجد متغيرات عالمية قابلة للتعديل مشتركة. هذا هو السلف النظري المباشر لإصلاح Intertangle. كان بارناس واضحًا: الحالة العالمية المشتركة تخلق اقترانًا غير مرئي لا يكشفه الاختبار.
MOAD-0003: تسرب هوية ThreadLocal
جافا 1.2، 1998. تم شحن ThreadLocal كفئة مكتبة قياسية في جافا. منذ اللحظة التي تعايش فيها تجميع الخيوط + ThreadLocal، وُجدت آلية التسرب. العيب هيكلي: حامل عمره هو الخيط، وليس وحدة العمل. حذّرت الوثائق من هذا منذ بداية دورة حياة Java EE.
MOAD-0004: بيانات الاعتماد المسجلة
RFC 1945، 1996. عرّف HTTP/1.0 رأس Authorization. أصبح عيب تسجيل بيانات الاعتماد ممكنًا منذ وجود رأس Authorization. تأسست OWASP في 2001 ووثّقت تسجيل بيانات الاعتماد كفئة من الثغرات في أدلّتها الأولى. النمط: رأس Authorization → وسيط التسجيل → بيانات اعتماد نصية واضحة على القرص. معروف منذ أول مواصفة مصادقة HTTP.
MOAD-0005: قطيع الرعد / عاصفة ذاكرة التخزين المؤقت
نواة يونكس، 1993. مشكلة «القطيع الصاخب» — إيقاظ N عملية في وقت واحد عند وقوع حدث مشترك — ظهرت في مناقشات تطوير نواة يونكس في أوائل التسعينيات. عمل دوغ شميدت على نمط Reactor (1994) وHalf-Sync/Half-Async (1995) تناول المزامنة على مستوى البنية التحتية. أما النسخة المتعلقة بـ«الطابع الجماعي للذاكرة المؤقتة» (حساب N خيطًا للقيمة نفسها عند فقدان الذاكرة المؤقتة) فقد وُثِّقت في أدبيات الأنظمة الموزعة بحلول عام 2001. [BLOCK_TYPE knowable/theory_exists]
--- [BLOCK_TYPE knowable/theory_exists]
النظرية: مكتملة. أدوات الكشف: غائبة. الفجوة بين «المعروف» و«المكتشف» تمتد من 28 إلى 54 سنة حسب العيب.
فجوة المعرفة [BLOCK_TYPE knowable/knowable_question]
يُظهر الجدول الزمني أن كل عيب MOAD كان له حل معروف قبل 28 سنة على الأقل من الكشف المنهجي. أقصر فجوة (MOAD-0003) هي 28 سنة. وأطولها (MOAD-0002) هي 54 سنة. [BLOCK_TYPE knowable/knowable_question]
هذه ليست قصة عن الجهل. كنوث، وبارناس، وهامينغ — هؤلاء من أكثر المؤلفين استشهادًا في علوم الحاسب. نُشرت أعمالهم في الجامعات. وأصبحت مفرداتهم (Big O، إخفاء المعلومات، التعقيد الخوارزمي) جزءًا من المناهج الدراسية القياسية.
لماذا يتفاقم الكود: خمسة شروط
لا يستمر العيب بالصدفة. خمسة شروط هيكلية، كلها موجودة في وقت واحد، تخلق بيئة تفاقم. إزالة أي واحد منها يجعل الكشف ممكنًا.
الشرط 1: الإخراج الصحيح
تجيب القائمة والمجموعة على سؤال العضوية بشكل متطابق. list.contains(x) و set.contains(x) تعيدان نفس القيمة المنطقية. يحمل ThreadLocal هوية قديمة لا تزال تحمل هوية — لكنها تنتمي إلى الطلب الخطأ. يتم تسجيل بيانات الاعتماد بشكل صحيح — تصل بيانات الاعتماد إلى ملف السجل دون خطأ. العيب ليس عطلاً. إنه عطل فقط في التكلفة أو النتيجة الأمنية. الاختبارات التي تتحقق من المخرجات تنجح. الاختبارات التي تتحقق من التكلفة أو النتيجة الأمنية: غير مكتوبة في الغالب.
الشرط 2: عدم وجود اختبارات التعقيد في CI
قال ديكسترا: "يُظهر الاختبار وجود العيوب، لا غيابها." وأضاف هامينغ: العيوب التي نختبرها هي العيوب التي نجدها. خطوط أنابيب CI في 2026 تختبر: الصحة، سلامة الأنواع، عقود واجهات API، والسلوك الوظيفي. ولا تختبر: التعقيد الخوارزمي لكل عملية، نمو الذاكرة لكل استدعاء، تنظيف رأس التفويض، دورة حياة هوية الخيط.
لا يُشغَّل أي اختبار. لا يفشل أي اختبار. خط الأنابيب أخضر. العيب غير مرئي.
الشرط 3: أصل Small-N
تُكتب الشيفرة وتُراجع في بيئات التطوير. تحتوي رسومات التطوير على 50 عقدة. تحتوي أحمال طلبات التطوير على 10 خيوط متزامنة. معدلات فقدان ذاكرة التخزين المؤقت في التطوير منخفضة (ذاكرة تخزين مؤقت دافئة، مفاتيح قليلة). عند N=50 تكون تكلفة O(N²) 2,500 عملية. غير مرئية. عند N=50,000 تكون التكلفة 2,500,000,000 عملية. بناء يستغرق 17 دقيقة بدلاً من ثانية واحدة.
لم يرَ مؤلف الشيفرة N=50,000 قط. ولم يرَ المراجع الذي وافق عليها N=50,000 قط. لم يكن العيب مرئياً عند مقياس كتابته.
الشرط 4: النسخ ينتشر بدون سياق
A correct algorithm is instructive. Tutorials teach with correct examples. Documentation shows working code. The same Tarjan SCC skeleton — visited = [], inner if n not in visited — appears in GHC, Maven, Python pip, Cargo, TypeScript compiler, Kotlin compiler, Scala compiler, and javac. Different teams, different languages, different decades. Same fossil. The original author's N=50 does not propagate with the code. What propagates: the correct output. What stays behind: the performance assumption.
[BLOCK_TYPE SECTION/STEP]
Condition 5: Scale Grows Around Frozen Code
[BLOCK_TYPE SECTION/STEP]Code does not degrade. Infrastructure scales. A dependency resolver written in 2003 for 200 packages runs on 50,000 packages in 2024. Nobody rewrites it — it works. Nobody profiles it — the CI is green. The N that makes the O(N²) cost catastrophic arrives gradually, invisibly, at production scale. By then the original author is gone. The code is a dependency. Nobody touches working dependencies.
التشخيص: الشروط الخمسة
الشروط الخمسة: مخرجات صحيحة، عدم وجود اختبارات تعقيد، أصل بـ N صغير، نسخ بدون سياق، ونمو الحجم حول كود مجمّد.
كانت الشروط الخمسة جميعها حاضرة في كل MOAD في وقت واحد. هذا ليس مصادفة — بل هو التوقيع البنيوي لفئة عيوب رسوبية.
ما قاله هامينغ
تحتوي محاضرات ريتشارد هامينغ عام 1986 في مختبرات بيل — والتي نُشرت عام 1997 بعنوان فن إنجاز العلوم والهندسة — على تحذيرات تبدو كوصف مباشر لنمط عيب MOAD. لم يكن يصف MOAD. بل كان يصف الميل الهيكلي للأنظمة الهندسية إلى التصلب حول قرارات صحيحة محليًا تصبح مكلفة عالميًا.
هامينغ عن التعقيد: "الغرض من الحوسبة هو الفهم، لا الأرقام. لكن يجب أن يكون لديك التعقيد الصحيح للخوارزمية وإلا فلن تظهر الأرقام أبدًا. خوارزمية O(N²) تعمل على N=100 لن تعمل على N=1,000,000 قبل تقاعدك."
هامينغ عن النسخ: "لا يكتفي المهندسون العظماء بنسخ الحلول. بل يفهمون لماذا يعمل الحل، وتحت أي ظروف ينطبق، وما الذي قد يعطله. الحل المنسوخ بدون شروطه قنبلة موقوتة."
هامينغ عن الاختبار: "اختبار ما قمت بقياسه ليس مثل قياس ما يهم. نبني مجموعات اختبار معقدة للخصائص التي اخترنا اختبارها. ونترك غير مختبرة الخصائص التي لم نخترها. ما نتركه غير مختبر هو ما يفاجئنا في الإنتاج."
هامينغ على المقياس: 'الخطأ الذي ترتكبه في السنة الأولى من المشروع هو الخطأ الذي لا تزال تصححه في السنة العاشرة. الافتراضات المبكرة تتصلب. يتوسع المشروع حولها. لا أحد يعيد كتابة الأساس.'
الفجوة بين التحذير والتفعيل
كانت تحذيرات هامينغ صحيحة. تم تدريسها. تم الاستشهاد بها. تم تكليفها في المناهج. لكن التحذير ليس كاشفًا. وصف هامينغ شكل العيب. ولم يبنِ أداة تعمل في CI وتُعلّم مسارات O(N²) الساخنة، أو تسربات هوية ThreadLocal، أو تسجيل بيانات الاعتماد. الفجوة بين "المعروف" و"القابل للكشف" هي الفجوة بين النظرية وتفعيلها كبنية تحتية آلية.
MOAD موجود لأن المجال بنى بنية تحتية للصحة وليس بنية تحتية للأداء أو الأمان بنفس المستوى. اختبارات الوحدة: قياسية منذ السبعينيات. الاختبارات القائمة على الخصائص: قياسية منذ التسعينيات. معايير تعقيد الخوارزميات في CI: لا تزال تجريبية في 2026.
تفعيل التحذير
حذّر هامينغ من تصلب التعقيد، والخصائص غير المختبرة، والحلول المنسوخة دون شروطها، وسحق الحجم للافتراضات المبكرة. أعطانا المفردات. ولم يعطنا الكاشف.
خط أنابيب MOAD يملأ هذه الفجوة: scan → ticket → patch → unit test → disclose → PR → upstream merge. هذا هو هامينغ المفعّل: ليس التحذير فقط، بل الكشف الآلي وخط أنابيب الإصلاح.
التوقيع الفاسد [BLOCK_TYPE SECTION/STEP]
يمتلك عيب فئة MOAD توقيعًا مميزًا. جميع الشروط الخمسة موجودة في وقت واحد. ويمكن التحقق من الخمسة جميعًا قبل كتابة أي فحص: [BLOCK_TYPE SECTION/STEP]
1. هل الخرج صحيح؟ شغّل مجموعة الاختبارات القياسية. إذا نجحت، فالعيب يتعلق بخاصية أداء أو أمان، وليس خاصية صحة. وهذا يعني أن CI القياسي لن يكتشفه.
2. لا يوجد اختبار تعقيد؟ تحقق من إعدادات CI. هل توجد مرحلة قياس أداء؟ هل تقارن سلوك الخوارزمية (وليس فقط زمن التنفيذ) بإصدار سابق؟ إذا لم يكن الأمر كذلك: الشرط موجود.
3. أصل Small-N؟ تحقق من git blame والالتزام الأصلي. ما حجم مجموعة البيانات في التنفيذ الأول؟ هل هذا الحجم أصغر من حمل الإنتاج الحالي بأكثر من 100×؟ إذا كان الأمر كذلك: الشرط موجود.
4. هل ينتشر النسخ؟ ابحث عن النمط في قاعدة الشيفرة وعبر الأنظمة البيئية. هل يظهر نفس النمط الهيكلي في N≥3 قواعد شيفرة مستقلة بدون أصل مشترك؟ إذا كان الأمر كذلك: انتشر الأثر. كل نسخة: موقع تفشٍ جديد.
5. هل ينمو الحجم؟ تحقق من مقاييس الإنتاج. ما قيمة N اليوم مقارنة بـ N عند أول نشر؟ هل معدل النمو مستمر؟ عند أي قيمة N يصبح العيب حرجًا تشغيليًا؟
إذا تم التحقق من الخمس نقاط جميعها وتأكيدها: لديك عيب من فئة MOAD. الإصلاح دائمًا استبدال سطر واحد أو طريقة واحدة. الاكتشاف هو الجزء الصعب. الإصلاح هو الجزء السهل.
هذا ما قصده Hamming: الهندسة ليست عن الإصلاح. الإصلاح مباشر بمجرد رؤيته. الهندسة تتعلق ببناء الأنظمة التي تتيح لك رؤيته.
تطبيق التوقيع
توقيع MOAD fester: مخرجات صحيحة + لا يوجد اختبار تعقيد + أصل Small-N + ينتشر النسخ + ينمو الحجم.
هذه البصمة لا تقتصر على عيوب MOAD الخمسة. فهي تصف فئة من العيوب التي تستمر في أي نظام تكون فيه اختبارات الصحة هي بوابة الجودة الآلية الوحيدة.