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

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

کوڈ جیم پر ری فیکٹرنگ

کوڈ جیم کورس میں ری فیکٹرنگ کا احاطہ کیا گیا ہے:

• ملٹی تھریڈنگ کی تلاش کے لیول 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 ڈیزائن کی خلاف ورزی کرتا ہے۔ ایسا اس وقت ہوتا ہے جب وہ 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) {
    // Some actions
    double yearlySalary = employee.getYearlySalary();
    double awards = employee.getAwards();
    double monthlySalary = getMonthlySalary(yearlySalary, awards);
    // Continue processing
}

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

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

public void employeeMethod(Employee employee) {
    // Some actions
    double monthlySalary = getMonthlySalary(employee);
    // Continue processing
}

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

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

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

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

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

اپنے آپ کو ری فیکٹرنگ میں مزید غرق کرنے کے وسائل

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

1. ہیڈ فرسٹ سیریز سے ایرک فری مین، الزبتھ رابسن، کیتھی سیرا، اور برٹ بیٹس کے "ڈیزائن پیٹرنز"
2. "دی آرٹ آف ریڈ ایبل کوڈ" بذریعہ ڈسٹن بوسویل اور ٹریور فاؤچر
3. Steve McConnell کا "کوڈ مکمل"، جو خوبصورت اور خوبصورت کوڈ کے اصول متعین کرتا ہے۔