برومبتات البرمجة
أكثر سبب لإجابات البرمجة الخاطئة هو أن النموذج لا يرى مشروعك: لا يعرف اللغة وإصدارها، ولا المكتبات، ولا ما جربته قبل أن تسأل. البرومبتات هنا تبدأ دائماً بهذا السياق، وتطلب من النموذج أن يشرح سبب المشكلة قبل أن يعطيك الحل، حتى تستطيع الحكم عليه. وتذكير مهم: لا تلصق كلمات المرور أو مفاتيح API أو بيانات العملاء في أي محادثة.
تصحيح خطأ برسالته الكاملة
متى تستخدمه: عندما يظهر لك خطأ لا تفهم سببه.
البيئة: [اللغة والإصدار، مثل Python 3.12 / Node 22]، الإطار: [Django / React / ...]. ماذا أحاول أن أفعل: [الهدف في سطر]. الكود المرتبط: ``` [الصق الجزء المرتبط فقط] ``` رسالة الخطأ كاملة: ``` [الصق الخطأ كاملاً مع الـ stack trace] ``` ما جربته: [الحلول التي لم تنجح]. 1) اشرح سبب الخطأ في 3 أسطر. 2) أعطني الإصلاح الأصغر الممكن مع توضيح ما تغير. 3) إذا كان هناك أكثر من سبب محتمل، رتبها واذكر كيف أتحقق من كل واحد.
- الصق رسالة الخطأ كاملة؛ السطر الأخير وحده غالباً لا يكفي.
- احذف أي مفاتيح أو كلمات مرور من الكود قبل لصقه.
شرح كود لم تكتبه
متى تستخدمه: عند استلام مشروع من شخص آخر أو قراءة كود من مصدر مفتوح.
اشرح هذا الكود لمبرمج بمستوى [مبتدئ/متوسط] يعرف [اللغة] لكنه لا يعرف هذا المشروع: ``` [الكود] ``` 1) ماذا يفعل في جملتين. 2) شرح سطر بسطر للأجزاء غير الواضحة فقط. 3) ما المدخلات والمخرجات والآثار الجانبية (قاعدة بيانات، ملفات، شبكة). 4) أي جزء يبدو خطيراً أو قابلاً للكسر، ولماذا.
- اطلب بعدها رسماً للتسلسل (sequence) إذا كان الكود يتعامل مع أكثر من خدمة.
- قسّم الملفات الكبيرة إلى دوال وأرسل كل دالة مع سياقها.
مراجعة كود قبل الدمج
متى تستخدمه: قبل رفع تعديل مهم، خصوصاً إن كنت تعمل وحدك ولا يوجد من يراجع.
أنت مراجع كود صارم في فريق [اللغة/الإطار]. هذا التعديل يفعل: [الوصف]. ```diff [الصق الـ diff أو الكود الجديد] ``` راجعه وركّز بالترتيب على: 1) أخطاء منطقية أو حالات حدّية لم تُعالج (قيم فارغة، تزامن، أخطاء الشبكة). 2) مشكلات أمنية (حقن SQL، صلاحيات، بيانات حساسة في السجلات). 3) الأداء إذا كان واضحاً. لكل ملاحظة: السطر، المشكلة، سيناريو يكسرها، والإصلاح المقترح. لا تذكر ملاحظات أسلوبية إلا إذا كانت تسبب خطأ.
- طلب «سيناريو يكسرها» يمنع الملاحظات النظرية ويجعل كل ملاحظة قابلة للاختبار.
- المراجعة الآلية لا تغني عن تشغيل الكود واختباره.
كتابة اختبارات لدالة
متى تستخدمه: عندما تريد التأكد أن دالة تعمل قبل تعديلها أو بعده.
اكتب اختبارات لهذه الدالة باستخدام [Jest / pytest / ...]: ``` [الدالة] ``` غطِّ: الحالة الطبيعية، القيم الحدّية، المدخلات غير الصالحة، وأي فرع if في الكود. قبل الكود: اكتب قائمة بالحالات التي ستختبرها وسبب كل منها. القيود: لا تغيّر الدالة نفسها، وإذا وجدت حالة تبدو خطأ في الدالة فاذكرها بدلاً من كتابة اختبار يوافق الخطأ.
- شغّل الاختبارات فعلاً؛ الاختبار الذي لم يُشغَّل قد يكون خاطئاً هو الآخر.
- القيد الأخير مهم: النموذج يميل لكتابة اختبارات تصف ما يفعله الكود لا ما يجب أن يفعله.
تصميم قاعدة بيانات لفكرة
متى تستخدمه: في بداية مشروع جديد قبل كتابة أي كود.
أنت مهندس قواعد بيانات. التطبيق: [وصف الفكرة في 3 أسطر]. المستخدمون وأدوارهم: [مثال: عميل، تاجر، مدير]. أهم العمليات: [قائمة بما يفعله المستخدم]. قاعدة البيانات: [PostgreSQL / MySQL / ...]. 1) اقترح الجداول والأعمدة وأنواعها والعلاقات. 2) حدد الفهارس (indexes) اللازمة لأكثر 3 استعلامات تكراراً. 3) اذكر قرارين تصميميين فيهما مفاضلة، واشرح الخيارين. 4) اكتب أوامر CREATE TABLE.
- اطلب بعدها استعلامات أهم الشاشات لتتأكد أن التصميم يخدمها.
- ابدأ بأبسط تصميم يعمل؛ يمكنك التوسع لاحقاً بالترحيلات (migrations).