أنت مهندس [لغة/إطار عمل] كبير تراجع التعليمات البرمجية لـ [مشروع/نطاق].
الهدف: [إصلاح الأخطاء | الأداء | إمكانية القراءة | الأمان | تجربة المطور | اتساق API]
القيود: [دليل الأسلوب، الإصدارات المدعومة، حدود الذاكرة/الوقت، قيود المكتبة]
السياق:
- وقت التشغيل/البيئة: [Node 20, JVM 17, Python 3.11, iOS 17، إلخ.]
- التبعيات الرئيسية: [قائمة]
- الهندسة المعمارية: [وحدة واحدة، خدمة مصغرة، بدون خادم، سداسية، إلخ.]
- الواجهات/العقود ذات الصلة: [رابط أو مضمن]
المهمة:
1) راجع التعليمات البرمجية التالية بحثًا عن [الأهداف].
2) حدد مشكلات معينة بالأدلة (مراجع الأسطر وتقديرات التعقيد والحالات الطرفية).
3) اقترح اختلافات ضئيلة وموجهة.
4) قدم نسخة نهائية مُعاد هيكلتها.
5) اشرح المفاضلات والمخاطر.
التعليمات البرمجية:
```[اللغة]
// الصق التعليمات البرمجية هنا

الهدف: تقليل تعقيد الوقت والذاكرة دون تغيير السلوك العام.
توفير: التعقيد الحالي والتعقيد المقترح والتحسينات الصغيرة مقابل التغييرات الخوارزمية والمعايير لتشغيلها.

إعادة الهيكلة من أجل الوضوح: تسمية أفضل ووظائف أصغر ومسؤولية واحدة.
أضف سلاسل الوثائق/JSDoc، وقم بتبسيط تدفق التحكم، وقم بإزالة التعليمات البرمجية غير المستخدمة. حافظ على استقرار واجهة برمجة التطبيقات العامة.

نموذج التهديد: إدخال غير موثوق به من [المصدر].
تحقق: الحقن، وإلغاء التسلسل، وSSRF، وXSS، وCSRF، وauthZ/authN، والتعامل مع الأسرار.
اقتراح: مكتبات آمنة وأنماط التحقق والاختلافات الضئيلة.

نحن ننتقل من [lib A] إلى [lib B].
قم بإدراج التغييرات التي قد تؤدي إلى أعطال، واقترح طبقة محول، وقدم خطة طرح تدريجية مع الاختبارات.

البيئة: Python 3.11، FastAPI، Pydantic v2.
العقد: يجب أن ترجع نقطة النهاية 200 مع { data, meta } حتى في حالات الفشل الجزئي.
القيد: يجب أن يظل غير متزامن؛ لا يمكن إضافة تبعيات ثقيلة جديدة.

1) النقد: قائمة المشكلات الملموسة مع الأدلة.
2) الاختلاف: أصغر التغييرات للإصلاح.
3) إعادة الهيكلة: تعليمات برمجية نهائية نظيفة واصطلاحية.
4) الاختبارات: اختبارات الوحدة التي تغطي المسار السعيد + 3 حالات طرفية.

اقترح 3 خيارات لإعادة الهيكلة:
- الخيار أ: تغيير بسيط
- الخيار ب: إعادة تصميم معتدلة
- الخيار ج: إعادة كتابة كاملة
لكل خيار: الإيجابيات/السلبيات والتعقيد والمخاطر وخطة الترحيل ومتى يتم اختياره.

القيود: نفس واجهة برمجة التطبيقات العامة، <50 مللي ثانية p95، <10 ميجابايت ذاكرة إضافية، لا توجد تبعيات جديدة لوقت التشغيل.
أظهر كيف تلبي عملية إعادة الهيكلة الخاصة بك كل قيد بالقياسات أو المنطق.

أنت مهندس Python كبير. الهدف: الصحة + الأداء.
البيئة: Python 3.11، FastAPI، httpx، Pydantic v2. العقد: لا تطرح أبدًا في حالة الفشل الجزئي.
المهمة: المراجعة وإعادة الهيكلة. توفير النقد ← اختلافات ضئيلة ← إعادة هيكلة نهائية ← اختبارات.
التعليمات البرمجية:
```python
from fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

قم بتعليق كل اقتراح بـ: {الخطورة والفئة والأساس المنطقي}. قم بتضمين مقتطفات قبل/بعد وخطة ترحيل من خطوة واحدة إذا كان السلوك قد يتغير.

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

الرد بكتلتين بالضبط:
1) ```diff
...التغييرات...

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

إذا كانت المتطلبات غامضة، اطرح ما يصل إلى 3 أسئلة توضيحية قبل المتابعة.

الدور: مهندس TypeScript كبير.
الهدف: تحسين إمكانية القراءة والسلامة في وقت التشغيل دون تغيير واجهة برمجة التطبيقات العامة.
البيئة: Node 20، TypeScript 5.4، Zod للتحقق من الصحة، ESLint Airbnb، strictNullChecks.
القيود: لا توجد تبعيات جديدة لوقت التشغيل تتجاوز Zod، ولا توجد تغييرات قد تؤدي إلى أعطال، والحفاظ على تعقيد O(n).
المهمة:
- النقد ← الاختلاف ← إعادة الهيكلة ← الاختبارات ← الملاحظات.
- قم بتمييز المشكلات بـ {الخطورة والفئة والأساس المنطقي}.
- قم بتضمين مخطط Zod للتحقق من صحة الإدخال و 4 اختبارات وحدة.
التعليمات البرمجية:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

قم بتشغيل تمريرة ESLint عقلية وقم بإدراج الانتهاكات التي تتوقعها، ثم قم بإصلاحها.

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

استخدم سياق المستودع فقط. راجع الملفات التي تم تغييرها في PR هذا بحثًا عن [الهدف]. قم بتعليق النتائج مضمنة مع الخطورة والأساس المنطقي. اقترح اختلافات تحافظ على واجهة برمجة التطبيقات العامة وNFRs. قم بتضمين اختبارات تلامس المسارات المتغيرة فقط.