أنماط التوجيه لهندسة برمجيات أنظف وإعادة كتابة أقل

كيف تبدو «الهندسة الأنظف» في العمل بمساعدة الذكاء الاصطناعي

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

تعريف عملي: الوضوح، التجزيء، القابلية للاختبار

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

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

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

لماذا تحدث إعادة الكتابة (ولماذا يمكن للذكاء الاصطناعي أن يضخمها)

عادة لا تُسبب إعادة الكتابة "كود سيئ" بحد ذاته — بل يُسببها القيود المفقودة، نطاق غامض، وافتراضات خفية. أمثلة:

• بُنيت ميزة لنوع مستخدم واحد، ثم نكتشف وجود ثلاث أدوار وأذونات مختلفة.
• تظهر متطلبات أداء أو تسجيل تدقيق أو احتفاظ بالبيانات في وقت متأخر.
• تتصرف واجهة برمجة خارجية بشكل مختلف عما توقّعنا، مما يجبر التعديلات في كل مكان.

يمكن للذكاء الاصطناعي أن يسرّع هذا النمط الفاشل بإنتاج مخرجات مقنعة بسرعة، مما يجعل من السهل البناء على أساسات هشة.

ماذا تتوقع من الأنماط في هذا الدليل

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

أين تناسب هذه الأنماط في سير عملك

ستستخدمها عبر دورة التسليم كاملة:

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

إذا كنت تستخدم سير عمل يعتمد على التوليد التفاعلي (حيث يُولَّد النظام ويتكرر عبر الدردشة)، فهذه نقاط التفتيش تصبح أكثر أهمية. على سبيل المثال، في Koder.ai يمكنك تشغيل حلقة "وضع التخطيط" لتثبيت المتطلبات والعقود قبل توليد كود React/Go/PostgreSQL، ثم استخدام لقطات/التراجع للتكرار بأمان عند تغير الافتراضات — دون أن تُحوِّل كل تغيير إلى إعادة كتابة.

كيفية استخدام أنماط التوجيه دون خلق عمل إضافي

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

متى تستخدم الأنماط

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

أثناء التصميم: استخدم أنماط تجبر التنازلات الصريحة (مثل البدائل، المخاطر، حدود البيانات) قبل البدء بالتنفيذ.

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

جمع المدخلات أولاً (اجعلها خفيفة)

ستحصل على مخرجات أفضل بحزمة مدخلات صغيرة ومتسقة:

• الأهداف: ماذا يعني "مكتمل" (أهداف زمن استجابة، نتائج UX، حدود التكلفة)
• المستخدمون: الأدوار، سير العمل الرئيسي، وأبرز نقاط الألم
• القيود: التقنية المستخدمة، المهل، متطلبات الامتثال/الأمن
• البيانات والتكاملات: المصادر، الملكية، واجهات برمجة التطبيقات، الاعتماد على طرف ثالث

إذا لم تكن تعرف شيئاً، اذكر ذلك صراحة واطلب من الذكاء الاصطناعي سرد الافتراضات.

اطلب صيغ مخرجات قابلة لإعادة الاستخدام

بدلاً من "فسّر التصميم"، اطلب مخرجات يمكنك لصقها في مستندات أو تذاكر:

• سجل القرار (الخيارات → المزايا/العيوب → المختار → لماذا)
• جدول للمكوّنات بمسؤولياتها وحدودها
• قائمة تحقق للموثوقية والاختبار
• وصف مبسط للمخطط (مثل نص Mermaid) يمكنك عرضه لاحقاً

كرر في حلقات صغيرة مع معايير قبول

قم بدورات 10–15 دقيقة: مطالبة → مسح سريع → ضيق. دائمًا تضمّن معايير القبول (ما الذي يجب أن يكون صحيحاً ليكون التصميم مقبولاً)، ثم اطلب من الذكاء الاصطناعي أن يفحص نفسه مقابلها. هذا يمنع العملية من الانزلاق إلى إعادة تصميم لا نهائية ويجعل الأنماط التالية سريعة التطبيق.

النمط 1: وضّح المتطلبات قبل أي تصميم

معظم "إعادات بناء الهندسة" لا تُسبَّبها مخططات سيئة — تُسبَّب ببناء الشيء الصحيح للمشكلة الخاطئة (أو الناقصة). عند استخدام LLM مبكراً، لا تطلب الهندسة أولاً. اجعله يكشف الغموض.

الحركة في المطالبة: حوّل عدم اليقين إلى قائمة تحقق

استخدم النموذج كمقابل متطلبات. هدفك هو مواصفة قصيرة ذات أولوية يمكنك تأكيدها قبل أن يصمم أحد المكوّنات، يختار قواعد البيانات، أو يلتزم بواجهات برمجة.

إليك قالب يمكنك نسخه ولصقه:

You are my requirements analyst. Before proposing any architecture, do this:

1) Ask 10–15 clarifying questions about missing requirements and assumptions.
   - Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.

2) Produce a prioritized scope list:
   - Must-have
   - Nice-to-have
   - Explicitly out-of-scope

3) List constraints I must confirm:
   - Performance (latency/throughput targets)
   - Cost limits
   - Security/privacy
   - Compliance (e.g., SOC2, HIPAA, GDPR)
   - Timeline and team size

4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”

Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):

### ما الذي تبحث عنه في المخرجات

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

## النمط 2: رحلات المستخدم أولاً، ثم الاختيارات التقنية

عندما تبدأ بالأدوات ("هل نستخدم event sourcing؟") غالباً ما تصمم على أساس الهندسة بدل المستخدم. طريق أسرع للهيكل النظيف هو طلب النموذج لوصف رحلات المستخدم أولاً بلغة بسيطة، ثم ترجمة تلك الرحلات إلى مكونات وبيانات وواجهات برمجة.

### قالب مطالبة بسيط يركز على الرحلات

استخدم هذا كنقطة بداية قابلة للنسخ:

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

ثم اطلب:

1) "وصف تدفق خطوة بخطوة لكل إجراء بلغة بسيطة."

2) "قدّم مخطط حالة بسيط أو قائمة حالات (مثلاً: Draft → Submitted → Approved → Archived)."

3) "سجل سيناريوهات غير المسار السعيد: مهلات، محاولات إعادة، طلبات مكررة، إلغاءات، ومدخلات غير صالحة."

### تحويل الرحلات إلى قرارات (دون القفز مقدماً)

بمجرد وضوح التدفقات، يمكنك أن تطلب من الذكاء الاصطناعي ربطها بالاختيارات التقنية:

- أين نحتاج **التحقق** مقابل **قواعد العمل**؟
- أي خطوات تتطلب **idempotency** (محاولات آمنة)؟
- ما البيانات التي يجب **تخزينها**، وما الذي يمكن اشتقاقه، وما الذي يحتاج سجل تدقيق؟

فقط بعد ذلك اطلب مخطط هندسي (خدمات/وحدات، حدود، ومسؤوليات) مرتبط مباشرة بخطوات التدفق.

### حول التدفقات إلى معايير قبول قابلة للاختبار

اختم بأن تطلب من الذكاء الاصطناعي تحويل كل رحلة إلى معايير قبول يمكنك اختبارها فعلياً:

- "Given/When/Then لكل خطوة وحالة فشل." 
- "ماذا يجب أن يُرجع النظام أو يعرض؟" 
- "ماذا يجب تسجيله، ومتى يجب أن يؤدي إلى محاولة إعادة أو خطأ يظهر للمستخدم؟"

هذا النمط يقلل إعادة الكتابة لأن الهندسة تنمو من سلوك المستخدم — لا من افتراضات حول التقنية.

## النمط 3: سجل الافتراضات لمنع مفاجآت إعادة الكتابة

معظم إعادة العمل لا تُسبَّب بتصميم سيئ بقدر ما تُسبَّب بالافتراضات الخفية التي تتبين لاحقاً خطأ. عندما تطلب من LLM بنية، غالباً ما يملأ الثغرات بتخمينات معقولة. يجعل سجل الافتراضات تلك التخمينات مرئية مبكراً، حين تكون التغييرات رخيصة.

### ماذا تطلب من النموذج أن يفعل

هدفك فصل واضح بين **الحقائق التي قدمتها** و**الافتراضات التي اختلقها**. استخدم نمط المطالبة التالي:

> **Template prompt**
> “Before proposing any solution: list your assumptions. Mark each as **validated** (explicitly stated by me) or **unknown** (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”

### قالب«سجل الافتراضات» القابل لإعادة الاستخدام

اجعله قصيراً حتى يستخدمه الناس فعلياً:

- **Assumption:** …
- **Status:** validated / unknown
- **Why it matters:** what decision it affects
- **How to validate:** question, check, or spike
- **If wrong, likely change:** what you’d redesign

### محفزات "ما الذي سيغير إجابتك؟"

أضف سطر واحد يطلب من النموذج إخراج نقاط التحول:

- “List 5 triggers: **what would change your answer?** (e.g., user volume, latency targets, compliance needs, data retention rules).”

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

## النمط 4: قارن عدة هندسات قبل اختيار واحدة

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

### قالب المطالبة الأساسي

استخدم مطالبة تطلب *متعدد* من الحلول وجدول مفاضلات منظم:

```text
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.

Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:

لماذا يقلل هذا إعادة الكتابة

المقارنة تجبر النموذج (وأنت) على إظهار الافتراضات الخفية: أين يعيش الـstate، كيف تتواصل الخدمات، ما الذي يجب أن يكون متزامناً، وما يمكن تأجيله. جدول المعايير يمنع مناقشات "microservices vs monolith" من أن تتحول إلى آراء شخصية، ويُؤسس القرار لما تهتم به فعلاً: الشحن السريع، تقليل عبء التشغيل، أو تحسين الاعتمادية.

اطلب توصية وحدود واضحة

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

النمط 5: حدود الموديلات والمسؤوليات

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

الفكرة الأساسية

اطلب من الذكاء الاصطناعي تعريف وحدات ومسؤوليات، وما لا ينتمي لكل وحدة. ثم اطلب واجهات (مدخلات/مخرجات) وقواعد تبعية، لا خطة بناء أو تفاصيل تنفيذ.

قالب مطالبة للنسخ/اللصق

استخدم هذا عند رسم ميزة جديدة أو إعادة تنظيم منطقة فوضوية:

• المحتوى: \u003cone paragraph about the product/feature\u003e
• الهدف: اقترح هندسة مجزأة بـ4–8 وحدات.

1. أدرج الوحدات مع:

   • الغرض (جملة واحدة)
   • المسؤوليات (3–5 نقاط)
   • ما لا تتحمّله (“لا تتعامل مع…”) (2–3 نقاط)

2. لكل وحدة، عرّف الواجهات فقط:

   • المدخلات (أحداث/طلبات/بيانات)
   • المخرجات (استجابات/أحداث/آثار جانبية)
   • واجهة API العامة (أسماء دوال أو نقاط نهاية مقبولة؛ لا صفوف داخلية)

3. قواعد التبعية:

   • تبعيات مسموح بها (A → B)
   • تبعيات ممنوعة (A ↛ C) مع سبب
   • أين تعيش الأنواع المشتركة (وماذا لا يجب أن يُشارك)

4. اختبار التغيير في المستقبل: مع تلك التغييرات المحتملة: \u003clist 3\u003e، أظهر أي وحدة يجب أن تستوعب كل تغيير ولماذا.

كيف تبدو مخرجات "جيدة"

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

النمط 6: العقود الخاصة بالبيانات وواجهات API أولاً (تجنّب إعادة تكامل)

إعادة العمل في التكامل غالباً لا تُسبَّب بـ"كود سيئ" — بل بوضوح العقود. إذا تقرر شكل البيانات وواجهات الـAPI متأخراً، كل فريق (أو وحدة) يملأ الفراغات بشكل مختلف، وتقضي السبرنت التالي في التوفيق بين الافتراضات المختلِفة.

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

مطالبة "عقد-أولاً"

استخدم هذه المطالبة المبكرة مع مساعدك الذكي:

• قالب: “Describe the data model, ownership, and lifecycle for each entity”

ثم تابع فوراً بـ:

• اطلب عقود API مع أمثلة (طلبات، استجابات، أشكال الأخطاء)
• أضف توقعات النسخ والتوافق للخلف
• اطلب قواعد التحقق وحالات الحافة لكل حقل

كيف تبدو مخرجات "جيدة"

تريد مستندات ملموسة، وليس نثرًا. مثال:

• Entity: Subscription
  • Owner: Billing service
  • Lifecycle: created on checkout → active → past_due → canceled (soft-delete after 90 days)
  • Source of truth: billing DB; other services cache read-only copies

ومخطط API مثال:

POST /v1/subscriptions
{
  "customer_id": "cus_123",
  "plan_id": "pro_monthly",
  "start_date": "2026-01-01"
}

201 Created
{
  "id": "sub_456",
  "status": "active",
  "current_period_end": "2026-02-01"
}

422 Unprocessable Entity
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "start_date must be today or later",
    "fields": {"start_date": "in_past"}
  }
}

قواعد النسخ والتوافق

اطلب من الذكاء الاصطناعي ذكر قواعد مثل: "الحقول المضافة مسموح بها دون ترقية الإصدار؛ إعادة التسمية تتطلب /v2؛ يجب على العملاء تجاهل الحقول غير المعروفة." هذه الخطوة الواحدة تمنع تغييرات كسرية صامتة — وإعادة الكتابة التي تتبعها.

النمط 7: أوضاع الفشل وقائمة تحقق للموثوقية

تُعاد كتابة البنى عندما يلتقي تصميم "المسار السعيد" بحركة حقيقية، تبعيات متقلبة، وسلوك مستخدم غير متوقع. هذا النمط يجعل الاعتمادية مخرج تصميم صريح، لا مشروع بعد الإطلاق.

قالب مطالبة للنسخ/اللصق

استخدم هذا مع وصف الهندسة المختارة:

List failure modes; propose mitigations; define observability signals.

For each failure mode:

• What triggers it?
• User impact (what the user experiences)
• Mitigation (design + operational)
• Retries, idempotency, rate limits, timeouts considerations
• Observability: logs/metrics/traces + alert thresholds

ما الذي تطلب من النموذج تغطيته (غير قابل للتفاوض)

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

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

مخرج قائمة تحقق للموثوقية

اختم المطالبة بـ: "أعد قائمة تحقق بسيطة يمكن مراجعتها خلال دقيقتين." تشمل قائمة جيدة عناصر مثل: مهلات التبعيات مضبوطة، المحاولات محدودة، idempotency مُطبّق لعمليات الإنشاء/الخصم، وجود إدارة ضغط/حدود معدل، مسار تدرج لالتفاف الأداء.

المراقبة مرتبطة بأفعال المستخدم

اطلب أحداثاً حول لحظات المستخدم (لا مجرد داخلية النظام): "user_signed_up", "checkout_submitted", "payment_confirmed", "report_generated". لكل حدث، اطلب:

• حقول السجل (user_id, request_id, idempotency_key)
• مقاييس (معدل النجاح، زمن الاستجابة p95/p99، عدد المحاولات)
• تعقّبات (spans لكل استدعاء تبعية)

هذا يحوّل الاعتمادية إلى مخرج تصميم يمكنك التحقق منه قبل وجود الكود.

النمط 8: تخطيط شريحة MVP لتقليل الإفراط في البناء

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

قالب المطالبة

استخدم هذا عندما تشعر أن الحل يتوسع أسرع من المتطلبات:

قالب: “Propose the smallest usable slice; define success metrics; list follow-ups.”

اطلب من النموذج الرد بـ:

• شريحة MVP: ما المُضمّن لشحن شيء حقيقي
• مقاييس النجاح: كيف ستعرف أنه نجح (مستخدم + تقني)
• المتابعات: ما يمكن تأجيله دون منع التعلم

اطلُب خارطة طريق مرحلية (MVP → v1 → v2)

أضف تعليمات ثانية: "أعط خارطة طريق مرحلية: MVP → v1 → v2، واشرح أي مخاطر يخفف كل مرحلة." هذا يبقي الأفكار المستقبلية مرئية دون إجبارها في الإصدار الأول.

أَرِد استثناءات صريحة لمنع توسع النطاق

السطر الأقوى في هذا النمط: "أدرج ما هو خارج النطاق صراحةً لـMVP." تحمي الاستثناءات قرارات الهندسة من التعقيد المبكر.

أمثلة جيدة على الاستثناءات:

• "لا تعافي متعدد المناطق في MVP (سجل الحوادث؛ خطط لـv2)."
• "لا نظام إضافات بعد (حافظ على الحدود نظيفة، لكن اشحن وحدات ثابتة)."
• "مزود دفع واحد فقط؛ جِهّز للتجريد لاحقاً إذا لزم الأمر."

حوّل الخطة إلى تذاكر مع تبعيات

أخيراً: "حوّل MVP إلى تذاكر، كل واحدة مع معايير قبول وتبعيات." هذا يجبر الوضوح ويكشف الاقترانات الخفية.

تفكيك تذاكر نموذجي جيد يشمل:

1. مسار "المسار السعيد" رقيق وكامل من الطرف إلى الطرف
2. نموذج بيانات أدنى + عقد API
3. معالجة أخطاء أساسية وتسجيل
4. نقطة تكامل واحدة (إن لزم) مع بديل مؤقت

إذا رغبت، اطلب من النموذج إخراجها بصيغة سير عمل فريقك (مثلاً حقول على طريقة Jira) واحتفظ بالمراحل اللاحقة كقائمة انتظار منفصلة.

النمط 9: مطالبات اختبار-أول التي تشكّل تصاميم أفضل

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

قالب مطالبة للنسخ/اللصق

استخدم هذا كنقطة بوابة عندما تكون على وشك تصميم مكوّن:

• قالب: “Write acceptance tests first; then propose implementation. You must: (1) list assumptions, (2) name unit vs integration tests, (3) define test data and mocks vs real dependencies, (4) include a definition of done.”

اطلب حدود الاختبار التي تطابق الوحدات

تابع بـ: "جمّع الاختبارات حسب مسؤولية الوحدة (طبقة API، منطق المجال، التخزين، التكاملات الخارجية). لكل مجموعة، حدد ما يُموَّه وما الحقيقي." هذا يحرّك النموذج بعيداً عن تصاميم متشابكة حيث يلمس كل شيء كل شيء. إذا لم يستطع شرح أين تبدأ اختبارات التكامل، فهندستك ربما ليست واضحة بعد.

استراتيجية بيانات الاختبار: تجنّب مجموعات هشة

اطلب: "اقترح خطة بيانات اختبار: fixtures vs factories، كيف تولّد حالات الحافة، وكيف تحافظ على حتمية الاختبارات. أدرج أي تبعيات يمكن أن تستخدم بدائل في الذاكرة وأيها يحتاج خدمة حقيقية في CI." كثيراً ما تكتشف أن ميزة "بسيطة" تحتاج عقداً، مجموعة بيانات أولية، أو معرفات ثابتة — من الأفضل اكتشاف ذلك الآن بدل أثناء إعادة الكتابة.

تعريف الإتمام (حتى يُشحن التصميم)

اختم بقائمة تحقق خفيفة:

• اجتياز الاختبارات (وحدات + تكامل) وتغطية معقولة لحالات الفشل
• مستندات بسيطة: الاستخدام، التكوين، وملاحظة حل المشاكل
• مراقبة/تنبيهات لحالات الفشل الرئيسية
• خطة نشر (علم الميزة، خطوات الهجرة، التراجع)

النمط 10: مطالبات مراجعة التصميم لاكتشاف المشاكل مبكراً

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

قالب المراجعة الأساسي

ابدأ بموقف ناقد واجبر التحديد:

Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can't evaluate something, say what information is missing.”

ألصق ملخَّص التصميم، القيود (الميزانية، الجدول الزمني، مهارات الفريق)، وأي متطلبات غير وظيفية (زمن استجابة، توافر، امتثال).

حوّل الملاحظات إلى قائمة مهام قابلة للتنفيذ

تفشل المراجعات عندما تكون الملاحظات غامضة. اطلب مجموعة إصلاحات مُرتبة حسب الأولوية:

Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”

هذا ينتج مجموعة مهام جاهزة للقرار بدلاً من نقاش.

قيّم خطر إعادة الكتابة

أداة مفيدة هي درجة بسيطة:

Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”

لا تبحث عن دقة مفرطة؛ هدفك إظهار أكثر الافتراضات عرضة لإعادة الكتابة.

اختم بـ"خطة الفرق"

أخيراً، امنع توسيع النطاق أثناء المراجعة:

Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”

عندما تكرر هذا النمط على كل تكرار، تتطوّر هندستك عبر خطوات صغيرة قابلة للعكس — والمشاكل الكبيرة تُكتشف مبكراً.

حزمة مطالبات قابلة للنسخ وسير عمل بسيط

استخدم هذه الحزمة كسير عمل خفيف يمكنك تكراره على كل ميزة. الفكرة هي سلسلة مطالبات بحيث ينتج كل خطوة مخرجات يمكن للخطوة التالية إعادة استخدامها — مما يقلل "فقدان السياق" وإعادة الكتابة المفاجئة.

سير العمل المكوَّن من 6 خطوات (اربط هذه الأنماط)

1. المتطلبات (توضيح + قيود)
2. خيارات الهندسة (قارن 2–3 مقاربات)
3. الحدود (وحدات + مسؤوليات)
4. العقود (البيانات + API)
5. الاختبارات (اختبار-أول + اختبارات وحدوية أساسية)
6. المراجعة (أوضاع الفشل + قائمة مراجعة التصميم)

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

حزمة مطالبات للنسخ/اللصق (مع حراسة)

SYSTEM (optional)
You are a software architecture assistant. Be practical and concise. 
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.

1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>

Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.

2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.

3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”

4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”

5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”

6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”

If you want a deeper companion, see /blog/prompting-for-code-reviews. If you’re evaluating tooling or team rollout, /pricing is a practical next stop.