تبدیلیاں کرنے سے پہلے اپنے میراثی کوڈبیس کو سمجھنے کے لیے AI کا استعمال کیسے کریں۔

جب بہت سے انجینئرز میراثی کوڈ بیس کے وارث ہوتے ہیں، تو سب سے پہلے وہ کوڈ کو تبدیل کرنا چاہتے ہیں۔ اور میں اس جذبے کو سمجھتا ہوں۔

ایک کلاس کھولیں جو 1,500 لائنیں لمبی ہو۔ کاروباری اصولوں کے ساتھ ڈیٹا بیس کالز کی آمیزش ہے، کنفیگریشن کی قدریں ذخیروں میں بکھری ہوئی ہیں، ایسے طریقے جن کو کوئی چھونا نہیں چاہتا، اور تبصرے کا حوالہ دینے والے سسٹم جو برسوں پہلے غائب ہو گئے تھے۔

اس کے بعد AI کوڈنگ اسسٹنٹ آپ کو ہر چیز کی وضاحت کرنے کی پیشکش کرے گا۔

تو آپ پوچھتے ہیں:

براہ کرم اس کلاس کو ریفیکٹر کریں۔

لیکن یہ عام طور پر بہت جلد ہوتا ہے۔

میراثی نظاموں کے استعمال سے میں نے جو سبق سیکھے ہیں ان میں سے ایک یہ ہے کہ کوڈ بدصورت ہو سکتا ہے اور پھر بھی اہم معلومات پر مشتمل ہے۔

عجیب حالات کاروباری استثناء کا سبب بن سکتے ہیں۔ ڈپلیکیٹ حسابات موجود ہو سکتے ہیں کیونکہ دو بظاہر ایک جیسے عمل درحقیقت ایک جیسے نہیں ہیں۔ خوفناک نام والا ڈیٹا بیس کالم اب بھی بیرونی معاہدے کا حصہ ہو سکتا ہے۔

اور وہ طریقہ جس کو کوئی نہیں سمجھتا وہ آٹھ سال پہلے ہونے والے پروڈکشن حادثے کی تکرار کو روکنے کا واحد طریقہ ہو سکتا ہے۔

AI غیر مانوس سافٹ ویئر کو پڑھنے میں بہت آسان بناتا ہے، اور یہ قیمتی ہے۔ تاہم، سافٹ ویئر کو سمجھنے سے پہلے اسے تبدیل کرنا بہت آسان ہو جاتا ہے۔

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

آپ مدد کرنے کے لیے AI کا استعمال سیکھیں گے:

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

مثالیں TypeScript کا استعمال کرتی ہیں، لیکن یہ عمل زیادہ تر زبانوں اور ڈھیروں کے ساتھ کام کرے گا۔

مقصد یہ نہیں ہے کہ AI سے یہ پوچھے کہ کوڈ کا کیا مطلب ہے اور اس کے جواب پر بھروسہ کریں۔ مقصد یہ ہے کہ صحیح سوالات تلاش کرنے میں لگنے والے وقت کو کم کرنے کے لیے AI کا استعمال کیا جائے۔

شرائط

آپ کو اس کے ساتھ آرام دہ ہونا چاہئے:

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

ورک فلو ماڈل سے زیادہ اہم ہے، لہذا کسی مخصوص AI فراہم کنندہ کی ضرورت نہیں ہے۔

انڈیکس

ری فیکٹرنگ سے پہلے سمجھ کیوں آنی چاہیے۔

میراثی کوڈ اکثر عجلت کا غلط احساس پیدا کرتا ہے۔

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

مندرجہ ذیل خصوصیات پر غور کریں:

async function approveOrder(order: Order) {
  if (order.total > 10000 && !order.customer.verified) {
    throw new Error("Manual verification required");
  }

  if (
    order.customer.country === "AR" &&
    order.paymentMethod === "TRANSFER"
  ) {
    order.status = "PENDING";
  } else {
    order.status = "APPROVED";
  }

  await orders.save(order);

  if (order.status === "APPROVED") {
    await billing.createInvoice(order);
  }

  await audit.log({
    action: "ORDER_APPROVAL",
    orderId: order.id,
    status: order.status,
  });

  return order;
}

پہلی نظر میں، ریفیکٹرنگ کے کچھ واضح مواقع موجود ہیں۔

تصدیق نکالی جا سکتی ہے۔
ریاستی حسابات کو الگ کیا جا سکتا ہے۔
بلنگ کو انٹرفیس کے پچھلے حصے میں منتقل کیا جا سکتا ہے۔
آپ منظوری کی پالیسیاں بنا سکتے ہیں۔

یہ خیالات سب سمجھ میں آسکتے ہیں، لیکن ایسے سوالات ہیں جن کا جواب پہلے دینے کی ضرورت ہے۔

کیوں 10000 اہم؟
میرا ارجنٹائن بینک ٹرانسفر کیوں ہولڈ پر ہے؟
کیا استقامت کے بعد رسید کی تخلیق ہونی چاہیے؟
ہے ORDER_APPROVAL کیا یہ کسی اور نظام کے ذریعہ استعمال ہوتا ہے؟
کیا میرا آرڈر اس سے تبدیل کیا جا سکتا ہے: PENDING کو APPROVED کہیں اور؟
کیا کچھ بھی مستثنیٰ پیغام پر منحصر ہے؟

اکیلا نحو ہی ان سوالوں کا جواب نہیں دے سکتا۔

یہیں سے تفہیم شروع ہوتی ہے۔

AI ٹولز سے سوالات پوچھنے کے بجائے:

Refactor this function using clean architecture.

کے ساتھ شروع کریں:

Analyze this function without changing it.

Identify:

1. explicit business rules,
2. likely business rules that need confirmation,
3. side effects,
4. external dependencies,
5. state transitions,
6. magic values,
7. assumptions that cannot be proven from this file alone.

Do not propose a refactor yet.

آخری لائن اہم ہے۔ براہ کرم ابھی ری فیکٹرنگ کا مشورہ نہ دیں۔

میں تحقیقاتی موڈ میں ماڈل چاہتا ہوں، حل موڈ میں نہیں۔

کلاس کے بجائے ریپوزٹری سے کیسے شروع کریں۔

جب آپ کسی غیر مانوس میراثی نظام تک رسائی حاصل کرتے ہیں، تو آپ ہر فائل کو پڑھ کر شروع نہیں کرتے ہیں۔ سب سے پہلے، یہ سمجھنے کی کوشش کریں کہ آپ کی درخواست کیسی دکھتی ہے۔

مخزن میں پہلے سے ہی آرکیٹیکچرل اشارے موجود ہیں۔

اس طرح کی ڈائریکٹری تلاش کریں:

src/
controllers/
services/
repositories/
models/
jobs/
workers/
scripts/
migrations/
config/
integrations/
tests/

تاہم، یہ نہ سمجھیں کہ ڈائریکٹری کے نام اصل فن تعمیر کو بیان کرتے ہیں۔

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

ایک ڈائریکٹری کہا جاتا ہے models ڈیٹا بیس کے ایسے اداروں پر مشتمل ہو سکتا ہے جو ڈومین ماڈل نہیں ہیں۔

ایک فولڈر کہا جاتا ہے۔ utils آپ اپنی درخواست کی کاروباری منطق کا نصف چھپا سکتے ہیں۔

ساخت کو ثبوت کے طور پر استعمال کریں، سچ نہیں۔

ایک مفید پہلی AI درخواست یہ ہوگی:

Inspect the repository structure.

Do not analyze individual implementation details yet.

Identify:

- application entry points,
- major modules,
- database technologies,
- external integrations,
- background processing,
- scheduled tasks,
- authentication mechanisms,
- configuration sources,
- tests,
- likely architectural boundaries.

For each conclusion, reference the files or directories
that support it.

Mark anything uncertain explicitly.

حوالہ فائلوں کی ضرورت اہم ہے۔ اس کے بغیر، AI بالکل معقول فن تعمیر فراہم کر سکتا ہے جو حقیقت میں موجود نہیں ہے۔

آپ کچھ اس کے قریب چاہتے ہیں:

HTTP API
Evidence:
- src/server.ts
- src/routes/orders.ts
- src/routes/customers.ts

Background processing
Evidence:
- src/workers/paymentWorker.ts
- src/queues/index.ts

Scheduled jobs
Evidence:
- src/jobs/reconcileInvoices.ts
- src/cron.ts

اب آپ کے پاس ایک نقشہ ہے جسے آپ چیک کر سکتے ہیں۔

اصل انٹری پوائنٹ کو کیسے تلاش کریں۔

ویب ایپلیکیشنز میں اکثر ایک واضح HTTP انٹری پوائنٹ ہوتا ہے۔ لیکن میراثی نظاموں میں اکثر پیش کرنے کے لیے بہت کچھ ہوتا ہے۔

کاروباری کاروائیاں اس طرح شروع ہو سکتی ہیں:

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

فرض کریں کہ آپ تخلیق آرڈر تلاش کرتے ہیں اور درج ذیل کو تلاش کرتے ہیں:

POST /orders

یہ سمجھنا آسان ہے کہ تمام آرڈرز اس اینڈ پوائنٹ کے ذریعے داخل کیے گئے ہیں۔

پھر آپ دریافت کریں:

jobs/importMarketplaceOrders.ts
workers/retryFailedOrders.ts
scripts/migratePendingOrders.ts
integrations/shopify/webhook.ts

اب ایک ہی کاروباری آبجیکٹ میں چار اضافی آئٹم راستے ہیں۔

یہ ری فیکٹرنگ کے بارے میں ہمارے سوچنے کے انداز کو بدل دیتا ہے۔

AI سے پوچھیں:

Find every location that can create, modify,
approve, cancel, or persist an Order.

Include:

- HTTP endpoints,
- background workers,
- scheduled jobs,
- scripts,
- imports,
- webhooks,
- direct repository calls.

Group the results by operation.

For every result, include the file path and
the relevant function or class.

پھر نتائج دیکھنے کے لیے ذخیرہ تلاش کریں۔

مثال کے طور پر:

rg "orders\.save|orders\.insert|createOrder|approveOrder" src

AI کو تلاش کو تیز کرنا چاہئے، اسے تبدیل نہیں کرنا چاہئے۔

اپنے کوڈ بیس کے ذریعے کاروباری صلاحیتوں کو کیسے ٹریک کریں۔

انفرادی فائلوں کو سمجھنا کافی نہیں ہے۔

جو عام طور پر اہم ہے وہ ہے۔ کاروباری صلاحیت.

مثال کے طور پر:

ایک آرڈر بنائیں۔

یہ فعالیت ایک سے زیادہ تہوں سے گزر سکتی ہے۔

HTTP Request
     ↓
Controller
     ↓
Application Service
     ↓
Pricing
     ↓
Inventory
     ↓
Persistence
     ↓
Payment
     ↓
Notification

ہو سکتا ہے آپ کا کوڈ صاف ستھرا منظم نہ ہو، یہی وجہ ہے کہ فیچر ٹریسنگ مفید ہے۔

ایک حقیقی زندگی کا ورک فلو چنیں اور پوچھیں:

Trace the "Create Order" capability from its entry point
until all observable side effects are complete.

For each step, show:

- file,
- function or class,
- input,
- output,
- state change,
- external call,
- error behavior.

Do not summarize multiple steps into one.

ہم ایک ایسا سلسلہ چاہتے ہیں جس کا معائنہ کیا جا سکے۔

مثال کے طور پر:

1. POST /orders
   src/routes/orders.ts

2. OrdersController.create()
   src/controllers/OrdersController.ts

3. OrderService.create()
   src/services/OrderService.ts

4. calculatePrice()
   src/services/pricing.ts

5. inventory.reserve()
   src/integrations/inventory.ts

6. ordersRepository.save()
   src/repositories/orders.ts

7. paymentQueue.publish()
   src/queues/payment.ts

یہ فن تعمیر کی عمومی وضاحت سے کہیں زیادہ مفید ہے۔

اب آپ سوالات پوچھ سکتے ہیں جیسے:

لین دین اصل میں کہاں سے شروع ہوتا ہے؟
اگر ادائیگی کی پوسٹنگ ناکام ہو جاتی ہے تو کیا ہوتا ہے؟
کیا انوینٹری کے تحفظات کو تبدیل کیا جا سکتا ہے؟
کیا میں ایک آرڈر کو دو بار بچا سکتا ہوں؟
کون سے مراحل ہم آہنگ ہیں؟
کن ناکامیوں کی دوبارہ کوشش کی جاتی ہے؟

یہ جدیدیت کا سوال ہے۔

بنیادی ڈھانچے سے کاروباری قواعد کو کیسے الگ کیا جائے۔

کوڈبیس آرکیالوجی کے دوران آپ جو سب سے زیادہ کارآمد چیزیں کر سکتے ہیں ان میں سے ایک یہ شناخت کرنا ہے کہ کاروباری رویہ کہاں رہتا ہے۔

روایتی ایپلی کیشنز اکثر اسے بنیادی ڈھانچے کے ساتھ ملا دیتے ہیں۔

غور کریں:

async function saveCustomer(customer: Customer) {
  if (
    customer.type === "ENTERPRISE" &&
    customer.creditLimit < 50000
  ) {
    throw new Error("Invalid enterprise credit limit");
  }

  const connection = await mysql.getConnection();

  await connection.query(
    "INSERT INTO customers (...) VALUES (...)",
    [...]
  );

  await redis.del(`customer:${customer.id}`);

  await eventBus.publish(
    "customer.updated",
    customer
  );
}

کم از کم ایک کاروباری اصول ہے۔

Enterprise customers must have a credit limit >= 50000.

اور کچھ بنیادی ڈھانچے کے مسائل:

MySQL
Redis
Event bus

AI سے اپنے کوڈ کی درجہ بندی کرنے کو کہیں۔

Classify each responsibility in this function as one of:

- business rule,
- application orchestration,
- persistence,
- caching,
- messaging,
- logging,
- validation,
- unknown.

Explain why.

Do not move or rewrite any code.

کہ unknown زمرے مفید ہیں۔ آپ نہیں چاہتے کہ آپ کا ماڈل ہر لائن کو صاف ستھرے آرکیٹیکچرل تھیوری پر مجبور کرے۔

کچھ کوڈ واقعی مبہم ہیں جب تک کہ مزید سیاق و سباق کی جانچ نہ کی جائے۔

پوشیدہ سائیڈ ایفیکٹس کو کیسے تلاش کریں۔

ضمنی اثرات نقل مکانی کے خطرے کی سب سے بڑی وجوہات میں سے ایک ہیں۔

مندرجہ ذیل فنکشن کو کہا جاتا ہے:

updateCustomer()

آپ اپنے گاہکوں کو اپ ڈیٹ کرنے سے کہیں زیادہ کر سکتے ہیں۔

درج ذیل ہو سکتے ہیں:

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

کسی فنکشن کو ری فیکٹر کر کے اور صرف اس کی واپسی کی قیمت کو محفوظ رکھ کر، آپ کمپائلر کی غلطیوں کے بغیر پروڈکشن رویے کو توڑ سکتے ہیں۔

کچھ مفید تحقیقی اشارے میں شامل ہیں:

List every observable side effect produced directly
or indirectly by this function.

For each one, identify:

- the side effect,
- where it happens,
- whether it is synchronous or asynchronous,
- whether failure propagates,
- whether it appears retryable,
- whether it is idempotent,
- whether it can be safely repeated.

Mark uncertain answers as unknown.

آخری جائیداد، idempotency، بہت اہم ہے.

فرض کریں کہ ایک کارکن مندرجہ ذیل کام کرتا ہے:

await chargeCard(order);
await markOrderAsPaid(order);

اگر کوئی کارکن دو لائنوں کے درمیان کریش ہو جائے اور دوبارہ کوشش کرے تو کیا ہوتا ہے؟ آپ اپنے صارفین کو دو بار بل کر سکتے ہیں۔ اور یہ فنکشن کے نام میں نظر نہیں آتا۔

دوبارہ کوشش کرنے کے الفاظ کو سمجھنا آپ کے کوڈ بیس کو سمجھنے کا حصہ ہے۔

مضمر معاہدوں کو کیسے دریافت کریں۔

تمام معاہدوں کو انٹرفیس کے طور پر قرار نہیں دیا جاتا ہے۔ میراثی ایپلی کیشنز میں بہت سے مضمر معاہدے ہوتے ہیں۔

مثال کے طور پر:

return {
  status: "ok",
  value: customer.balance.toFixed(2),
};

کچھ بیرونی صارفین اس پر بھروسہ کر سکتے ہیں:

{
  "status": "ok",
  "value": "100.00"
}

تبدیل کرنا value تاروں سے اعداد میں تبدیلی ایک بہتری کی طرح لگ سکتی ہے۔

{
  "status": "ok",
  "value": 100
}

اس سے کلائنٹ کریش ہو سکتا ہے۔

ذیل میں معاہدہ تلاش کریں:

API کا جواب،
واقعہ،
ڈیٹا بیس کی ساخت،
CSV برآمد،
فائل کا نام،
ماحولیاتی متغیرات،
غلطی کا پیغام،
قطار پے لوڈ،
اور ویب ہک باڈی۔

پوچھیں:

Identify outputs from this module that could be consumed
outside the module.

Include:

- HTTP responses,
- emitted events,
- queue messages,
- files,
- database records,
- exceptions,
- logs used for automated processing.

For each output, explain what evidence suggests that it
may be an external or implicit contract.

نمائندگی اہم ہے:

ثبوت کیا تجویز کرتا ہے۔

نہیں:

مجھے بتائیں کہ معاہدہ کیا ہے؟

اس کی وجہ یہ ہے کہ موجودہ ذخیرہ صارف کو تصدیق کرنے کے قابل نہیں ہوسکتا ہے۔

ڈپلیکیٹ کاروباری قواعد تلاش کرنے کے لیے AI کا استعمال کیسے کریں۔

ڈپلیکیٹ کوڈ کا پتہ لگانا آسان ہے۔ ڈپلیکیٹ کاروباری مضمرات یہ زیادہ مشکل ہے۔

آپ تلاش کر سکتے ہیں:

if (customer.type === "PREMIUM") {
  discount = total * 0.1;
}

ایک ماڈیول میں۔

اور دوسری جگہ:

if (account.plan === "GOLD") {
  price = price * 0.9;
}

یہ ایک ہی کاروباری اصول کی نمائندگی کر سکتے ہیں یا نہیں کر سکتے ہیں۔

AI امیدواروں کی شناخت میں مفید ہے۔

پوچھیں:

Search the repository for business rules related to
customer discounts.

Group implementations that appear semantically related,
even if variable names differ.

For each group:

- list file locations,
- describe the apparent rule,
- highlight differences,
- do not assume the rules should be unified.

آخری ہدایت اہم ہے۔

نقل بعض اوقات حادثاتی ہوتی ہے۔

بعض اوقات وہ دو شعبوں کی نمائندگی کرتے ہیں جو آزادانہ طور پر تیار ہوئے ہیں۔

اپنے AI اسسٹنٹ کو گھومنے سے روکیں:

similar

میں:

must be merged

بغیر ثبوت کے۔

ہلکا پھلکا انحصار کا نقشہ کیسے بنایا جائے۔

کسی وقت، آپ کو یہ سمجھنے کی ضرورت ہے کہ سسٹم کے کون سے حصے دوسرے حصوں پر منحصر ہیں۔

آپ کو ایک مکمل انٹرپرائز آرکیٹیکچر ڈایاگرام کی ضرورت نہیں ہے۔ ہلکے وزن کے انحصار کے نقشے سے شروع کرنا کافی ہے۔

مثال کے طور پر:

Orders
 ├── Customers
 ├── Inventory
 ├── Payments
 ├── Notifications
 └── Database

Payments
 ├── Payment Provider
 ├── Audit
 └── Database

AI سے ماڈیول کی سطح پر انحصار نکالنے کو کہیں۔

Build a module dependency map from the repository.

Only include dependencies supported by imports,
constructor dependencies, explicit calls, or configuration.

Output:

Module A -> Module B

For each dependency, provide at least one source file
that demonstrates it.

Do not infer dependencies from names alone.

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

JavaScript یا TypeScript پروجیکٹس کے لیے، انحصاری تجزیہ کا آلہ آپ کو تلاش کرنے میں مدد کر سکتا ہے:

سرکلر انحصار
کراس ماڈیول درآمد
اعلی پرستار
اعلی پرستار

AI یہ بتانے میں مفید ہے کہ یہ انحصار کیوں اہم ہیں۔ جامد تجزیہ وجود کو ثابت کرنے میں بہتر ہے۔

دونوں استعمال کریں۔

جس چیز کو آپ ابھی تک نہیں سمجھتے اسے کیسے نشان زد کریں۔

یہ عمل کے سب سے اہم حصوں میں سے ایک ہے۔

ایک مفید نظام کا نقشہ صرف جوابات سے زیادہ پر مشتمل ہے۔ اس میں غیر یقینی صورتحال بھی شامل ہے۔

میں اس طرح کی ایک واضح فہرست رکھنا پسند کرتا ہوں:

## Open Questions

- Why is the enterprise credit threshold 50,000?
- Is `ORDER_APPROVAL` consumed outside this repository?
- Can marketplace orders bypass inventory validation?
- Is `customer.balance` allowed to be negative?
- What process transitions PENDING orders to APPROVED?
- Is `legacy_customer_id` still used by another system?

آپ AI سے یہ فہرست تیار کرنے کے لیے کہہ سکتے ہیں۔

Based on everything analyzed so far, list the questions
that can't be answered safely from the repository.

Focus on questions that would matter during:

- refactoring,
- migration,
- schema changes,
- interface changes,
- removal of code.

Do not answer the questions.

مجھے یہ پرامپٹ پسند ہے کیونکہ یہ اس کے برعکس کرتا ہے جو ہم عام طور پر AI سے کرنے کو کہتے ہیں۔ ماڈل سے مقام کی نشاندہی کرنے کو کہیں۔ ~ نہیں دکھاوا کرو تم جانتے ہو۔

جدید کاری کے منصوبوں میں یہ نامعلوم شامل ہونا ضروری ہے۔

اپنے سسٹم کے خلاف AI نتائج کی توثیق کیسے کریں۔

AI سے تیار کردہ وضاحتیں قائل کرنے والی لگ سکتی ہیں چاہے وہ نامکمل ہوں۔ لہٰذا، ہر اہم دریافت کا ثبوت کا دوسرا ذریعہ ہونا چاہیے۔

میں ایک سادہ درجہ بندی کا استعمال کرتا ہوں۔

مخزن کی تلاش

اگر AI کہتا ہے کہ ایک فنکشن صرف ایک بار بلایا جائے گا، تو اس فنکشن کو تلاش کریں۔

rg "approveOrder" .

ٹیسٹ

ٹیسٹ اکثر ایسے مفروضوں کو ظاہر کرتے ہیں جن کا نفاذ کوڈ کا حساب نہیں ہے۔

تلاش کریں:

expected errors
special values
boundary cases
fixture data
historical behavior

ڈیٹا بیس سکیما

اسکیماس اہم نکات کو ظاہر کر سکتے ہیں جیسے:

nullable فیلڈ
غیر ملکی کلید
پہلے سے طے شدہ
میراثی کالم
فارماسیوٹیکل
حیثیت کی قدر

نوشتہ جات اور مشاہدہ

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

ورژن کی تاریخ

گٹ ہسٹری بعض اوقات ایسے سوالوں کے جواب دے سکتی ہے جو سورس کوڈ نہیں دے سکتے۔

مثال کے طور پر:

git log -S "Manual verification required" --all

یا:

git blame src/orders/approveOrder.ts

وہ عہد جس کے نتیجے میں عجیب حالت پیدا ہوئی اس میں وضاحت ہوسکتی ہے۔

وہ علاقے جہاں AI تاریخ کا خلاصہ کرنے میں مدد کر سکتا ہے ان میں شامل ہیں:

Review the commits that changed this function.

Build a timeline of behavior changes.

For each change, include:

- commit,
- date,
- behavior changed,
- stated reason if available.

Do not infer a reason if the commit history does not provide one.

اس سے آپ کا ناقابل یقین وقت بچ جائے گا۔

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

ایک بار جب آپ ایک خصوصیت کو سمجھ لیں تو آپ فیصلہ کر سکتے ہیں۔ لیکن پہلے ایسا نہیں تھا۔

فرض کریں کہ آپ کی تحقیقات سے درج ذیل نتائج برآمد ہوتے ہیں:

Create Order

Business rules:
- active customer required
- premium customers receive 10% discount
- inventory must be available

Side effects:
- order persisted
- inventory reserved
- payment queued
- confirmation email sent

External contracts:
- POST /orders response
- payment queue payload
- order.created event

Unknowns:
- retry semantics for inventory reservation
- whether event consumers require exact field names

اب آپ فیصلہ کر سکتے ہیں کہ کس چیز کی حفاظت کرنی ہے۔

مثال کے طور پر:

Protect first:
- pricing behavior
- API response
- payment payload
- event schema

پھر فیصلہ کریں کہ کیا ری فیکٹر کیا جا سکتا ہے۔

Candidate boundaries:
- pricing policy
- inventory gateway
- payment publisher
- notification service

پھر فیصلہ کریں کہ کس چیز کی تحقیقات کی ضرورت ہے۔

Block migration until understood:
- inventory retry behavior
- event consumers

یہ پہلے سے ہی ہجرت کا منصوبہ ہے۔

AI کیا نہیں کرتا اس پر توجہ دیں۔ میں نے ٹارگٹ فن تعمیر کا فیصلہ نہیں کیا ہے۔

اس سے موجودہ فن تعمیر کو فیصلے کرنے کے لیے کافی قابل مشاہدہ بنانے میں مدد ملی۔

عملی کوڈبیس آرکیالوجی ورک فلو

اگر آپ کو اس عمل کو دہرانے کے قابل عمل میں کم کرنے کی ضرورت ہے تو درج ذیل اقدامات استعمال کریں:

1. ریپوزٹری میپنگ

شناخت کریں:

داخلہ پوائنٹ
ماڈیول
استقامت
انضمام
کارکن
نوکری
ٹیسٹ
مرکب

کسی بھی چیز کو ری فیکٹر نہ کریں۔

2. ایک خصوصیت کا انتخاب کریں۔

براہ کرم مخصوص تفصیلات منتخب کریں۔

Create Order
Approve Loan
Generate Invoice
Register Customer
Cancel Subscription

ایک ساتھ پوری پروڈکٹ کو سمجھنے کی کوشش نہ کریں۔

3. آخر تک عمل کریں۔

پیروی کریں:

input
↓
business logic
↓
state changes
↓
external calls
↓
output

تمام متعلقہ فائلوں کو ریکارڈ کریں۔

الگ کیا گیا:

واضح قوانین
ممکنہ حکمرانی
بنیادی ڈھانچے کے رویے
نامعلوم

5. ضمنی اثرات کی جانچ کریں۔

تلاش کریں:

لکھنا
پیغام
ای میل
نوکری
کیشے کو تبدیل کریں
بیرونی کرنسی

6. معاہدہ دریافت

تلاش کریں:

apis
ایونٹ سکیما
ڈیٹا بیس مفروضے۔
برآمد فائل
غلطی کا رویہ

7. نقشہ پر انحصار

دستاویز:

module -> module

اور جوڑے کی شناخت کریں۔

8. نامعلوم ریکارڈ

اپنی بے یقینی کو مت چھپائیں۔ ایک واضح فہرست بنائیں۔

9. تصدیق کریں۔

استعمال کریں:

مخزن کی تلاش
ٹیسٹ
خاکہ
لاگ
گٹ ہسٹری
پیداوار ٹیلی میٹری

10. تب ہی منصوبہ بندی کی تبدیلی

فیصلہ کریں:

کن اعمال کو زندہ رہنا چاہیے؛
کون سا کوڈ غائب ہو سکتا ہے،
کن حدود کو متعارف کرایا جانا چاہئے؛
ٹیسٹ کرنے کی کیا ضرورت ہے،
آپ سب سے پہلے کیا منتقل کر سکتے ہیں

پہلے AI سے مت پوچھیں۔

میراثی ماڈرنائزیشن کے منصوبے پر کام شروع کرنے سے بچنے کے لیے کئی پیغامات ہیں۔

مثال کے طور پر:

Rewrite this application using Clean Architecture.

یا:

Convert this monolith into microservices.

یا:

Modernize this entire repository.

یا یہاں تک کہ:

Find all the bad code.

مسئلہ یہ نہیں ہے کہ AI ان اشارے سے کارآمد آؤٹ پٹ پیدا نہیں کر سکتا۔ ایسا ہو سکتا ہے۔

مسئلہ یہ ہے کہ ان سوالات کا حل پہلے سے موجود ہے۔

آپ پوچھ رہے ہیں:

Clean Architecture
Microservices
Rewrite
Bad code

اس سے پہلے کہ نظام کو واقعی کیا ضرورت ہے۔

ایک بہتر حکم یہ ہوگا:

What exists?
↓
Why does it exist?
↓
What behavior matters?
↓
What is uncertain?
↓
What should change?

یہ ترتیب پہلے گھنٹے کے لیے سست ہے، لیکن عام طور پر باقی پروجیکٹ کے لیے بہت تیز ہوتی ہے۔

سب سے زیادہ مفید AI نتائج بعض اوقات سوالات ہوتے ہیں۔

AI کوڈنگ ٹولز کو ان کے تیار کردہ کوڈ کی مقدار سے جانچنے کا رجحان ہے۔

مجھے لگتا ہے کہ آپ میراثی نظام کے ساتھ کچھ قدر سے محروم ہیں۔

سب سے زیادہ مفید نتائج میں سے ایک ہے:

دستیاب کوڈ سے یہ تعین کرنا ممکن نہیں کہ یہ حالت کیوں موجود ہے۔

یا:

ایسا لگتا ہے کہ اس ایونٹ کا موجودہ اسٹور میں کوئی صارف نہیں ہے، لیکن بیرونی صارفین کو مسترد نہیں کیا جا سکتا۔

یا:

اگرچہ یہ دونوں رعایتی حسابات ایک جیسے نظر آتے ہیں، لیکن 0 کی قدر والے آرڈرز کے لیے ان کا برتاؤ مختلف ہے۔

یہ ایک مفید تلاش ہے جو انجینئرز کو بتاتی ہے کہ کہاں تفتیش کرنی ہے۔

ایک پر اعتماد لیکن غلط جواب بہت زیادہ خطرناک ہے۔

میراثی نظام کے ساتھ کام کرتے وقت، غیر یقینی صورتحال معلومات ہوتی ہے۔ ایسے ہی سنبھالو۔

نتیجہ

AI غیر مانوس کوڈ بیسز کو نیویگیٹ کرنا بہت آسان بنا دیتا ہے۔

آپ اسے ماڈیولز کا خلاصہ کرنے، عملدرآمد کے راستوں کا پتہ لگانے، امیدواروں کے کاروباری اصولوں کو نکالنے، ضمنی اثرات تلاش کرنے، نفاذ کا موازنہ کرنے، Git کی تاریخ کا تجزیہ کرنے، اور انحصار کے نقشے بنانے کے لیے استعمال کر سکتے ہیں۔

یہ مکینیکل سروے کے کام کی ایک بڑی مقدار کو ختم کر سکتا ہے۔

تاہم، کسی نظام کو سمجھنا اس کی تفصیل پیدا کرنے جیسا نہیں ہے۔ میراثی ایپلیکیشنز میں ایسا سیاق و سباق ہوتا ہے جو ماخذ کوڈ سے باہر موجود ہو سکتا ہے۔

پیداواری رویہ،
پرانا واقعہ
بیرونی صارف،
کاروباری استثناء،
غیر دستاویزی انضمام؛
اور تنظیم کی تاریخ۔

AI ثبوت تلاش کرنے میں آپ کی مدد کر سکتا ہے۔ گمشدہ تاریخ نہیں بنائی جا سکتی۔

اس لیے میں اسے ٹرانسفارمر کے طور پر استعمال کرنے سے پہلے بطور تفتیش کار استعمال کرنے کو ترجیح دیتا ہوں۔

کے ساتھ شروع کریں:

What does this system actually do?

پھر سوال پوچھیں۔

What do I still not understand?

تب ہی آپ کو پوچھنا چاہئے:

What should I change?

AI کے ذریعے جتنی تیزی سے سافٹ ویئر میں ترمیم کی جا سکتی ہے، یہ ترتیب اتنی ہی اہم ہو جاتی ہے۔

کیونکہ کوڈ کو تبدیل کرنا آپ سمجھتے ہیں انجینئرنگ ہے۔ لیکن کوڈ کو تبدیل کرنا جو آپ نہیں سمجھتے ہیں وہ تجربہ ہے۔

اور اس تجربے کو چلانے کے لیے پیداوار عام طور پر سب سے مہنگی جگہ ہوتی ہے۔

شرائط

انڈیکس

ری فیکٹرنگ سے پہلے سمجھ کیوں آنی چاہیے۔

کلاس کے بجائے ریپوزٹری سے کیسے شروع کریں۔

اصل انٹری پوائنٹ کو کیسے تلاش کریں۔

اپنے کوڈ بیس کے ذریعے کاروباری صلاحیتوں کو کیسے ٹریک کریں۔

بنیادی ڈھانچے سے کاروباری قواعد کو کیسے الگ کیا جائے۔

پوشیدہ سائیڈ ایفیکٹس کو کیسے تلاش کریں۔

مضمر معاہدوں کو کیسے دریافت کریں۔

ڈپلیکیٹ کاروباری قواعد تلاش کرنے کے لیے AI کا استعمال کیسے کریں۔

ہلکا پھلکا انحصار کا نقشہ کیسے بنایا جائے۔

جس چیز کو آپ ابھی تک نہیں سمجھتے اسے کیسے نشان زد کریں۔

اپنے سسٹم کے خلاف AI نتائج کی توثیق کیسے کریں۔

مخزن کی تلاش

ٹیسٹ

ڈیٹا بیس سکیما

نوشتہ جات اور مشاہدہ

ورژن کی تاریخ

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

عملی کوڈبیس آرکیالوجی ورک فلو

1. ریپوزٹری میپنگ

2. ایک خصوصیت کا انتخاب کریں۔

3. آخر تک عمل کریں۔

5. ضمنی اثرات کی جانچ کریں۔

6. معاہدہ دریافت

7. نقشہ پر انحصار

8. نامعلوم ریکارڈ

9. تصدیق کریں۔

10. تب ہی منصوبہ بندی کی تبدیلی

پہلے AI سے مت پوچھیں۔

سب سے زیادہ مفید AI نتائج بعض اوقات سوالات ہوتے ہیں۔

نتیجہ

متعلقہ پوسٹس