دوبارہ لکھنے کی طرف رجوع کیے بغیر AI کے ساتھ میراثی ایپلی کیشنز کو جدید کیسے بنایا جائے۔

میں نے میراثی ہجرت کو کامیاب سمجھا ہے کیونکہ پرانا فریم ورک ذخیرہ خانوں سے غائب ہو گیا ہے۔

چھ ماہ بعد، ٹیم اب بھی وہی جوڑے، وہی غیر واضح کاروباری قواعد، اور تقریباً وہی تعیناتی کے مسائل سے نمٹ رہی تھی۔

اگرچہ ٹیکنالوجی بدل گئی ہے، لیکن مجموعی طور پر نظام زیادہ نہیں بدلا ہے۔

AI اس مسئلے کو مزید دلچسپ بنا دیتا ہے۔

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

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

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

اس ٹیوٹوریل میں، میں آپ کو میراثی منتقلی کے دوران AI استعمال کرنے کا ایک اور طریقہ دکھانا چاہتا ہوں۔

AI کو خودکار کوڈ مترجم کے طور پر علاج کرنے کے بجائے، آپ AI کو اس کے لیے استعمال کر سکتے ہیں:

• غیر مانوس کوڈ اڈوں کو سمجھیں،

• کاروباری قوانین اور پوشیدہ انحصار کی شناخت کریں،

• طرز عمل کی حفاظت کا جال قائم کریں،

• بڑھتی ہوئی نقل مکانی کی حدود تلاش کرنا،

• تبدیل کرنے سے پہلے ریفیکٹر،

• دہرائی جانے والی تبادلوں کو خودکار بنائیں،

• پرانے اور نئے اعمال کا موازنہ کریں،

• پیداوار تک پہنچنے سے پہلے رجعت کا پتہ لگائیں۔

اگرچہ مثالیں TypeScript کا استعمال کرتی ہیں، لیکن عمل خود TypeScript یا Node.js سے منسلک نہیں ہے۔

اہم حصہ ورک فلو ہے۔ AI منتقلی کے کام تیزی سے انجام دے سکتا ہے۔ تاہم، انجینئرنگ ٹیموں کو اب بھی یہ فیصلہ کرنے کی ضرورت ہے کہ منتقلی کے قابل کیا ہے۔

شرطیں

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

• بنیادی ٹائپ اسکرپٹ،

• یونٹ اور انضمام کی جانچ؛

• انحصار انجکشن،

• سافٹ ویئر آرکیٹیکچر کے تصورات،

• موجودہ کوڈ بیس کے ساتھ کام کریں۔

مثالیں Vitest کا استعمال کرتی ہیں، لیکن اگر آپ Jest یا دوسرے ٹیسٹنگ فریم ورک کا استعمال کرتے ہیں تو وہی خیالات لاگو ہوتے ہیں۔

انڈیکس

ون ٹو ون میراثی ہجرت سے کیسے بچیں۔

اپنے پرانے آرڈر پروسیسنگ سسٹم میں اس خصوصیت کو تلاش کرنے کا تصور کریں۔

async function processOrder(order: Order) {
  if (!order.customer.active) {
    throw new Error("Inactive customer");
  }

  const discount =
    order.customer.type === "PREMIUM"
      ? order.total * 0.1
      : 0;

  const finalAmount = order.total - discount;

  await db.orders.insert({
    customerId: order.customer.id,
    amount: finalAmount,
  });

  await paymentGateway.charge(
    order.customer.card,
    finalAmount,
  );

  await mailer.send(
    order.customer.email,
    "Order processed",
  );

  return finalAmount;
}

یہ خصوصیت کام کرتی ہے، لیکن یہ کافی حد تک کام کرتی ہے۔

صارفین کی تصدیق کریں، قیمتوں کے اصولوں کا اطلاق کریں، ڈیٹا کو برقرار رکھیں، ادائیگی کے طریقے چارج کریں، اور اطلاعات بھیجیں۔

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

آپ موجودہ کنٹرولر کو نئے کنٹرولر سے، موجودہ سروس کو نئی سروس کے ساتھ، یا موجودہ ORM کو نئے ORM کے ساتھ تبدیل کر سکتے ہیں اور پھر بھی وہی آرکیٹیکچرل مسائل ہیں۔

یہ پہلی جگہوں میں سے ایک ہے جہاں AI آپ کے خلاف کام کر سکتا ہے۔

اگر اشارہ ہے:

Convert this legacy class to TypeScript.

ماڈل عام طور پر اپنی ساخت کو محفوظ رکھتے ہیں۔ کیونکہ ڈھانچے کو بچانا آپ کا کام ہے۔

AI سے اپنے کوڈ کا ترجمہ کرنے کو کہنے سے پہلے، دو سوالوں میں فرق کریں:

1. کون سے اعمال کو زندہ رہنا چاہیے؟

2. کون سے ڈیزائن کو زندہ رہنا چاہئے؟

وہ ایک ہی سوال نہیں ہیں۔

کبھی کبھی عمل درآمد پرانا ہوتا ہے، لیکن طرز عمل اب بھی ضروری ہے۔ بعض اوقات رویہ اہم ہوتا ہے لیکن عمل درآمد کرنا پڑتا ہے۔ اور کبھی کبھی وہ دریافت کرتے ہیں کہ نہ تو زندہ رہنے کی ضرورت ہے۔

بڑے پیمانے پر ہجرت شروع ہونے سے پہلے یہ فرق کرنا ضروری ہے۔

تبدیلیاں کرنے سے پہلے میراثی کوڈبیس کا نقشہ کیسے بنائیں

میراثی منتقلی کا پہلا مشکل حصہ عام طور پر یہ سمجھنا ہوتا ہے کہ آپ کے پاس اصل میں کیا ہے۔

دستاویزات کا ہونا مفید ہوگا۔ تاہم، بہت سے نظاموں میں اصل دستاویزات کو تقسیم کیا جاتا ہے:

یہ ایک ایسا علاقہ ہے جہاں AI تعمیراتی فیصلے کیے بغیر وقت بچا سکتا ہے۔

پچھلے کو لے لو۔ processOrder فنکشن AI کو دوبارہ لکھنے کے لیے کہنے کے بجائے، سوالات پوچھ کر شروع کریں جیسے:

Identify the business rules in this function.

List every side effect.

Which external systems does it depend on?

Which parts could be expressed as pure functions?

Which observable behaviors should probably be protected
with tests before this function is changed?

Do not rewrite the function.

آخری ہدایت آپ کے خیال سے کہیں زیادہ اہم ہے۔

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

میں پہلے واضح طور پر تجزیہ کرنے کو ترجیح دیتا ہوں۔

بڑے کوڈ بیسز کے لیے، ہم اس عمل کو متعدد سطحوں پر دہراتے ہیں۔

ذخیرہ کی سطح پر، تلاش کریں:

• داخلی مقام،

• ڈیٹا بیس تک رسائی،

• بیرونی API،

• پیغام کی دم،

• پس منظر کے کام،

• طے شدہ کام،

• ترکیب،

• مشترکہ ریاست،

• ثبوت

• اور منظور کرلیا۔

ماڈیول کی سطح پر تلاش کریں:

• کاروباری قوانین،

• انحصار،

• ضمنی اثرات،

• بے کار منطق،

• انتہائی مربوط کلاسز؛

• اور مضمر معاہدے۔

خصوصیت کی سطح پر، تلاش کریں:

• ان پٹ

• بجلی کی پیداوار،

• استثناء،

• ریاست کی تبدیلی،

• بیرونی کرنسی،

• اور ایج کیسز۔

AI اس ایکسپلوریشن کو بہت تیز تر بنا سکتا ہے۔ تاہم، نتائج کو اصل ذخیروں، ٹیسٹوں، اسکیموں، نوشتہ جات، اور پیداواری رویے کے خلاف چیک کیا جانا چاہیے۔

آپ کے کوڈ کی پراعتماد تفصیل اب بھی صرف ایک تفصیل ہے۔ ذخیرہ معلومات کا ذریعہ رہتا ہے۔

ری فیکٹرنگ سے پہلے خصوصیت کے ٹیسٹ کیسے بنائیں

میراثی سافٹ ویئر کے مایوس کن حصوں میں سے ایک یہ ہے کہ عجیب سلوک ضروری نہیں کہ حادثاتی ہو۔

آپ کو ایسا کوڈ مل سکتا ہے جو بظاہر غلط معلوم ہوتا ہے، صرف بعد میں معلوم کرنے کے لیے کہ آپ کے کاروبار کے دیگر حصے اس پر منحصر ہیں۔

یہ وہ جگہ ہے جہاں خصوصیت کے ٹیسٹ کام آتے ہیں۔

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

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

export function calculateDiscount(
  customerType: string,
  total: number,
): number {
  if (customerType === "PREMIUM") {
    return total * 0.1;
  }

  return 0;
}

جانچ موجودہ رویے کی حفاظت میں مدد کرتی ہے۔

import { describe, expect, it } from "vitest";
import { calculateDiscount } from "./calculateDiscount";

describe("calculateDiscount", () => {
  it("applies a 10 percent discount to premium customers", () => {
    expect(
      calculateDiscount("PREMIUM", 100),
    ).toBe(10);
  });

  it("does not discount regular customers", () => {
    expect(
      calculateDiscount("REGULAR", 100),
    ).toBe(0);
  });

  it("returns zero when the order total is zero", () => {
    expect(
      calculateDiscount("PREMIUM", 0),
    ).toBe(0);
  });
});

AI اس حفاظتی جال کو بڑھانے میں مدد کر سکتا ہے۔

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

Generate characterization tests for this function.

Preserve the existing behavior.

Include:
- normal inputs,
- boundary values,
- invalid inputs,
- exceptions,
- observable side effects.

Do not redesign the function.

پھر جائزہ لیں کہ کیا پیدا ہوتا ہے۔

اس سے ثابت نہیں ہوتا کہ سابقہ ​​رویہ درست تھا۔ میں ریکارڈ کر رہا ہوں کہ اگر میں اسے ری ایکٹر کرتا ہوں تو کیا بدل جائے گا۔

فرق اہم ہے۔

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

محفوظ نقل مکانی کی حدود کیسے تلاش کریں۔

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

عام طور پر، آپ کو ایک ایسی جگہ کی ضرورت ہے جہاں پرانے اور نئے سسٹمز عارضی طور پر ایک ساتھ رہ سکیں۔

پنکھ بھی سیون کو میراثی کوڈ کو مؤثر طریقے سے استعمال کرنا: یہ وہ جگہ ہے جہاں آپ اپنے اردگرد کی ہر چیز کو تبدیل کیے بغیر اپنا رویہ بدل سکتے ہیں۔

تکمیل کی مثال ایک ممکنہ سیون فراہم کرتی ہے۔

اصل فنکشن میں شامل ہیں:

• کسٹمر کی تصدیق،

• رعایت کا حساب،

• ڈیٹا بیس استقامت،

• ادائیگی کی کارروائی،

• اور ای میل اطلاعات۔

پہلے دو قدرتی طور پر کاروباری رویے کے تحت آتے ہیں. باقی کا تعلق انفراسٹرکچر سے ہے۔ یہ ممکنہ حد کی تجویز کرتا ہے۔

ڈومین/درخواست کی ذمہ داریاں:

• کسٹمر کے قوانین،

• قیمتوں کے قوانین،

• ورک فلو آرڈر کریں۔

بنیادی ڈھانچے کی ذمہ داریاں:

• ڈیٹا بیس،

• ادائیگی فراہم کرنے والے؛

• ای میل فراہم کنندہ۔

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

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

Analyze these files and identify:

- business rules,
- infrastructure concerns,
- side effects,
- shared mutable state,
- duplicated logic,
- dependencies that make isolated testing difficult.

Suggest possible boundaries.

Do not rewrite the code yet.

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

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

واضح ذمہ داریوں کی طرف ری ایکٹر کیسے کریں۔

کوڈ کے کسی حصے کو سمجھنا اور اس کے موجودہ رویے کو جانچنا ری فیکٹرنگ کا خطرہ کم کرتا ہے۔

قیمتوں کا تعین کرنے کے قوانین خالصتاً فعال ہو سکتے ہیں۔

export function calculateDiscount(
  customerType: string,
  total: number,
): number {
  if (customerType === "PREMIUM") {
    return total * 0.1;
  }

  return 0;
}

کسٹمر کی توثیق کو اس میں الگ کیا جا سکتا ہے:

export function validateCustomer(
  customer: Customer,
): void {
  if (!customer.active) {
    throw new Error("Inactive customer");
  }
}

انفراسٹرکچر معاہدوں سے پیچھے رہ سکتا ہے۔

export interface OrderRepository {
  save(order: PersistedOrder): Promise;
}

export interface PaymentGateway {
  charge(
    card: string,
    amount: number,
  ): Promise;
}

export interface NotificationService {
  sendOrderConfirmation(
    email: string,
  ): Promise;
}

اپنی درخواست کے ورک فلو کو پڑھنے میں آسان بنائیں۔

export class ProcessOrder {
  constructor(
    private readonly orders: OrderRepository,
    private readonly payments: PaymentGateway,
    private readonly notifications: NotificationService,
  ) {}

  async execute(order: Order): Promise {
    validateCustomer(order.customer);

    const discount = calculateDiscount(
      order.customer.type,
      order.total,
    );

    const finalAmount =
      order.total - discount;

    await this.orders.save({
      customerId: order.customer.id,
      amount: finalAmount,
    });

    await this.payments.charge(
      order.customer.card,
      finalAmount,
    );

    await this.notifications.sendOrderConfirmation(
      order.customer.email,
    );

    return finalAmount;
  }
}

اس ری فیکٹرنگ کے بارے میں کوئی خاص انقلابی بات نہیں ہے۔ یہ نقطہ کا حصہ ہے.

جدیدیت کو غیر ملکی فن تعمیر کی ضرورت نہیں ہے۔

اکثر ایک اہم بہتری ذمہ داریوں کو اتنا واضح کرتی ہے کہ اگلی تبدیلی کے لیے پوری درخواست کو سمجھنے کی ضرورت نہیں ہوتی ہے۔

مکینیکل اختراع میں AI کا استعمال کیسے کریں۔

جیسے جیسے حدود واضح ہوتی جاتی ہیں، AI نفاذ کے لیے بہت زیادہ مفید ہو جاتا ہے۔

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

• API ترجمہ،

• فریم ورک کے قوانین کو تبدیل کریں،

• اڈاپٹر بنائیں،

• ترتیب کی تبدیلی،

• اپ ڈیٹ کی قسم کی تعریف،

• ڈیٹا تک رسائی کی لائبریری کو تبدیل کریں،

• بار بار انٹیگریشن کوڈ کو اپ ڈیٹ کریں۔

AI کو استعمال کرنے کے لیے یہ ایک بہترین جگہ ہے۔

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

async function getCustomer(id: number) {
  const result = await db.query(
    `SELECT * FROM customer WHERE id = ${id}`,
  );

  return result[0];
}

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

export interface CustomerRepository {
  findById(id: number): Promise;
}

پھر ہم تبدیلی کو محدود کرتے ہیں۔

Implement CustomerRepository using the new database client.

Constraints:

- Keep the CustomerRepository interface unchanged.
- Use parameterized queries.
- Do not move business rules into the repository.
- Preserve the existing null behavior.
- Preserve the existing error semantics.
- Return only the implementation.

یہ اس سے بہت مختلف درخواست ہے:

Modernize this database code.

پہلی صورت میں، ہم نے آرکیٹیکچرل فیصلے کیے اور AI سے کہا کہ وہ ان حدود میں لاگو کرے۔

یہ وہ جگہ ہے جہاں ہمیں نقل مکانی کی کوششوں میں AI سب سے زیادہ کارآمد معلوم ہوتا ہے۔ اہم فیصلے پہلے ہی کر لیے جانے کے بعد مکینیکل کوشش کو ختم کر دیا جاتا ہے۔

چھوٹے عمودی ٹکڑوں میں کیسے منتقل کیا جائے۔

جب ہزاروں فائلیں ایک ساتھ تبدیل ہوتی ہیں، تو بڑے پیمانے پر منتقلی کا اندازہ لگانا مشکل ہو جاتا ہے۔

تبدیلی کی ایک محفوظ اکائی اکثر کاروباری قابلیت ہوتی ہے۔

تمام کنٹرولرز، پھر تمام خدمات، اور آخر میں تمام ذخیروں کو منتقل کرنے کے بجائے، آپ ایک مکمل خصوصیت کو منتقل کرتے ہیں۔

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

آرڈر بنائیں

• API

• درخواست کی منطق

• ڈومین کے قوانین

• استقامت

• ٹیسٹ

پھر ہم اگلی خصوصیت کی طرف بڑھتے ہیں۔

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

جانچ بھی زیادہ مرکوز ہے۔ اور اگر کچھ غلط ہو جائے تو غلطی کو پکڑنا آسان ہو جاتا ہے۔

عمودی ٹکڑوں کے لیے ایک مفید پہلا اشارہ صرف تجزیہ کے لیے ہے۔

We are migrating the Create Order capability.

The legacy implementation is under /legacy/orders.

The target architecture separates:
- domain,
- application,
- infrastructure.

The characterization tests under /tests/legacy
describe behavior that must remain compatible.

Analyze the current implementation.

List:
1. business rules,
2. external dependencies,
3. side effects,
4. likely migration risks,
5. files that need to change.

Do not generate code yet.

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

یہ بتدریج تبدیلی کی حکمت عملیوں کے ساتھ بھی مطابقت رکھتا ہے، جیسا کہ مارٹن فاؤلر کی اسٹرینگلر فِگ اپروچ، جہاں ایک بڑی منتقلی کی ضرورت کے بجائے نئی فعالیت موجودہ نظام سے بتدریج اختیار کرتی ہے۔

اہم الفاظ یہ ہیں۔ آہستہ آہستہ.

AI تبدیلی کو تیز کر سکتا ہے۔ اس سے بگ بینگ ہجرت کا خطرہ کم نہیں ہوتا۔

میراثی رویے کا جدید طرز عمل سے موازنہ کیسے کریں۔

یونٹ ٹیسٹ ایک قسم کی حفاظت فراہم کرتے ہیں۔

نقل مکانی کے لیے، میں پرانے اور نئے نفاذ کا براہ راست موازنہ کرنا بھی پسند کرتا ہوں۔

فرض کریں کہ دونوں سسٹم ایک ہی آرڈر پر کارروائی کر سکتے ہیں۔ آپ ہر ایک کے ذریعے ایک ہی فکسچر چلا سکتے ہیں:

const inputs = [
  premiumCustomerOrder,
  standardCustomerOrder,
  inactiveCustomerOrder,
];

for (const input of inputs) {
  const legacyResult =
    await legacyProcessor(input);

  const modernResult =
    await modernProcessor(input);

  expect(modernResult).toEqual(legacyResult);
}

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

وہی بھیجیں POST /orders دونوں ورژن کی درخواست کریں اور موازنہ کریں۔

• اسٹیٹس کوڈ

• ردعمل پے لوڈ

• ڈیٹا بیس کی تبدیلیاں

• واقعہ کا اخراج

• بیرونی کرنسی

• غلطی

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

AI یہاں بھی مدد کر سکتا ہے۔

اگر آپ کے پاس سینکڑوں تضادات ہیں، تو آپ انہیں ایک ساتھ گروپ کرنے کے لیے کہہ سکتے ہیں۔

Analyze these behavioral mismatches.

Group them by likely cause.

Pay particular attention to:
- rounding,
- null handling,
- timezone conversion,
- validation,
- serialization,
- data mapping.

Do not label a mismatch as a defect unless the
available evidence supports that conclusion.

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

ریگریشنز تلاش کرنے کے لیے شیڈو ٹریفک کا استعمال کیسے کریں۔

بالآخر، آپ کے ٹیسٹ فکسچر مزید نمائندہ نہیں رہیں گے۔

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

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

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

Legacy:
200
{ "total": 90 }

Modern:
200
{ "total": 90 }

MATCH

یا:

Legacy:
200
{ "total": 90 }

Modern:
200
{ "total": 100 }

MISMATCH

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

اس تکنیک میں آپریشنل تحفظات شامل ہیں۔ آپ کو مندرجہ ذیل کے بارے میں احتیاط سے سوچنا چاہئے:

• نقلی ضمنی اثرات،

• ادائیگی کی کرنسی،

• ای میل

• لکھیں،

• تنہائی،

• پیداوار کا بوجھ،

• اور بیرونی APIs کا استعمال کرتے ہوئے

شیڈو مثالوں کو عام طور پر کوئی ناقابل واپسی ضمنی اثرات نہیں ہونے چاہئیں۔

مثال کے طور پر، فزیکل پیمنٹ اڈاپٹر کو ریکارڈنگ اڈاپٹر سے بدل دیں۔

export class RecordingPaymentGateway
  implements PaymentGateway {

  public readonly calls: Array<{
    card: string;
    amount: number;
  }> = [];

  async charge(
    card: string,
    amount: number,
  ): Promise {
    this.calls.push({
      card,
      amount,
    });
  }
}

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

آپ جس فن تعمیر کو اصل میں چاہتے ہیں اس کی جانچ کیسے کریں۔

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

فرض کریں کہ آپ نے درج ذیل رکاوٹوں کا تعین کیا ہے:

ڈومین کوڈ کا انحصار انفراسٹرکچر کوڈ پر نہیں ہونا چاہیے۔

اگر وہ اصول صرف آرکیٹیکچر ڈایاگرام میں موجود ہیں، تو ہجرت کا دباؤ بالآخر انہیں توڑ دے گا۔

تو اس کی جانچ کریں۔

سادہ منصوبوں کے لیے آپ درآمدات کا معائنہ کر سکتے ہیں۔ بڑے پیمانے کے لیے، انحصاری تجزیہ کا آلہ استعمال کریں جو تعمیراتی اصولوں کو نافذ کر سکے۔

درست ٹولنگ اصول سے کم اہم ہے۔

اگر آرکیٹیکچرل رکاوٹیں اہم ہیں، تو انہیں توڑنے کی اجازت دیں۔

آپ کو اس طرح کے اصول کی ضرورت ہوسکتی ہے:

• آپ کے ڈومین کو انفراسٹرکچر پر انحصار نہیں کرنا چاہیے۔

• آپ کے ڈومین کو HTTP فریم ورک پر انحصار نہیں کرنا چاہیے۔

• ایپلیکیشن کوڈ کا انحصار براہ راست ڈیٹا بیس ڈرائیورز پر نہیں ہونا چاہیے۔

• ایک ماڈیول کو دوسرے ماڈیول کے اندرونی نفاذ کو درآمد نہیں کرنا چاہیے۔

AI کی مدد سے منتقلی میں یہ کیوں اہم ہے؟ کیونکہ AI کوڈ کو مرتب کرنے کے طریقے تلاش کرنے میں بہت اچھا ہے۔

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

آرکیٹیکچرل ٹیسٹنگ ایسی حدود فراہم کرتی ہے جن کی غلطی سے خلاف ورزی کرنا انسانوں اور AI ٹولز دونوں کے لیے مشکل ہے۔

یہ کیسے طے کریں کہ AI کو کن کاموں کو سنبھالنا چاہئے۔

نقل مکانی کے تمام کاموں کے ساتھ ایک جیسا سلوک نہیں کیا جاتا ہے۔ کچھ آٹومیشن کے لیے اچھے امیدوار ہیں۔

وہ کام جہاں AI عام طور پر مفید ہوتا ہے۔

• غیر مانوس کوڈ کی وضاحت کرنا

• انحصار کی شناخت کریں۔

• امیدوار کاروباری اصول نکالنا

• خصوصیت کے ٹیسٹ کیسز بنائیں

• دوبارہ قابل اڈاپٹر بنائیں

• فریم ورک API اپ ڈیٹس

• مشین کوڈ کا ترجمہ

• ہجرت کی چیک لسٹ بنائیں

• نفاذ کا موازنہ

• ریگریشن آؤٹ پٹ کی درجہ بندی

• تکنیکی دستاویزات کا مسودہ تیار کرنا

ایسے کام جن میں انجینئرنگ کا اہم جائزہ درکار ہوتا ہے۔

• ماڈیول باؤنڈری کی تجویز

• ڈومین کا تصور نکالنا

• انتہائی جوڑے ہوئے کلاس ری فیکٹرنگ

• منتقلی کا آرڈر منتخب کریں۔

• اپنا ڈیٹا ماڈل تبدیل کریں۔

• انٹیگریٹڈ باؤنڈری ڈیزائن

فیصلے انسانوں کے ہاتھ میں رہیں گے۔

• ہدف فن تعمیر

• قابل قبول رویے کے اختلافات

• سیکورٹی کا دائرہ

• ڈیٹا منتقلی کی حکمت عملی

• حکمت عملی لانچ کریں۔

• رول بیک حکمت عملی

• میراثی سلوک کو ہٹا دیں۔

• پیداوار کے خطرے کو قبول کریں۔

اس کی وجہ یہ نہیں ہے کہ AI آرکیٹیکچرل پروپوزل تیار نہیں کر سکتا۔ ایسا ہو سکتا ہے۔

مسئلہ ذمہ داری اور سیاق و سباق کا ہے۔

آرکیٹیکچرل انتخاب رکاوٹوں، تاریخ، تنظیمی صلاحیتوں، کاروباری ترجیحات، اور آپریشنل خطرات کا نتیجہ ہیں جو ذخیرہ میں کہیں اور موجود نہیں ہوسکتے ہیں۔

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

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

نقل مکانی کی رفتار ایک پرکشش میٹرک ہے کیونکہ اسے ظاہر کرنا آسان ہے۔

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

کوڈ بیس کا 37٪ منتقل کیا گیا تھا۔

یہ آپ کو اس بارے میں زیادہ نہیں بتاتا کہ آیا نظام بہتر ہے یا نہیں۔

جدیدیت کی کوششوں کو کئی قسم کے نتائج کو دیکھنے کی ضرورت ہے۔ آپریشنل میٹرکس میں شامل ہوسکتا ہے:

• تعیناتی کی تعدد

• ناکامی کی شرح کو تبدیل کریں۔

• اوسط وصولی کا وقت

• پیداوار حادثہ

• وقت کی تعمیر

انجینئرنگ میٹرکس میں شامل ہوسکتا ہے:

• ٹیسٹ کی گنجائش

• اعلی پیچیدگی کی کلاس

• ڈپلیکیٹ کاروباری قواعد

• انٹر ماڈیول انحصار

• عمارت کی خلاف ورزی

• فعالیت کو تبدیل کرنے کے لیے وقت درکار ہے۔

ہجرت سے متعلق میٹرکس میں شامل ہو سکتے ہیں:

• رجعت کی شرح

• نئے راستے کے ذریعے پیش کی جانے والی ٹریفک کا فیصد

• غیر حل شدہ طرز عمل کی تضادات

• رول بیک فریکوئنسی

• میراثی اجزاء اب بھی استعمال میں ہیں۔

درست میٹرکس آپ کے سسٹم کے لحاظ سے مختلف ہوں گے۔ اہم بات یہ ہے کہ کامیابی کی درج ذیل تعریفوں سے گریز کیا جائے۔

پرانا ذخیرہ چھوٹا ہے = جدید کاری کامیاب رہی۔

AI آپ کو کم وقت میں مزید کوڈ تبدیل کرنے کی اجازت دیتا ہے۔ یہ تبادلوں کے معیار کی پیمائش کو زیادہ اہم بناتا ہے۔

وہ خطرات جن کے بارے میں مجھے AI کی مدد سے منتقلی کے بارے میں سب سے زیادہ تشویش ہے۔

ہیلوسینیشن کوڈز ایک واضح خطرہ ہیں۔ لیکن میں جس چیز کے بارے میں زیادہ پریشان ہوں وہ ہے۔ قابل فہم کوڈ.

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

اس طرح کی چھوٹی چیز پر غور کریں:

if (customer.balance > 0) {
  charge(customer);
}

جب آپ کو یہ سمجھ نہیں آتی ہے کہ کوئی شرط کیوں موجود ہے تو یہ آپ کے کوڈ کو صاف کرنا پرکشش ہے۔

تاہم، 0 کا خاص کاروباری معنی بھی ہو سکتا ہے۔

ہوسکتا ہے کہ منفی توازن جائز ہو۔

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

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

تبدیلی جتنی تیز ہوگی، تصدیق کا عمل اتنا ہی مضبوط ہونا چاہیے۔

دوسری صورت میں، یہ صرف اس رفتار میں اضافہ کرے گا جس پر نامعلوم تبدیلیوں کو متعارف کرایا جا سکتا ہے.

عملی مائیگریشن ورک فلو

میں اسے استعمال کروں گا اگر مجھے کسی عمل کو ایک قابل تکرار ترتیب تک کم کرنے کی ضرورت ہو۔

1. سمجھنا

نقشہ:

• کارروائی

• انحصار

• کاروباری قوانین

• ضمنی اثرات

• ڈیٹا

• انضمام

AI کا استعمال کرتے ہوئے اپنی تحقیقات کو تیز کریں۔ نیا نظام بنا کر شروع نہ کریں۔

2. تحفظ

تحریر:

• کریکٹرائزیشن ٹیسٹ

• انضمام کی جانچ

• API کی سہولت

• طرز عمل سنیپ شاٹ

موجودہ رویے کو قابل مشاہدہ بناتا ہے۔

3. ڈیزائن

منتخب کریں:

• حد

• انٹرفیس

• ذمہ داری

• نقل مکانی سیون

کسی بھی بڑی تبدیلی سے پہلے یہ کریں۔

4. ریفیکٹرنگ

کافی علیحدگی بنائیں تاکہ سسٹم کے حصوں کو ہر چیز کو گھسیٹے بغیر منتقل کیا جا سکے۔

5. تبدیلی

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

واضح آرکیٹیکچرل رکاوٹیں دیں۔

6. موازنہ

ایک ہی ان پٹ پر پرانے اور نئے اعمال کو انجام دیں اور اختلافات کی جانچ کریں۔

7. بتدریج رول آؤٹ

اپنے ماحول کے لیے مناسب طریقہ کار استعمال کریں۔

• خصوصیت کے جھنڈے

• کینری تعیناتی۔

• سائے ٹریفک

• مشاہدہ

• رول بیک

8. پرانے راستے کو ہٹا دیں۔

دونوں نظاموں کو غیر معینہ مدت تک چلنے نہ دیں۔ ہجرت جو میراثی راستوں کو ختم نہیں کرتی ہے وہ ایک اور میراثی فن تعمیر کو ختم کرتی ہے۔

نتیجہ

AI روایتی جدیدیت کی معاشیات کو تبدیل کرتا ہے۔

بہت سے کام جو انجینئرنگ کا وقت استعمال کرتے تھے – غیر مانوس کوڈ کو پڑھنا، ٹیسٹ بنانا، APIs کو اپ ڈیٹ کرنا، تکراری نفاذ کا ترجمہ کرنا، اور سسٹمز کے درمیان فرق کی تحقیقات کرنا – اب بہت تیزی سے انجام دیے جا سکتے ہیں۔

یہ مفید ہے۔ لیکن یہ جدیدیت کا حصہ نہیں ہے جس میں سب سے زیادہ فیصلے کی ضرورت ہے۔

مشکل سوالات باقی ہیں۔

• کون سے اعمال اب بھی اہم ہیں؟

• دور جانے کی کیا ضرورت ہے؟

• کن انحصاروں کو زندہ رہنا چاہئے؟

• سرحدیں کہاں ہونی چاہئیں؟

• رویے کی تبدیلی کتنی قابل قبول ہے؟

• پروڈکشن ٹریفک حاصل کرنے کے لیے نیا نفاذ کب اتنا محفوظ ہوگا؟

صرف کوڈ ترجمہ کے لیے AI کا استعمال آپ کو تکنیکی قرض کو تیزی سے منتقل کرنے کی اجازت دیتا ہے۔

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

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

AI اس راستے کو چھوٹا کر سکتا ہے۔ لیکن میں ابھی طے نہیں کر سکتا کہ منزل کیا ہے۔