تجاوز إلى المحتوى
تعلّم لعملك المرجع مقالات المحفوظات
العربية

playbook

اقرأ codebase الخاص بك بالإنجليزية البسيطة

وجّه Claude إلى repo الخاص بك واسأل عمّا يحدث حين يُسجّل مستخدم، وأي ملفات تعمل وبأي ترتيب، وأين ستعيش feature جديدة — بلا مطوّر في الغرفة.

متوسّط ~30 دقيقة

متى تلجأ إلى هذا

أنت لا تكتب كودًا، فيتحوّل كل سؤال «كيف يعمل هذا فعلًا؟» إلى اجتماع مع مهندس. لكن الكود هناك تمامًا، وClaude يستطيع قراءته. هذا النظام يوجّه Claude إلى الـ repository الخاص بك ويجعله يشرح، بالإنجليزية البسيطة، ما يحدث حين يفعل مستخدم X، أي ملفات تعمل وبأي ترتيب، وأين ستندرج feature جديدة تقريبًا. العائد ليس استبدال مهندسيك — بل أن تدخل المحادثة بـ«ها هو شكل الأمر»، كي يُنفَق الوقت الهندسي على الحُكم، لا على سرد الـ codebase لك.

جهّز هذا أولًا

  • الـ repository الفعلي، مفتوحًا في Claude Code من المجلد الجذر للمشروع — لا وصفًا له، بل الشيء الحقيقي.
  • التدفّق الواحد الذي تريد فهمه، بمصطلحات المستخدم — «ماذا يحدث حين يُسجّل أحدهم»، «أين يُخزَّن مقال محفوظ».
  • دفتر ملاحظات (أو ملف notes.md) لالتقاط الخريطة بالإنجليزية البسيطة التي يعطيك إياها Claude، كي تبدأ منها محادثة الهندسة التالية.

الـ workflow

  1. احصل على المشهد العام أولًا

    قبل تعقّب تدفّق محدّد، اجعل Claude يصف شكل الـ repo كله — المجلدات الرئيسية وما لكلٍ منها. التوجيه أولًا يمنع Claude (وأنت) من الضياع في ملف واحد.

    أنت تطلب 
    هذا codebase الخاص بنا. بالإنجليزية البسيطة، أعطني خريطة: ما المجلدات الرئيسية وما المسؤول عنه كلٌ منها؟ أين يعيش الـ frontend مقابل الـ backend مقابل البيانات؟ أبقها نظرة عامة بحجم شاشة واحدة — لا كود بعد، فقط شكل الأمر.

    ما تحصل عليه خريطة بنيوية قصيرة — «مجلد app/ هو الـ web UI، وapi/ يعالج الـ requests، وdb/ هو طبقة البيانات، وauth/ يعالج تسجيل الدخول». كافية لتعرف أي حيّ يعيش فيه أي سؤال.

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

  2. تعقّب تدفّقًا حقيقيًا واحدًا من البداية للنهاية

    اختر فعل مستخدم ملموسًا واجعل Claude يتبعه عبر الملفات بالترتيب. «ماذا يحدث حين يُسجّل مستخدم» يحوّل العمارة المجرّدة إلى قصة تستطيع متابعتها.

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

    ما تحصل عليه تعقّب مرقّم يسمّي ملفات حقيقية — «1. الـ form في SignupForm.tsx يرسل (POST) إلى api/auth/register.ts؛ 2. ذاك يتحقّق ويستدعي createUser في db/users.ts؛ 3. الصف يهبط في جدول users؛ إن فشلت التسجيلات، ابدأ في register.ts». مسار تستطيع اتباعه فعلًا.

  3. اسأل الأسئلة التي قد تُحرَج من طرحها في اجتماع

    هذه هي الغرفة الآمنة. لن يحكم Claude على سؤال أساسي، والإجابة عنها على انفراد تعني أن محادثات الهندسة تعمل على مستوى أعلى.

    أنت تطلب 
    ثلاثة أسئلة بسيطة: أين تُخزَّن كلمة مرور المستخدم فعلًا، وهل هي مُجزّأة (hashed)؟ ماذا يحدث لمقالات المستخدم المحفوظة إن حذف حسابه؟ وأي ملف أُغيّره لأعدّل صياغة بريد تأكيد التسجيل الإلكتروني؟

    ما تحصل عليه إجابات مباشرة راسخة في الكود — «كلمات المرور مُجزّأة بـ bcrypt في register.ts، لا تُخزَّن خامة أبدًا؛ حذف الحساب يتعاقب (cascade) ويزيل المحفوظات عبر db/users.ts؛ نص البريد الإلكتروني يعيش في emails/welcome.ts». الأساسيات، مُجابة بلا اجتماع.

  4. اعثر على أين ستعيش feature جديدة

    الآن وجّهه إلى الأمام. سؤال أين *ستذهب* feature يحوّل القراءة إلى نطاق تستطيع أخذه إلى الهندسة — «ها هو تقريبًا ما يمسّه» بدل صفحة بيضاء.

    أنت تطلب 
    لو بنينا feature «حفظ المقالات للقراءة لاحقًا»، أي ملفات موجودة سيمسّها مهندس على الأرجح، وما الملفات الجديدة التي ستلزم على الأرجح؟ فقط الشكل التقريبي للعمل وما يتصل به — سأستخدم هذا لتحديد نطاق محادثة الهندسة، لا لكتابتها بنفسي.

    ما تحصل عليه نطاق راسخ — «يمسّ على الأرجح component قائمة المقالات وdb/ لجدول saved_articles جديد؛ يحتاج عرض Saved جديدًا وAPI route للحفظ/إلغاء الحفظ». تدخل الهندسة بشكل العمل، لا بعلامة استفهام.

    التقط هذا في ملاحظاتك — إنه الفرق بين سؤال الهندسة «هل هذا صعب؟» وسؤال «هل مسّ هذه الملفات يطابق كيف ستفعلها؟»

اجعله ملكك

  • **onboarding نفسك:** جديد على شركة أو codebase موروث؟ شغّل الخطوات 1-3 عبر عدة تدفّقات لبناء نموذجك الذهني بسرعة، قبل أن تقابل من كتبه.
  • **تحديد نطاق feature حقيقية:** اربط هذا مباشرةً خارج **اختبر فكرة تحت الضغط إلى spec للـ v1** — الـ spec يقول *ماذا*، وهذا يقول *أين تعيش* و*كم حجمها* تقريبًا — كلاهما يغذّي اللعبة الختامية، **من طلب العميل إلى الجاهزية للـ roadmap**.
  • **اجعله روتينًا:** لـ repo ستعود إليه باستمرار، ملف CLAUDE.md في الجذر (انظر تبويب *Features*) يعلّم Claude أعراف المشروع كي تكون كل قراءة مستقبلية أحدّ.

انتبه إلى

  • Claude يشرح الكود؛ المهندس ما زال يمتلك ما إذا كان *صحيحًا*. تعقّب بالإنجليزية البسيطة قد يكون مخطئًا بثقة في بِتٍ دقيق — عامله كخريطة للتحقّق منها مع الهندسة، لا كحُكم للتصرّف عليه.
  • عامل الـ codebase على أنه سري. إن احتوى الـ repo على secrets أو keys أو بيانات عملاء، فأنت تقرأ مادة مملوكة — أبقها في بيئتك المُعتمَدة ولا تلصق مقتطفات في أي مكان عام.
  • القراءة للفهم، لا لتعديل كود حيّ. اطلب من Claude أن *يشرح* و*يحدّد النطاق*؛ ودع مطوّرًا يمتلك أي تغيير فعلي على النظام العامل.

ستحصل في النهاية على خريطة بالإنجليزية البسيطة لـ codebase الخاص بك — كيف يعمل تدفّق حقيقي، والأساسيات مُجابة بلا اجتماع، ونطاق تقريبي لـ feature جديدة — كي تبدأ محادثات الهندسة من فهم مشترك بدل صفحة بيضاء.