Claude Code سیریز سبق 4: Claude Code کے استعمال کے کیسز کیا ہیں؟

عام استعمال کے کیسز

میں استعمال کے کیسز کو چار اقسام میں تقسیم کرتا ہوں، تعدد کے اعتبار سے اعلیٰ سے ادنیٰ تک۔

پہلی قسم: کوڈ کو سمجھنا

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

مخصوص طریقہ:

claude \"یہ پروجیکٹ کیا کرتا ہے؟ داخلہ کہاں ہے؟\" — یہ package.json، ڈائرکٹری کا ڈھانچہ، اور اہم فائلیں پڑھ کر ایک خلاصہ فراہم کرے گا۔
ایک فنکشن کھولیں اور اس سے منطق کی وضاحت اور فلو (متن میں) بنانے کو کہیں۔
اسے ایک API درخواست کے فرنٹ اینڈ سے ڈیٹا بیس تک مکمل راستے کا سراغ لگانے کو کہیں۔

یہاں یہ جو کام کرتا ہے، وہ بنیادی طور پر 'کوڈ پڑھنے کا گندا کام' کرنے میں آپ کی مدد کرنا ہے۔ آپ کو خود آدھے دن grep کرنے اور پھر دماغ میں پزل بنانے کی ضرورت نہیں۔ یہ راستہ صاف کرتا ہے، فیصلہ آپ کرتے ہیں۔

اس قسم کے منظر نامے کا متبادل ہے: کوڈ بیس میں دستی طور پر تلاش کرنا، نوٹ لینا، کال گراف بنانا۔

دوسری قسم: کوڈ لکھنا، کوڈ تبدیل کرنا

یہ سب سے زیادہ زیر بحث قسم ہے، لیکن حقیقت میں یہ سب سے زیادہ استعمال نہیں ہوتی۔ کوڈ لکھنے کے مناظر عام طور پر یوں ہوتے ہیں:

نیا فیچر بنانا: \"user ماڈیول کے تحت ای میل تبدیل کرنے کا ایک انٹرفیس شامل کریں، ای میل کی فارمیٹ کی تصدیق کریں، اور یونٹ ٹیسٹ لکھیں۔\"
کراس فائل ری فیکٹرنگ: \"ان تین فائلوں میں تمام moment() کو dayjs() سے تبدیل کریں، دوسری منطق میں تبدیلی نہ کریں۔\"
منتقلی اور اپ گریڈ: \"اس Vue 2 کے کمپوننٹ کو Vue 3 Composition API کے انداز میں تبدیل کریں۔\"

یہ جو کوڈ تیار کرتا ہے وہ ضروری نہیں کہ ایک بار میں درست ہو، لیکن یہ ایک بار میں کراس فائل کی تمام تبدیلیاں کر سکتا ہے، اور آپ فائل بہ فائل diff کر سکتے ہیں اور ایک ایک کو قبول یا مسترد کر سکتے ہیں۔

اس قسم کے منظر نامے کا متبادل ہے: دستی طور پر تکراری کوڈ لکھنا، کراس فائل حوالوں کو دستی طور پر تلاش کرکے تبدیل کرنا۔

تیسری قسم: ڈیبگنگ اور مرمت

جب بگ ظاہر ہوتا ہے، عام ورک فلو یہ ہوتا ہے: غلطی دیکھیں، فائل کا پتہ لگائیں، وجہ کا اندازہ لگائیں، تبدیلی کرکے آزمائیں، کام نہ آئے تو واپس آئیں۔ Claude Code براہ راست پورے ایرر اسٹیک کو قبول کر سکتا ہے اور پروجیکٹ کوڈ کے ساتھ مل کر خود پتہ لگا سکتا ہے۔

عام استعمال:

ناکام ٹیسٹ کا آؤٹ پٹ اسے دیں، یہ متعلقہ کوڈ پڑھے گا، تبدیلی کی تجویز دے گا، تبدیل کرے گا اور پھر ٹیسٹ دوبارہ چلائے گا تاکہ دیکھے کہ آیا یہ پاس ہوتا ہے۔
CI کی غلطی ملنے پر، لاگ چسپاں کریں، اسے ٹھیک کرنے کو کہیں، ٹھیک کرنے کے بعد git diff چلا کر تبدیلیوں کی تصدیق کریں۔

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

اس قسم کے منظر نامے کا متبادل ہے: بار بار ٹیسٹ چلانا، ایرر لاگ پڑھنا، دستی طور پر کوڈ کے فرقوں کا موازنہ کرنا۔

چوتھی قسم: متفرق آٹومیشن

اس قسم کے مناظر سب سے کم نمایاں ہیں، لیکن مل کر سب سے زیادہ وقت بچاتے ہیں۔

مثالیں:

Git کمٹ پیغام لکھنا: claude \"موجودہ git diff کی بنیاد پر Conventional Commits فارمیٹ میں کمٹ پیغام لکھیں\"
PR کی تفصیل تیار کرنا: اس سے موجودہ برانچ اور main کے درمیان فرق کا موازنہ کرنے کو کہیں، اور اس تبدیلی کا خلاصہ اور ٹیسٹ کی وضاحت تیار کریں۔
ریلیز نوٹ لکھنا: Claude Code سے پچھلے ہفتے کی کمٹ ہسٹری پڑھ کر CHANGELOG تیار کرنے کو کہیں۔
ماحولیاتی مسائل کا حل: \"یہ انحصار انسٹال کرتے وقت غلطی آئی، ٹرمینل آؤٹ پٹ دیکھ کر وجہ بتائیں۔\"

ان چیزوں کی مشترکہ خصوصیت یہ ہے: پیچیدہ نہیں، لیکن باریک۔ خود کرنے پر ونڈو تبدیل کرنا اور بہت کچھ ٹائپ کرنا پڑتا ہے۔ اسے دے دیں، چند سیکنڈ میں ہو جاتا ہے۔

اس قسم کے منظر نامے کا متبادل ہے: دستی طور پر متن میں ترمیم کرنا، معیاری دستاویزات لکھنا، ماحولیاتی ترتیب کے مسائل تلاش کرنا۔

ایک 'نقشہ'

ان چار اقسام کے مناظر کو روزمرہ کے ورک فلو میں ڈالیں تو یہ نقشہ کچھ یوں بنتا ہے:

ایک ناواقف پروجیکٹ ملنا
    │
    ▼
[کوڈ سمجھنا] ─── ڈھانچہ، داخلہ، اہم منطق سمجھنا
    │
    ▼
نیا فیچر یا ماڈیول تبدیل کرنا شروع کریں
    │
    ▼
[کوڈ لکھنا/تبدیل کرنا] ─── نفاذ تیار کرنا، کراس فائل ری فیکٹرنگ
    │
    ▼
ٹیسٹ چلائیں، بگ آتا ہے
    │
    ▼
[ڈیبگ اور مرمت] ─── غلطی کا تجزیہ، پتہ لگانا، ٹھیک کرنا، دوبارہ چلانا
    │
    ▼
کمٹ کے لیے تیار
    │
    ▼
[متفرق آٹومیشن] ─── کمٹ، PR وضاحت، ریلیز نوٹ لکھنا
    │
    ▼
کمٹ کریں، مکمل

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

دو کارآمد فیصلے کے معیار

اگر آپ کو یقین نہیں کہ کوئی کام Claude Code کو دینا چاہیے یا نہیں، تو اپنے آپ سے دو سوال پوچھیں:

1. کیا یہ کام 'مشینی' نوعیت کا 'تخلیقی' سے زیادہ ہے؟

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

2. کیا اس کام کی 'تصدیق کی لاگت' زیادہ ہے؟

اگر کسی تبدیلی کی تصدیق کے لیے بارہ بار سوئچ کرنا، ٹیسٹ چلانا، لاگ دیکھنا ضروری ہو، تو انسان کے لیے آزمائش اور غلطی سست ہوتی ہے۔ Claude Code خود 'تبدیل کرو-چلاؤ-دیکھو-دوبارہ تبدیل کرو' کے چکر کو مکمل کر سکتا ہے، جس سے آپ بہت آرام محسوس کریں گے۔