ڈیبگنگ، ری فیکٹرز اور آرکیٹیکچر ریویوز کے لیے Claude کوڈنگ پرامپٹ پیک

چار شرائط جو نیچے دیے گئے ہر پرامپٹ کو کارگر بناتی ہیں

پرامپٹس سے پہلے، وہ اصول جو ان سب میں مشترک ہیں۔ ان کو کسی بھی کوڈنگ پرامپٹ میں شامل کرنا ماڈل تبدیل کرنے سے زیادہ آؤٹ پٹ بہتر بناتا ہے۔

اپنا ورژن بتائیں۔ ٹریننگ ڈیٹا اُس میجر ورژن کی طرف جھکا ہوتا ہے جس کے بارے میں سب سے زیادہ لکھا گیا ہو، جو اکثر وہ نہیں ہوتا جس پر آپ ہیں۔ We are on [framework] [version], [language] [version] زیادہ تر پرانے جوابات کو روکتا ہے۔

تبدیلی (diff) کو محدود رکھیں۔ فکس مانگیں تو اکثر آپ کو ری فیکٹر مل جاتا ہے۔ Change as little as possible, preserve existing structure and naming, and list every line you changed with a one line reason اس دستاویز کا سب سے مفید جملہ ہے۔

حل سے پہلے مفروضے مانگیں۔ جس ماڈل سے پوچھا جائے کہ کیا غلط ہے وہ ایک اندازہ نتیجے کی شکل میں دیتا ہے۔ جس ماڈل سے درجہ بند اسباب اور سستے چیکس مانگے جائیں وہ ایک ڈیبگنگ پلان دیتا ہے۔

فیل ہونے کا طریقہ لازمی قرار دیں۔ What could this break, and is this fixing the cause or the symptom? سب سے مہنگی قسم کی AI مدد کو پکڑتا ہے، یعنی وہ تبدیلی جو علامت کو غائب کر دیتی ہے جبکہ خرابی برقرار رہتی ہے۔

ڈیبگنگ

1. درجہ بند مفروضے

یہاں ایرر ہے، متعلقہ کوڈ ہے، اور جو میں پہلے ہی مسترد کر چکا ہوں۔ ابھی مجھے فکس مت دیں۔ چار سب سے ممکنہ اسباب کو امکان کے لحاظ سے درجہ بند کریں، اور ہر ایک کے لیے وہ واحد سب سے سستا چیک بتائیں جو اسے ثابت یا مسترد کر دے۔ ایرر: [paste]۔ کوڈ: [paste]۔ پہلے سے مسترد: [list]۔ سٹیک: [language, framework, versions]۔

2. وقفے وقفے سے آنے والا بگ

یہ وقفے وقفے سے فیل ہوتا ہے، تقریباً [frequency]، [conditions] کے تحت۔ ان اقسام کو شمار کریں جو یہ مخصوص علامت پیدا کر سکتی ہیں: ٹائمنگ، ترتیب، وسائل کا ختم ہونا، بیرونی انحصار، رنز کے درمیان اسٹیٹ کا رسنا، کلاک یا ٹائم زون، کیشنگ۔ ہر ایک کے لیے بتائیں کہ کوڈ میں کیا چیز اس کی تائید یا تردید کرتی ہے، اور بالکل بتائیں کہ انہیں الگ کرنے کے لیے مجھے کیا لاگ کرنا چاہیے۔ کوڈ: [paste]۔

3. مقامی طور پر کام کرتا ہے

یہ مقامی طور پر کام کرتا ہے اور [environment] میں فیل ہوتا ہے۔ ماحول کے فرق کی ہر قسم کی فہرست بنائیں جو یہ مخصوص علامت پیدا کر سکتی ہے: کنفیگریشن، ماحولیاتی متغیرات، ورژنز، فائل سسٹم اور کیس سینسیٹیویٹی، ٹائم زون اور لوکیل، نیٹ ورک اور DNS، اجازتیں، وسائل کی حدیں، اور بلڈ یا بنڈلنگ کے فرق۔ علامت کے پیش نظر امکان کے لحاظ سے درجہ بند کریں، اور ہر ایک کے لیے تشخیصی کمانڈ دیں۔

4. فکس اپنانے سے پہلے اسے سمجھائیں

وضاحت کریں کہ یہ فکس کیوں کام کرتا ہے، یہ کیا فکس نہیں کرتا، اور یہ کیا خراب کر سکتا ہے۔ اگر اصل وجہ کہیں اور ہے اور یہ صرف علامت کا پیوند ہے، تو براہِ راست بتائیں۔

کوڈ ریویو

5. ایک diff کا جائزہ لیں

اس diff کا جائزہ ایک سخت گیر ریویور کی طرح لیں۔ ترجیحی ترتیب میں اقسام: درستگی کے بگز، سیکیورٹی مسائل، غیر ہینڈل شدہ فیل ہونے کے طریقے، ریس کنڈیشنز، پھر اسٹائل۔ ہر نتیجے کے لیے شدت، مخصوص لائن، اور یہ بتائیں کہ عمومی طور پر نہیں بلکہ اس کوڈبیس میں یہ کیوں اہم ہے۔ فارمیٹنگ پر تبصرہ نہ کریں۔ اگر diff درست ہے تو یہی بتائیں، نتائج گھڑیں نہیں۔ کنونشنز: [describe]۔ Diff: [paste]۔

6. سیکیورٹی پاس

اس کوڈ کا خاص طور پر سیکیورٹی مسائل کے لیے جائزہ لیں: انجیکشن، توثیق اور اجازت کے خلا، غیر محفوظ ڈی سیریلائزیشن، کوڈ یا لاگز میں راز، حساس آپریشن تک پہنچنے والا غیر تصدیق شدہ ان پٹ، اور انحصار کا خطرہ۔ ہر ایک کے لیے، صرف قسم کا نام لینے کے بجائے حملے کا راستہ واضح طور پر بتائیں۔ صاف بتائیں کہ [deployment, auth layer, data sensitivity] دیکھے بغیر آپ کیا اندازہ نہیں لگا سکتے۔

7. فیل ہونے کے طریقے کا آڈٹ

اس کوڈ کی ہر بیرونی کال کے لیے بتائیں کہ کیا ہوتا ہے جب یہ سست ہو، جب یہ فیل ہو، جب یہ غیر متوقع ڈیٹا لوٹائے، اور جب یہ جزوی طور پر کامیاب ہو۔ ان میں سے کون سے فی الحال ان ہینڈلڈ ہیں، اور کون سے خاموش رہیں گے؟

وہ آخری والا عمومی جائزے سے کہیں زیادہ حقیقی پروڈکشن مسائل تلاش کرتا ہے، کیونکہ یہ ان راستوں کے بارے میں پوچھتا ہے جن کے لیے کسی نے ٹیسٹ نہیں لکھا۔

ری فیکٹرنگ اور آرکیٹیکچر

8. ری فیکٹر پلان

[description] کو ری فیکٹر کرنے کا ایک ترتیب وار پلان تجویز کریں۔ شرائط: [x] کا پبلک API تبدیل نہیں ہو سکتا، ہم مسلسل ڈیپلائے کرتے ہیں لہٰذا ہر مرحلہ آزادانہ طور پر شپ ایبل ہونا چاہیے، اور ہر مرحلے کے بعد ٹیسٹس پاس ہونے چاہئیں۔ ہر مرحلے کے لیے تبدیلی، خطرہ، اسے تصدیق کرنے کا طریقہ، اور واپس پلٹنے کا طریقہ بتائیں۔ خطرے کے لحاظ سے ترتیب دیں، سب سے کم پہلے۔ ابھی کوڈ نہ لکھیں۔

9. دوسرے پہلو کی دلیل دیں

میں [context and constraints] کے لیے [approach B] پر [approach A] کو ترجیح دے رہا ہوں۔ B کے لیے سب سے مضبوط دلیل بنائیں۔ ہماری شرائط کے بارے میں کیا سچ ہونا چاہیے تاکہ B درست ہو، اور کیا اس میں سے کچھ یہاں سچ ہے؟ یہ نتیجہ نہ نکالیں کہ دونوں درست ہیں۔

10. سمجھیں کہ آپ کو کیا وراثت میں ملا

یہ اہم سورس فائلیں ہیں۔ یہ بتائیں: انٹری پوائنٹس، درخواست سے جواب تک ڈیٹا کا بہاؤ، وہ اسٹیٹ جو مشترک ہے اور کہاں تبدیل ہوتی ہے، بیرونی انحصار اور ہر ایک کے دستیاب نہ ہونے پر کیا ہوتا ہے، اور پیچیدگی اور کپلنگ کی بنیاد پر بگز رکھنے کے سب سے زیادہ امکان والے تین علاقے۔ واضح طور پر بتائیں کہ جو میں نے فراہم کیا اس سے آپ کیا متعین نہیں کر سکتے۔

وہ آخری ہدایت اہم ہے۔ ماڈلز اُس فائل کے رویے کی وضاحت کریں گے جو آپ نے پیسٹ نہیں کی، محض اس کے نام سے اندازہ لگا کر۔ نامعلوم چیزوں کی واضح فہرست پر مجبور کرنا آپ کو بتاتا ہے کہ آپ کو کیا پڑھنا چاہیے۔

ٹیسٹس

11. وہ ٹیسٹس جو آپ نہ لکھتے

اس فنکشن کے لیے ٹیسٹ کیسز لکھیں، ان ان پٹس پر توجہ دیتے ہوئے جن پر میں نے شاید غور نہیں کیا: حدود، خالی اور null، یونیکوڈ، بہت بڑی قدریں، ہم وقتی کالز، اور نفاذ میں کوئی بھی مضمر مفروضہ۔ ہر ٹیسٹ کے لیے وہ مفروضہ بتائیں جسے وہ چیک کر رہا ہے۔ فنکشن: [paste]۔

12. ٹیسٹ سویٹ کو ٹیسٹ کریں

یہ ایک فنکشن اور اس کے موجودہ ٹیسٹس ہیں۔ کون سا رویہ کور نہیں ہوا؟ خاص طور پر: ایرر پاتھس، حدی قدریں، پیرامیٹرز کے درمیان تعامل، اور کوئی بھی ایسی چیز جو نفاذ کرتا ہے مگر کوئی ٹیسٹ اسے تصدیق نہیں کرتا۔ موجودہ ٹیسٹس کو دوبارہ نہ لکھیں۔

دوسرا زیادہ قیمتی پرامپٹ ہے اور یہ شاذ و نادر ہی چلایا جاتا ہے۔ کوریج فیصد آپ کو بتاتے ہیں کہ کون سی لائنیں چلیں، نہ کہ کون سے رویے واقعی طے شدہ ہیں، اور ان دونوں کے درمیان کا فرق وہ جگہ ہے جہاں ریگریشنز رہتی ہیں۔

سیکنڈ اوپینین پیٹرن

اس پورے پیک کی سب سے زیادہ فائدہ مند عادت، اور وہ جس کے لیے ایک سے زیادہ ماڈل درکار ہوتے ہیں۔

ایک ماڈل سے جواب حاصل کریں۔ پھر تبدیل کریں اور اسے حوالے کر دیں:

ایک اور انجینئر نے اس مسئلے کے لیے یہ حل تجویز کیا۔ اس میں کیا غلط ہے یہ تلاش کریں: ایج کیسز کے تحت درستگی، ہم وقتی، ایرر ہینڈلنگ، [scale] پر کارکردگی، یا ایک آسان طریقہ جو نظرانداز ہو گیا۔ اگر یہ واقعی درست ہے تو صاف صاف بتائیں، اعتراضات نہ گھڑیں۔ مسئلہ: [paste]۔ تجویز کردہ حل: [paste]۔

دو نتائج ہیں اور دونوں مفید ہیں۔ یا تو دوسرا ماڈل ایک حقیقی خامی تلاش کرتا ہے، جو آپ اب مرج کرنے سے پہلے جان لیتے ہیں، یا یہ اختلاف کرنے پر زور دیے جانے کے باوجود متفق ہوتا ہے، جو ایک بامعنی تصدیق ہے۔ اسی ماڈل کے ساتھ دہرانا آپ کو ان میں سے کوئی نہیں دیتا، کیونکہ اپنے ہی آؤٹ پٹ کا جائزہ لینے والا ماڈل زیادہ تر اپنے آپ سے متفق ہوتا ہے۔

اسے ان فیصلوں پر استعمال کریں جن کا غلط ہونا مہنگا پڑے: اسکیما میں تبدیلی، ہم وقتی فکس، auth یا پیسے سے متعلق کوئی بھی چیز۔ معمول کے کام پر نہیں۔ پورا ورک فلو ایک جگہ دیکھنے کے لیے ماڈلز کا شانہ بشانہ موازنہ، گفتگو کے دوران ماڈلز تبدیل کرنا، اور متعدد ماڈلز کے ساتھ کوڈ لکھنا اور ڈیبگ کرنا دیکھیں۔

کن باتوں کا خیال رکھیں

گھڑے ہوئے APIs۔ پراعتماد میتھڈ نام، پیرامیٹرز، اور کنفیگ کیز جو موجود ہی نہیں، خاص طور پر ان لائبریریوں کے لیے جو حال ہی میں تبدیل ہوئی ہوں۔ سگنیچر بالکل ٹھیک نظر آئے گا۔ کسی بھی غیر مانوس چیز پر تعمیر کرنے سے پہلے اصل دستاویزات چیک کریں۔

کوئی اعتماد کا اشارہ نہیں۔ ایک درست فکس اور ایک باریکی سے غلط فکس بالکل یکساں یقین کے ساتھ آتے ہیں۔ لہجہ آپ کو کچھ نہیں بتاتا۔

خاموش اسکوپ کریپ۔ یہی وجہ ہے کہ دوسری شرط موجود ہے۔

سیکیورٹی تھیٹر۔ آپ کے کوڈ میں کمزوری کی اقسام کا نام لینا ایک مفید پہلا پاس ہے۔ یہ آڈٹ نہیں ہے، اور ماڈل کو آپ کے تھریٹ ماڈل، ڈیپلائمنٹ، یا ڈیٹا کی حساسیت کا علم نہیں۔

جو پرامپٹس آپ ہفتہ وار استعمال کرتے ہیں انہیں ایسی جگہ رکھیں جہاں سے پیسٹ کر سکیں، اور مستقل شرائط کو پروجیکٹ کی ہدایات میں ڈالیں تاکہ وہ اس پروجیکٹ کی ہر چیٹ پر خودکار طور پر لاگو ہوں۔