جاوا میں ری فیکٹرنگ کیسے کام کرتی ہے۔

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

جاوا رش کورس میں ری فیکٹرنگ

JavaRush کورس دو بار ری فیکٹرنگ کے موضوع کا احاطہ کرتا ہے:

• ملٹی تھریڈنگ کی تلاش کے لیول 5 پر بڑا چیلنج ؛
• جاوا کلیکشن کی تلاش کے لیول 9 پر Intellij IDEA میں ری فیکٹرنگ پر لیکچر ۔

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

ریفیکٹرنگ کیا ہے؟

یہ اس کی فعالیت کو تبدیل کیے بغیر کوڈ کی ساخت میں تبدیلی ہے۔ مثال کے طور پر، ایک ایسا طریقہ ہے جو 2 نمبروں کا موازنہ کرتا ہے اور اگر پہلا نمبر بڑا ہے تو صحیح واپس آتا ہے، اور دوسری صورت میں غلط :

public boolean max(int a, int b) {
    if(a > b) {
        return true;
    } else if(a == b) {
        return false;
    } else {
        return false;
    }
}

نتیجہ بہت بوجھل کوڈ تھا۔ یہاں تک کہ مبتدی بھی شاذ و نادر ہی ایسا کچھ لکھتے ہیں، لیکن ایسا خطرہ ہوتا ہے۔ ایسا لگتا ہے، یہاں ایک بلاک کیوں ہے if-elseاگر آپ 6 لائنیں چھوٹا طریقہ لکھ سکتے ہیں:

public boolean max(int a, int b) {
     return a>b;
}

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

ری فیکٹرنگ کی ضرورت کیوں ہے؟

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

1. ری فیکٹرنگ دوسرے ڈویلپر کے لکھے ہوئے کوڈ کی سمجھ کو بہتر بناتا ہے۔
2. غلطیوں کو تلاش کرنے اور ٹھیک کرنے میں مدد کرتا ہے۔
3. آپ کو سافٹ ویئر کی ترقی کی رفتار بڑھانے کی اجازت دیتا ہے؛
4. مجموعی طور پر سافٹ ویئر کی ساخت کو بہتر بناتا ہے۔

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

"کوڈ بو آ رہا ہے"

جب کوڈ کو ری فیکٹرنگ کی ضرورت ہوتی ہے تو وہ کہتے ہیں کہ "بو آ رہی ہے۔" یقینا، لفظی نہیں، لیکن اس طرح کا کوڈ واقعی بہت اچھا نہیں لگتا. ذیل میں ہم ابتدائی مرحلے کے لیے ری فیکٹرنگ کی اہم تکنیکوں پر غور کریں گے۔

غیر ضروری طور پر بڑے عناصر

بوجھل کلاسز اور طریقے ہیں جن کے ساتھ کام کرنا ان کے بڑے سائز کی وجہ سے مؤثر طریقے سے درست طریقے سے ناممکن ہے۔

بڑی کلاس

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

بڑا طریقہ

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

1. اگر، کوئی طریقہ لکھتے وقت، آپ کوڈ میں ایک تبصرہ شامل کرنا چاہتے ہیں، تو آپ کو اس فعالیت کو ایک الگ طریقہ میں الگ کرنے کی ضرورت ہے۔
2. اگر کوئی طریقہ کوڈ کی 10-15 لائنوں سے زیادہ لیتا ہے، تو آپ کو ان کاموں اور ذیلی کاموں کی شناخت کرنی چاہیے جو وہ انجام دیتا ہے اور ذیلی کاموں کو ایک الگ طریقہ میں الگ کرنے کی کوشش کریں۔

ایک بڑے طریقہ کو ختم کرنے کے کئی طریقے:

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

بہت سے قدیم ڈیٹا کی اقسام کا استعمال کرتے ہوئے

عام طور پر، یہ مسئلہ اس وقت ہوتا ہے جب کلاس میں ڈیٹا کو ذخیرہ کرنے کے لیے فیلڈز کی تعداد وقت کے ساتھ بڑھ جاتی ہے۔ مثال کے طور پر، اگر آپ ڈیٹا (کرنسی، تاریخ، ٹیلی فون نمبرز، وغیرہ) یا کسی بھی معلومات کو انکوڈ کرنے کے لیے مستقل کو ذخیرہ کرنے کے لیے چھوٹی اشیاء کی بجائے قدیم اقسام کا استعمال کرتے ہیں۔ اس معاملے میں ایک اچھا عمل یہ ہوگا کہ منطقی طور پر فیلڈز کو گروپ کیا جائے اور انہیں ایک الگ کلاس میں رکھا جائے (کلاس کا انتخاب کرنا)۔ آپ کلاس میں اس ڈیٹا پر کارروائی کرنے کے طریقے بھی شامل کر سکتے ہیں۔

اختیارات کی لمبی فہرست

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

ڈیٹا گروپس

ڈیٹا کے منطقی طور پر متعلقہ گروپ اکثر کوڈ میں ظاہر ہوتے ہیں۔ مثال کے طور پر، ڈیٹا بیس سے کنکشن کے پیرامیٹرز (URL، صارف نام، پاس ورڈ، اسکیما کا نام، وغیرہ)۔ اگر عناصر کی فہرست سے کسی ایک فیلڈ کو نہیں ہٹایا جا سکتا ہے، تو فہرست ڈیٹا کا ایک گروپ ہے جسے ایک الگ کلاس (کلاس سلیکشن) میں رکھا جانا چاہیے۔

ایسے حل جو OOP کے تصور کو خراب کرتے ہیں۔

اس قسم کی "بو" اس وقت ہوتی ہے جب ڈویلپر OOP ڈیزائن کی خلاف ورزی کرتا ہے۔ ایسا اس وقت ہوتا ہے جب وہ اس تمثیل کی صلاحیتوں کو پوری طرح نہیں سمجھتا، انہیں نامکمل یا غلط استعمال کرتا ہے۔

وراثت سے انکار

اگر کوئی ذیلی طبقہ پیرنٹ کلاس کے افعال کا ایک کم سے کم حصہ استعمال کرتا ہے، تو اس سے ایک غلط درجہ بندی کی طرح بو آتی ہے۔ عام طور پر، اس معاملے میں، غیر ضروری طریقوں کو محض اوور رائڈ نہیں کیا جاتا ہے یا مستثنیات کو پھینک دیا جاتا ہے۔ اگر ایک کلاس دوسرے سے وراثت میں ملتی ہے، تو اس کا مطلب اس کی فعالیت کا تقریباً مکمل استعمال ہوتا ہے۔ صحیح درجہ بندی کی مثال: غلط درجہ بندی کی مثال:

بیان سوئچ کریں

آپریٹر کے ساتھ کیا غلط ہو سکتا ہے switch؟ یہ خراب ہے جب اس کا ڈیزائن بہت پیچیدہ ہے۔ اس میں بہت سے نیسٹڈ بلاکس بھی شامل ہیں if۔

مختلف انٹرفیس کے ساتھ متبادل کلاسز

کئی کلاسیں بنیادی طور پر ایک ہی کام کرتی ہیں، لیکن ان کے طریقوں کو مختلف نام دیا گیا ہے۔

عارضی میدان

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

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

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

متوازی وراثت کے درجہ بندی

جب آپ کسی کلاس کا ذیلی طبقہ بناتے ہیں، تو آپ کو دوسری کلاس کے لیے ایک اور ذیلی کلاس بنانا چاہیے۔

یکساں انحصار کی تقسیم

کوئی ترمیم کرتے وقت، آپ کو اس کلاس کے تمام انحصار (استعمال) کو تلاش کرنا ہوگا اور بہت سی چھوٹی تبدیلیاں کرنی ہوں گی۔ ایک تبدیلی - کئی کلاسوں میں ترمیم۔

پیچیدہ ترمیم کا درخت

یہ بو پچھلے ایک کے برعکس ہے: تبدیلیاں ایک ہی طبقے کے طریقوں کی ایک بڑی تعداد کو متاثر کرتی ہیں۔ ایک اصول کے طور پر، اس طرح کے کوڈ میں انحصار جھلکتا ہے: ایک طریقہ کو تبدیل کرنے کے بعد، آپ کو دوسرے میں کچھ ٹھیک کرنے کی ضرورت ہے، اور پھر تیسرے میں، اور اسی طرح. ایک طبقہ - بہت سی تبدیلیاں۔

"کچرے سے بدبو آتی ہے"

بدبو کا ایک ناخوشگوار زمرہ جو سر درد کا سبب بنتا ہے۔ بیکار، غیر ضروری، پرانا کوڈ۔ خوش قسمتی سے، جدید IDEs اور linters نے ایسی بدبو کے بارے میں خبردار کرنا سیکھ لیا ہے۔

طریقہ کار میں تبصرے کی ایک بڑی تعداد

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

کوڈ کی نقل

مختلف کلاسز یا طریقے کوڈ کے ایک ہی بلاکس کا استعمال کرتے ہیں۔

سست کلاس

کلاس میں بہت کم فعالیت ہوتی ہے، حالانکہ اس کی بہت سی منصوبہ بندی کی گئی تھی۔

غیر استعمال شدہ کوڈ

کوڈ میں کلاس، طریقہ یا متغیر استعمال نہیں کیا گیا ہے اور یہ "ڈیڈ ویٹ" ہے۔

ضرورت سے زیادہ جوڑے

بو کے اس زمرے کی خصوصیت کوڈ میں غیر ضروری کنکشن کی ایک بڑی تعداد ہے۔

تیسری پارٹی کے طریقے

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

نامناسب قربت

ایک کلاس سروس فیلڈز اور دوسری کلاس کے طریقے استعمال کرتی ہے۔

لمبی کلاس کالز

ایک کلاس دوسرے کو کال کرتی ہے، جو تیسرے سے ڈیٹا کی درخواست کرتی ہے، چوتھی سے، وغیرہ۔ کالوں کے اتنے طویل سلسلے کا مطلب ہے موجودہ طبقاتی ڈھانچے پر اعلیٰ سطح کا انحصار۔

کلاس ٹاسک ڈیلر

ایک کلاس کی ضرورت صرف کسی کام کو دوسری کلاس کو منتقل کرنے کے لیے ہوتی ہے۔ شاید اسے ہٹا دیا جانا چاہئے؟

ریفیکٹرنگ تکنیک

ذیل میں ہم ابتدائی ری فیکٹرنگ تکنیکوں کے بارے میں بات کریں گے جو بیان کردہ کوڈ کی بدبو کو ختم کرنے میں مدد کریں گی۔

کلاس سلیکشن

کلاس بہت زیادہ افعال انجام دیتی ہے؛ ان میں سے کچھ کو دوسری کلاس میں منتقل کرنے کی ضرورت ہے۔ مثال کے طور پر، ایک کلاس ہے Humanجس میں رہائشی پتہ اور طریقہ بھی ہے جو مکمل پتہ فراہم کرتا ہے:

class Human {
   private String name;
   private String age;
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

ایڈریس کی معلومات اور طریقہ کار (ڈیٹا پروسیسنگ رویہ) کو الگ کلاس میں رکھنا اچھا خیال ہوگا:

class Human {
   private String name;
   private String age;
   private Address address;

   private String getFullAddress() {
       return address.getFullAddress();
   }
}
class Address {
   private String country;
   private String city;
   private String street;
   private String house;
   private String quarter;

   public String getFullAddress() {
       StringBuilder result = new StringBuilder();
       return result
                       .append(country)
                       .append(", ")
                       .append(city)
                       .append(", ")
                       .append(street)
                       .append(", ")
                       .append(house)
                       .append(" ")
                       .append(quarter).toString();
   }
}

طریقہ انتخاب

اگر کسی طریقہ کار میں کسی بھی فعالیت کو گروپ کیا جا سکتا ہے، تو اسے الگ طریقہ میں رکھا جانا چاہیے۔ مثال کے طور پر، ایک طریقہ جو چوکور مساوات کی جڑوں کا حساب لگاتا ہے:

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        double x1, x2;
        x1 = (-b - Math.sqrt(D)) / (2 * a);
        x2 = (-b + Math.sqrt(D)) / (2 * a);
        System.out.println("x1 = " + x1 + ", x2 = " + x2);
    }
    else if (D == 0) {
        double x;
        x = -b / (2 * a);
        System.out.println("x = " + x);
    }
    else {
        System.out.println("Equation has no roots");
    }
}

آئیے تینوں ممکنہ اختیارات کے حساب کتاب کو الگ الگ طریقوں میں منتقل کرتے ہیں:

public void calcQuadraticEq(double a, double b, double c) {
    double D = b * b - 4 * a * c;
    if (D > 0) {
        dGreaterThanZero(a, b, D);
    }
    else if (D == 0) {
        dEqualsZero(a, b);
    }
    else {
        dLessThanZero();
    }
}

public void dGreaterThanZero(double a, double b, double D) {
    double x1, x2;
    x1 = (-b - Math.sqrt(D)) / (2 * a);
    x2 = (-b + Math.sqrt(D)) / (2 * a);
    System.out.println("x1 = " + x1 + ", x2 = " + x2);
}

public void dEqualsZero(double a, double b) {
    double x;
    x = -b / (2 * a);
    System.out.println("x = " + x);
}

public void dLessThanZero() {
    System.out.println("Equation has no roots");
}

ہر طریقہ کا کوڈ بہت چھوٹا اور واضح ہو گیا ہے۔

پوری آبجیکٹ کو منتقل کرنا

پیرامیٹرز کے ساتھ کسی طریقہ کو کال کرتے وقت، آپ کبھی کبھی اس طرح کا کوڈ دیکھ سکتے ہیں:

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double yearlySalary = employee.getYearlySalary();
    double awards = employee.getAwards();
    double monthlySalary = getMonthlySalary(yearlySalary, awards);
    // Продолжение обработки
}

public double getMonthlySalary(double yearlySalary, double awards) {
     return (yearlySalary + awards)/12;
}

طریقہ کار میں، employeeMethodزیادہ سے زیادہ 2 لائنیں اقدار کو حاصل کرنے اور انہیں قدیم متغیرات میں ذخیرہ کرنے کے لیے مختص کی گئی ہیں۔ بعض اوقات اس طرح کے ڈیزائن میں 10 لائنیں لگتی ہیں۔ آبجیکٹ کو خود طریقہ کار میں منتقل کرنا بہت آسان ہے، جہاں سے آپ ضروری ڈیٹا نکال سکتے ہیں:

public void employeeMethod(Employee employee) {
    // Некоторые действия
    double monthlySalary = getMonthlySalary(employee);
    // Продолжение обработки
}

public double getMonthlySalary(Employee employee) {
    return (employee.getYearlySalary() + employee.getAwards())/12;
}

سادہ، مختصر اور جامع۔

فیلڈز کی منطقی گروپ بندی اور انہیں الگ کلاس میں رکھنا

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

ری فیکٹرنگ کیوں موثر ہے۔

ایک اچھی ری فیکٹرنگ کا نتیجہ ایک ایسا پروگرام ہے جس کا کوڈ پڑھنا آسان ہے، پروگرام کی منطق میں تبدیلیاں خطرے کا باعث نہیں بنتی ہیں، اور نئی خصوصیات کا تعارف کوڈ پارسنگ جہنم میں نہیں بدلتا، بلکہ چند دنوں کے لیے ایک خوشگوار سرگرمی ہے۔ . ری فیکٹرنگ کا استعمال نہیں کیا جانا چاہئے اگر پروگرام کو شروع سے دوبارہ لکھنا آسان ہو۔ مثال کے طور پر، ٹیم کا تخمینہ ہے کہ کوڈ کو پارس کرنے، تجزیہ کرنے اور ری فیکٹرنگ کے لیے لیبر کی لاگت اسی فعالیت کو شروع سے لاگو کرنے سے زیادہ ہے۔ یا جس کوڈ کو ری فیکٹر کرنے کی ضرورت ہے اس میں بہت ساری غلطیاں ہیں جن کو ڈیبگ کرنا مشکل ہے۔ پروگرامر کے کام میں کوڈ کی ساخت کو بہتر بنانے کا طریقہ جاننا لازمی ہے۔ ٹھیک ہے، JavaRush پر جاوا پروگرامنگ سیکھنا بہتر ہے - پریکٹس پر زور دینے والا ایک آن لائن کورس۔ فوری تصدیق کے ساتھ 1200+ کام، تقریباً 20 منی پروجیکٹس، گیم ٹاسک - یہ سب آپ کو کوڈنگ میں اعتماد محسوس کرنے میں مدد کریں گے۔ شروع کرنے کا بہترین وقت اب ہے :)

ری فیکٹرنگ میں مزید غوطہ لگانے کے لیے وسائل

ری فیکٹرنگ کے بارے میں سب سے مشہور کتاب "ری فیکٹرنگ" ہے۔ مارٹن فاؤلر کے ذریعہ موجودہ کوڈ کے ڈیزائن کو بہتر بنانا۔ ریفیکٹرنگ پر ایک دلچسپ اشاعت بھی ہے، جو جوشوا کیریوسکی کی ایک پچھلی کتاب - "ریفیکٹرنگ ود پیٹرنز" پر مبنی ہے۔ ٹیمپلیٹس کی بات کرتے ہوئے۔ ری فیکٹرنگ کرتے وقت، ایپلیکیشن ڈیزائن کے بنیادی نمونوں کو جاننا ہمیشہ بہت مفید ہوتا ہے۔ یہ عظیم کتابیں اس میں مدد کریں گی:

1. "ڈیزائن پیٹرنز" - ایرک فری مین، الزبتھ فری مین، کیتھی سیرا، برٹ بیٹس فار دی ہیڈ فرسٹ سیریز؛
2. "پڑھنے کے قابل کوڈ، یا پروگرامنگ بطور آرٹ" - ڈسٹن بوسویل، ٹریور فوچر۔
3. Steve McConnell کا "Perfect Code"، جو خوبصورت اور خوبصورت کوڈ کے اصولوں کو بیان کرتا ہے۔

ٹھیک ہے، ری فیکٹرنگ کے بارے میں چند مضامین:

1. جہنم کا کام: آئیے لیگیسی کوڈ کی ری فیکٹرنگ شروع کریں ۔
2. ریفیکٹرنگ _
3. سب کے لیے ری فیکٹرنگ