برنامج جودة ousterhout

SKILL.md

---
name: برنامج جودة ousterhout
description: استخدمه كلما تم كتابة أو مراجعة كود ينشئ أو يغير حدًا — وحدة جديدة، فئة، مكون، مساعد، هوك، خدمة، أو غلاف؛ أي استخراج أو تمركز للكود المشترك؛ أي لحظة "لنجعل هذا قابلاً لإعادة الاستخدام" — وعند مراجعة أو إعادة هيكلة أو تصميم وحدة بشكل صريح. يحكم ما إذا كان التجريد يستحق العناء: عمق الوحدة، ما إذا كان يجب إخفاء قرار تصميم، ما إذا كان الكود المكرر يحمي قاعدة مشتركة أو مجرد تشابه، ما إذا كانت الواجهة مستقرة. يحمي من SOLID/Clean Code الميكانيكي الذي ينتج العديد من الفئات السطحية. كما يحدد اختبار تكلفة القارئ (الكود الذي يكون رخيصًا للبشر والوكلاء لقراءته وتغييره) والإجراء لإعادة هيكلة قاعدة كود موجودة وفقًا لهذا المعيار.
---

# برنامج جودة أوسترهاوت

## نظرة عامة

وظيفة الوحدة هي إخفاء التعقيد خلف واجهة صغيرة. المقياس الأساسي هو **العمق**: الوحدة العميقة تقدم واجهة بسيطة على وظيفة كبيرة؛ واجهة الوحدة الضحلة معقدة تقريبًا مثل تنفيذها، لذا فهي لا تقدم فائدة. التعقيد هو ما تشعر به عندما يجبرك التغيير على فهم أو لمس كود لم تكن تتوقعه — أوسترهاوت يذكر مصدرين: **التبعيات** (لا يمكنك تغيير A دون تغيير B) و**الغموض** (المعلومات المهمة ليست واضحة).

أوسترهاوت وحده يخبرك كيف *تشعر* الوحدة الجيدة. هو الأقوى عند دمجه مع عدسات أخرى تخبرك أين يجب أن تكون الحدود وكيف تتحرك نحوها بأمان. هذه المهارة هي تلك العدسة المدمجة.

## أين تفشل المراجعات فعليًا

الفشلان اللذان توجد هذه المهارة لتصحيحهما — واللذان لوحظا مرارًا في الكود المكتوب بواسطة الوكلاء — هما في **العلاج**، وليس في حكم التقسيم/عدم التقسيم نفسه:

1. **الإصلاح السطحي.** عند وجود ستة تحويلات `as unknown as`، يقوم المراجع غير المساعد بتجميعها في مساعد عام واحد `castRows<T>()` — أنظف، لكن الغموض يبقى. الإصلاح العميق هو استخدام محولات صف→نطاق مكتوبة بأنواع مع اختبارات مثبتة أولاً (تطبيقًا لـ Parnas: التحويل هو رائحة لحد مفقود؛ Beck: أثبت التحويل قبل نقله). ترتيب رائحة ليس إزالتها.
2. **الاستخراج الانعكاسي.** عند تكرار نفس منطق التحديث في ثلاثة مكونات شقيقة، قال كل مراجع غير مساعد "استخرج مساعدًا مشتركًا" — رد فعل DRY. قاعدة هذا البرنامج، الممتدة من Metz: انتظر الثابت، لا تنتظر التكرار الثالث — اجمع عندما يحمي الكود قاعدة مشتركة، لا عندما يتشابه.

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

## بوابة التناسب

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

## القاعدة كاملة

كل قطعة من الكود المولدة أو المراجعة تمر عبر عدسة أوسترهاوت قبل اعتبار المهمة منتهية — ليس فقط مراجعات التصميم الصريحة — باستثناء التغييرات تحت بوابة التناسب (لا حد جديد، لا تجميع: إعادة تسمية، تعديلات الكود، تعديلات التكوين). اختباران: (1) **العمق** — يجب أن تخفي الواجهة الجديدة أكثر بكثير مما تكشف؛ الواجهة المعقدة مثل ما تغلف لا تقدم فائدة. (2) **الثابت** — استخرج الكود المشترك فقط عندما يحمي قاعدة مشتركة، لا لأن ثلاثة مواقع تتشابه؛ ويجب أن يزيل الإصلاح الغموض، لا ينقله (تجميع ستة تحويلات في مساعد واحد لا يزال ستة تحويلات). عندما ينشئ التغيير حدًا أو يعيد تشكيله، ابحث أولاً كيف يحل منتج معروف مشكلة بهذا الشكل والحجم وتبنَّى قواعده ما لم يكن هناك سبب معلن لعدم ذلك (النمط المستعاد من التدريب هو ادعاء، ليس مصدرًا)، ثم نفذ الفحوصات أدناه.

## متى تستخدم

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

**ليس لـ:** التعديلات الميكانيكية التافهة، أو عندما يحدد اتفاق مشروع الهيكل — انظر بوابة التناسب أعلاه. ارجع إلى `karpathy-guidelines` لانضباط التغيير الجراحي ومهارة التطوير المدفوع بالاختبار لشبكة أمان إعادة الهيكلة، عندما تكون متاحة.

## العدسات

كل عدسة تضيف سؤالًا واحدًا بالضبط. أوسترهاوت هو العمود الفقري؛ والبقية تصحح نقاط عماه.

| العدسة | السؤال الواحد الذي تضيفه | متى تتجاوز |
|---|---|---|
| **أوسترهوت** — الوحدات العميقة | هل تخفي هذه الواجهة أكثر مما تكشف؟ | العمود الفقري الافتراضي. |
| **بارناس** — إخفاء المعلومات | ما القرار التصميمي (الذي من المحتمل أن يتغير) الذي تخفيه هذه الوحدة؟ | *السبب* الذي يجعل الوحدة عميقة. إذا لم تخفِ شيئًا يتغير، فالعمق تجميلي. |
| **بروكس** — الأساسي مقابل العرضي | هل يزيل هذا التعقيد العرضي، أم ينقل فقط تعقيد المجال الأساسي؟ | يقتل "إعادة الهيكلة" التي تنقل الفوضى دون تقليصها. |
| **إيفانز** — التصميم المدفوع بالمجال | هل تم تسمية هذا الحد في لغة المجال، وليس بلغة الأدوات العامة؟ | أعد تسمية `utils`/`helpers` — سمِّ الحد بناءً على الثابت الذي يمتلكه هذا المستودع فعليًا. |
| **فاولر** — إعادة الهيكلة / الروائح | ما هو أصغر خطوة آمنة نحو التصميم الأعمق؟ | يحول "يجب أن يكون أعمق" إلى خطوات ملموسة خلف اختبارات ناجحة. |
| **بيك** — التصميم البسيط، الاختبار أولاً | هل أثبتت السلوك الحالي قبل تعميق الفاصل؟ | فرامل على الهندسة المعمارية المبكرة. اجعله يعمل ومختبرًا أولاً، ثم عمق الفاصل الصحيح. |
| **هيكي** — البسيط مقابل السهل | هل يخلط هذا بين مفاهيم غير مرتبطة، أم هو مفهوم واحد حقًا؟ | المساعد السطحي عادة ما يكون *سهلًا* (قريب، سريع)، وليس *بسيطًا* (قليل المفاهيم المتداخلة). الأفضل البسيط. |
| **ميتز** — التكرار أفضل من التجريد الخاطئ | هل يحمي هذا الكود المكرر ثابتًا مشتركًا، أم يبدو متشابهًا فقط (قاعدة هذا البرنامج، توسيعًا لميتز)؟ | ميتز: التكرار أرخص من التجريد الخاطئ — أعد إدخال التجريد الخاطئ بدلاً من تحريفه. يوسع هذا البرنامج قاعدتها: لا تُركز فقط لأنه يتكرر؛ ركز فقط عندما يحمي ثابتًا حقيقيًا. تحمل التكرار حتى يظهر الثابت. |
| **قانون هيروم** — السلوك المرصود | هل سيعتمد المستدعون على سلوك يتجاوز عقد هذه الواجهة؟ | يجادل لصالح واجهات صغيرة ومستقرة: كل سلوك مرصود يصبح في النهاية حاملاً للحمل. |

## وصفة الدمج

طبق بالترتيب التالي — العدسات اللاحقة تهم فقط بعد اجتياز العدسات السابقة:

1. **ميتز — بوابة القبول.** هل يستحق هذا الحد/التجريد الوجود أصلاً؟ قاعدة هذا البرنامج، توسيعًا لميتز: استخرج فقط عندما يحمي الكود قاعدة مشتركة — ثلاثة متشابهين ليسوا ثابتًا مكشوفًا. إذا لا، توقف هنا.
2. **بارناس / أوسترهوت** — أخفِ القرار المتقلب (نطاق التفويض، قاعدة التقريب، حارس الانتقال، قاعدة الاحتفاظ) خلف وحدة عميقة.
3. **إيفانز** — سمِّ تلك الوحدة بلغة المجال، وليس `utils`.
4. **بيك / فاولر** — للكود الموجود، ثبت السلوك الحالي بالاختبارات، ثم أعد الهيكلة نحوه بخطوات صغيرة وآمنة. للكود المولد حديثًا لا يوجد سلوك حالي لتثبيته — اكتب الاختبار الذي يحدد السلوك المقصود بدلاً من ذلك.
5. **هيكي** — ارفض الواجهات التي تخلط بين مفاهيم غير مرتبطة لمجرد أن سير العمل يبدو مشابهًا.

## النمط الهيكلي المضاد

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

## الأخطاء الشائعة

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

## تكلفة القارئ: الاختبار الثالث

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

- **هل هو قابل للعثور؟** اسم واحد لكل مفهوم، مكتوب بنفس الطريقة في كل مكان، يمكن الوصول إليه بالبحث النصي العادي. العيوب: أسماء مركبة من سلاسل نصية، التوصيل عبر تأثير الاستيراد الجانبي، سلاسل إعادة التصدير التي تخفي التعريف، اسمين لمفهوم واحد.
- **هل يمكن للقارئ التوقف مبكرًا؟** العقدة موجودة في أعلى الملف أو فوق التصدير: ما تعد به، ما تخفيه، ما لا تفعله أبدًا. العيب: العقدة لا يمكن استنتاجها إلا بقراءة المحتوى.
- **هل يمكن التحقق منها آليًا؟** أنواع دقيقة داخل وخارج كل حد، بحيث يحل التحقق من النوع محل قراءة المستدعين. العيوب: `any`، القواميس العارية، العلامات المنطقية التي معنىها موجود في المحتوى.
- **هل الترابط مرئي؟** الأماكن التي يجب أن تتغير معًا يتم فرضها (نوع مشترك، اختبار، مصدر واحد) أو، في حال الفشل، يتم تمييزها في كلا الموقعين. دليل الترابط الخفي هو التغيير المشترك في التاريخ الذي لا يذكره شيء في الكود.
- **هل هو خالٍ من الضوضاء؟** لا تعليقات تعيد صياغة الكود، لا كود معلق بالتعليق، لا فروع ميتة، لا تعليقات تاريخ التغيير، لا مسار قديم محفوظ بجانب بديله.
- **هل هو متوقع؟** التخطيط يتبع نمط المستودع الحالي؛ الاختبار هو المكان الذي سيبحث فيه القارئ ويعمل بشكل مستقل.

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

للمؤشرات داخل الكود وخريطة المستودع، استخدم `context-audit` حيثما كان متاحًا: مرساة `AIDEV-NOTE:` الخاصة به (حقيقة واحدة غير قابلة للاسترداد بالإضافة إلى مرجع الأصل، بحد أقصى سطرين، في الموقع) هي الاتفاقية للترابط الذي لا يمكن فرضه.

## إعادة هيكلة قاعدة كود موجودة لهذا المعيار

يتم تقييم التعديل بنفس طريقة الكود الجديد؛ ما يختلف هو الترتيب والضبط. يجب ترك معظم قاعدة الكود كما هي.

1. **الجرد، للقراءة فقط.** سرد الحدود (الوحدات، الخدمات، المساعدين المشتركين). لكل سجل: القرار الذي يخفيه، أو "لا شيء"؛ حجم الواجهة مقابل المحتوى؛ شركاء التغيير المشترك من التاريخ؛ عيوب تكلفة القارئ. لا تغير شيئًا بعد.
2. **الترتيب حسب التغير، وليس القبح.** الأولوية هي عدد مرات تغير الكود مضروبًا في تكلفة قراءته. الكود البارد الذي يعمل يبقى كما هو، مهما كان سطحيًا. تعقيد المجال الأساسي يبقى حيث هو (بروكس).
3. **تعيين علاج واحد لكل اكتشاف:**
   - طبقة تمرير أو غلاف لا تخفي شيئًا: احذفها، يستخدم المستدعون ما كانت تغلفه؛
   - تجريد خاطئ منحرف بعلامات وحالات خاصة: أعده إلى الداخل (ميتز)، ثم ابحث عن الثابت الحقيقي؛
   - أشقاء سطحيون يشتركون في قرار واحد: دمجهم خلف واجهة واحدة؛
   - قرار مسرب (المستدعون يعرفون التنسيق، القاعدة، المخطط): اسحبه إلى الوحدة التي تملكه؛
   - اسم عام (`utils`، `helpers`، `manager`): أعد تسميته للقرار الذي يخفيه، أو قم بحله في مستدعيه؛
   - حد غير مكتوب النوع: اكتبه، واستبدل التحويلات بالموصل الذي كانت تغطيه؛
   - ترابط مخفي: فرضه، أو وسم كلا الموقعين؛
   - ضوضاء: احذفها.

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

المهارات ذات الصلة، حيثما كانت متاحة: `repo-review` (نوع التصميم) ينتج الجرد كأثر نصيحة فقط؛ `design-cleanup` يدير حلقة الإصلاح وإعادة الفحص للتعقيد العرضي؛ `context-audit` يضيف المراسي وخريطة الكود؛ `ousterhout-build-deep` هو قائمة التحقق في وقت المؤلف للوكلاء الذين ينفذون الوحدات.

## أين يقع هذا

هذه المهارة هي طبقة المراجعة والحكم: استخدمها لتقرير ما إذا كان التجريد عميقًا، مسمى للقرار الصحيح، ويستحق الاستخراج. يستخدمها `find-shared-code` كاختبار قبول عند مسح التاريخ الحديث للكود الجدير بالمشاركة. الملحق أدناه يعطي منطق كل مؤلف.

---

## الملحق: العدسات بعمق

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

### أوسترهاوت — الوحدات العميقة (العمود الفقري)

*فلسفة تصميم البرمجيات.*

- **العمق** = الفائدة (الوظائف المخفية) ÷ التكلفة (تعقيد الواجهة). الوحدة العميقة تخفي الكثير خلف القليل. واجهة الوحدة السطحية معقدة تقريبًا مثل محتواها، لذا لا تكسب شيئًا.
- **التعقيد** هو أي شيء في النظام يجعل فهمه أو تعديله صعبًا. مصدران:
  - **الاعتمادات** — لا يمكنك تغيير جزء واحد دون لمس آخر.
  - **الغموض** — المعلومات المهمة ليست واضحة من الكود.
- **الأعراض:** تضخيم التغيير (قرار واحد، العديد من التعديلات)، الحمل المعرفي (كم يجب أن تحتفظ به في ذهنك)، المجهولات المجهولة (لا يمكنك معرفة أي كود سيتأثر بالتغيير).
- **الحركة الرئيسية:** اسحب التعقيد *للأسفل* — الوحدة تمتص الحالة الصعبة حتى لا يضطر المستدعون لذلك. معلمات التكوين والتمريرات تدفع التعقيد *للأعلى* إلى المستدعي؛ هذا هو السطحية.

يلتقط: الواجهات التي تسرب تنفيذها؛ المساعدين الذين لا يساعدون.

### بارناس — إخفاء المعلومات (لماذا العمق مهم)

*حول المعايير المستخدمة في تفكيك الأنظمة إلى وحدات (1972).*

- فكك حول **قرارات التصميم التي من المحتمل أن تتغير**، وليس حول خطوات
  الحساب. يخفي كل وحدة قرارًا من هذا النوع.
- هذا هو السلف المباشر للوحدة العميقة. الوحدة عميقة *لأنها*
  تخفي قرارًا كان سينتشر عبر المستدعين.

المشاكل: "وحدة" لا تخفي شيئًا متقلبًا — عمقها تجميلي. اسأل:
ما الذي يتغير خلف هذه الواجهة التي لا يراها المستدعون أبدًا؟ إذا كانت الإجابة
"لا شيء"، فالحد هو مجرد زخرفة.

### بروكس — التعقيد الجوهري مقابل التعقيد العرضي

*لا توجد رصاصة فضية.*

- التعقيد **الجوهري** متأصل في المجال (التقييم حقًا معقد بهذا الشكل).
  التعقيد **العرضي** هو ما تفرضه أدواتنا وبنيتنا.
- فقط التعقيد العرضي قابل للإزالة. إعادة هيكلة "تنظف" بنقل
  التعقيد الجوهري من ملف إلى آخر لم تفعل شيئًا.

المشاكل: إعادة ترتيب متنكرة في شكل تبسيط. اسأل: هل انخفض التعقيد الكلي،
أم أنه فقط انتقل؟

### إيفانز — التصميم المدفوع بالمجال

*التصميم المدفوع بالمجال.*

- يجب أن تُسمى الحدود بلغة المجال **الشائعة**، وليس بمصطلحات عامة.
  وحدة تسمى `helpers` لا تسمي شيئًا؛ وحدة تسمى `AccessScope` أو `PricingPolicy`
  تسمي قاعدة ثابتة.
- تحافظ السياقات المحدودة على ثوابت العمل من التسرب عبر الفواصل.

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

### فولر — إعادة الهيكلة وروائح الكود

*إعادة الهيكلة.*

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

المشاكل: الفجوة بين "يجب أن يكون هذا أعمق" ومعرفة الالتزام التالي.
أوسترهاوت يحدد الهدف؛ فولر هو الطريق.

### بيك — التصميم البسيط، الاختبار أولاً

*التطوير المدفوع بالاختبار؛ XP.*

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

المشاكل: هندسة معمارية بُنيت قبل تثبيت السلوك. بدون اختبار يثبت السلوك الحالي،
إعادة الهيكلة "للتعميق" هي إعادة كتابة غير مؤكدة.

### هيكي — البسيط مقابل السهل

*البسيط يصبح سهلاً.*

- **البسيط** = غير متشابك: مفهوم واحد، غير متداخل مع الآخرين (موضوعي).
- **السهل** = قريب، مألوف، سريع الوصول (نسبيًا لك).
- الاثنان مستقلان. المساعد السطحي عادة *سهل* — سريع الكتابة، قريب —
  لكنه ليس *بسيطًا* إذا كان يخلط بين اهتمامات غير مرتبطة.

المشاكل: الراحة متنكرة في شكل تصميم. فضل التركيبات التي تحافظ على المفاهيم
غير المتشابكة حتى لو كان المتشابك أسرع في الكتابة.

### متز — فضل التكرار على التجريد الخاطئ

*"التجريد الخاطئ" (2016).* 

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

المشاكل: التركيز المفرط — المساعد المشترك السطحي الذي يجب على الجميع الآن
التعامل معه. هذا هو التوازن ضد "DRY بأي ثمن" الميكانيكي.

### قانون هيروم — السلوك المرصود يصبح عقدًا

*"مع عدد كافٍ من المستخدمين، كل سلوك مرصود في نظامك
سيعتمد عليه شخص ما."*

- مهما فعلت الواجهة *صدفة* — الترتيب، التوقيت، نص الخطأ — سيعتمد عليه شخص في النهاية.
  لذا السطح الذي تعرضه أكبر من السطح الذي وثقته.
- هذا يدعم تفضيل أوسترهاوت للواجهات **الصغيرة والمستقرة**: كلما عرضت أقل،
  قل ما يمكن أن يصبح حاملاً للحمل عن طريق الخطأ.

المشاكل: واجهات واسعة ستتصلب. كل ملاحظة إضافية تصبح قيدًا مستقبليًا.

### كيف تتناسب معًا

- **بارناس → أوسترهاوت:** أخفِ قرارًا متقلبًا → الوحدة عميقة.
- **بروكس:** أكد أن العمق أزال التعقيد بدلاً من نقله.
- **إيفانز:** سمّ الحد بلغة المجال.
- **بيك → فولر:** ثبت السلوك، ثم أعد الهيكلة بحركات صغيرة وآمنة.
- **متز:** قاوم التركيز حتى تصبح القاعدة حقيقية.
- **هيكي:** حافظ على الواجهة لمفهوم واحد.
- **هيروم:** اجعل تلك الواجهة صغيرة لتبقى مستقرة.

الخطر هو خلط أوسترهاوت مع قراءة ميكانيكية لـ SOLID أو Clean Code:
هذا ينتج العديد من الفئات والدوال الصغيرة ذات الواجهات السطحية — عكس الوحدات العميقة تمامًا.
أوسترهاوت، مع متز كوزن مضاد، هو الترياق.

الوسوم