میراثی کوڈ کیا ہے اور اس کے ساتھ کیسے کام کرنا ہے۔
ماخذ: ڈو جلد اور بعد میں، ایک پروگرامر کو شاید میراثی کوڈ کا سامنا کرنا پڑے گا۔ اس شناسائی کے نتائج کو کم کرنے کے لیے، میں نے اپنے تجربے سے کچھ عملی نکات اور مثالیں منتخب کی ہیں - خاص طور پر، میراثی جاوا سسٹم کے ساتھ کام کرنا۔میراثی خصوصیات
میراث کسی اور کا کوڈ ہے، جو اکثر اتنا خوفناک ہوتا ہے کہ عام طور پر یہ واضح نہیں ہوتا کہ اس کے ساتھ کیسے کام کیا جائے۔ اور اگر آپ کو پرانے کوڈ کے علاوہ، پرانے کوڈ کے ساتھ کام کرنا ہے، تو آپ کا سامنا بھی ہوگا:- پرانی ٹیکنالوجی کے ساتھ؛
- متفاوت فن تعمیر؛
- دستاویزات کی کمی یا یہاں تک کہ مکمل عدم موجودگی۔
-
ہم ایسے نظام کی بے عزتی نہیں کر سکتے جس سے روزانہ لاکھوں لوگ کماتے ہیں یا اس تک ہزاروں لوگ رسائی حاصل کرتے ہیں۔ اس سے کوئی فرق نہیں پڑتا ہے کہ یہ کتنا ہی خراب لکھا گیا تھا، یہ مکروہ کوڈ پیداوار تک زندہ رہا اور 24/7 کام کرتا ہے۔
-
چونکہ یہ نظام حقیقی رقم لاتا ہے، اس کے ساتھ کام کرنا بڑی ذمہ داری کے ساتھ آتا ہے۔ یہ کوئی سٹارٹ اپ نہیں ہے، بلکہ ایسی چیز ہے جس کے ساتھ صارفین کل کام کریں گے۔ اس سے غلطی کی بہت زیادہ قیمت بھی ظاہر ہوتی ہے، اور یہاں بات کلائنٹ کے دعووں میں نہیں ہے، بلکہ معاملات کی اصل حالت میں ہے۔
ریورس انجینئرنگ
لیگیسی کوڈ کے ساتھ کامیابی کے ساتھ کام کرنے کے لیے، آپ کو ریورس انجینئرنگ تکنیک استعمال کرنی ہوگی۔ سب سے پہلے، آپ کو کوڈ کو بغور پڑھنے کی ضرورت ہے تاکہ یہ سمجھ سکیں کہ یہ کیسے کام کرتا ہے۔ یہ لازمی ہے، کیونکہ ہمارے پاس دستاویزات نہیں ہوں گی۔ اگر ہم مصنف کی سوچ کی تربیت کو نہیں سمجھتے ہیں، تو ہم غیر متوقع نتائج کے ساتھ تبدیلیاں کریں گے۔ اس سے اپنے آپ کو بچانے کے لیے، آپ کو ملحقہ کوڈ کو بھی جاننے کی ضرورت ہے۔ اور ایک ہی وقت میں نہ صرف چوڑائی میں بلکہ گہرائی میں بھی حرکت کریں۔ غلطی کے ساتھ طریقہ کہاں کہا جاتا ہے؟ اس کو کال کرنے والا کوڈ کہاں سے آتا ہے؟ میراثی پروجیکٹ میں، "کال کی درجہ بندی" اور "قسم کا درجہ بندی" کسی بھی چیز سے زیادہ کثرت سے استعمال ہوتے ہیں۔ آپ کو ڈیبگر کے ساتھ کافی وقت گزارنا پڑے گا: سب سے پہلے، غلطیاں تلاش کرنے کے لیے، اور دوم، یہ سمجھنا کہ سب کچھ کیسے کام کرتا ہے۔ جہاں تک دستاویزات کا تعلق ہے، صنعتی آثار قدیمہ کا سہارا لینا برا خیال نہیں ہوگا۔ کہیں پرانی دستاویزات کو کھودنا اور ان لوگوں سے بات کرنا بہت مفید ہو سکتا ہے جنہیں یاد ہے کہ آپ کو وراثت میں ملا کوڈ کیسے لکھا گیا تھا۔ ان تکنیکوں کا استعمال کرتے ہوئے، جلد یا بدیر آپ کوڈ کو کم و بیش سمجھنا شروع کر دیں گے۔ لیکن اپنی کوششوں کو ضائع ہونے سے روکنے کے لیے، آپ کو اپنی تحقیق کے نتائج کو فوری طور پر دستاویز کرنا چاہیے۔ ایسا کرنے کے لیے، میں تجویز کرتا ہوں کہ بلاک ڈایاگرام یا ترتیب ڈایاگرام بنائیں۔ بلاشبہ، آپ سست ہوں گے، لیکن آپ کو یقینی طور پر ایسا کرنے کی ضرورت ہے، ورنہ چھ ماہ میں بغیر دستاویزات کے آپ اس کوڈ کو اس طرح کھودیں گے جیسے یہ پہلی بار تھا۔
کوڈ کو دوبارہ نہ لکھیں۔
ترقی کے عمل میں سب سے اہم چیز یہ ہے کہ اپنے آپ کو وقت پر شکست دیں اور شروع سے پورے کوڈ کو دوبارہ لکھنے کی کوشش نہ کریں۔ اندازہ لگائیں کہ اس کے لیے کتنے سال درکار ہوں گے۔ اس بات کا امکان نہیں ہے کہ گاہک پہلے سے کام کرنے والی کسی چیز کو دوبارہ کرنے پر اتنا پیسہ خرچ کرنا چاہے گا۔ یہ نہ صرف پورے نظام پر لاگو ہوتا ہے، بلکہ اس کے کسی بھی حصے پر بھی لاگو ہوتا ہے۔ یقینا، وہ آپ کو ہر چیز کا پتہ لگانے کے لیے ایک ہفتہ اور کچھ ٹھیک کرنے کے لیے ایک اور ہفتہ دے سکتے ہیں۔ لیکن وہ آپ کو دوبارہ سسٹم کا حصہ لکھنے کے لیے دو ماہ کا وقت نہیں دیں گے۔ اس کے بجائے، باقی کوڈ کی طرح نئی فعالیت کو اسی انداز میں نافذ کریں۔ دوسرے الفاظ میں، اگر کوڈ پرانا ہے، تو آپ کو نئی خوبصورت ٹیکنالوجیز استعمال کرنے کا لالچ نہیں ہونا چاہیے: اس طرح کے کوڈ کو پڑھنا بہت مشکل ہوگا۔ مثال کے طور پر، آپ کو ایسی صورت حال کا سامنا کرنا پڑ سکتا ہے جیسا کہ ہمارے پاس تھا: سسٹم کا کچھ حصہ اسپرنگ MVC میں لکھا گیا ہے، اور کچھ حصہ ننگے سرولیٹ میں لکھا گیا ہے۔ اور اگر servlets میں لکھے ہوئے حصے میں، کچھ اور شامل کرنے کی ضرورت ہے، تو ہم اسے اسی طرح - servlets میں شامل کرتے ہیں۔کاروباری مفادات کا احترام کریں۔
یہ یاد رکھنا چاہیے کہ کسی بھی کام کا تعین سب سے پہلے، کاروبار کی قدر کے لحاظ سے کیا جاتا ہے۔ اگر آپ گاہک کو کاروباری نقطہ نظر سے کچھ تبدیلیوں کی ضرورت ثابت نہیں کرتے ہیں، تو یہ تبدیلیاں نہیں ہوں گی۔ اور گاہک کو قائل کرنے کے لیے، آپ کو اس کی جگہ پر کھڑے ہونے اور اس کے مفادات کو سمجھنے کی کوشش کرنی چاہیے۔ خاص طور پر، اگر آپ صرف اس وجہ سے ریفیکٹر کرنا چاہتے ہیں کہ کوڈ کو پڑھنا مشکل ہے، تو آپ کو ایسا کرنے کی اجازت نہیں ہوگی، اور آپ کو اس کے ساتھ رہنا ہوگا۔ اگر آپ واقعی اسے برداشت نہیں کر سکتے ہیں، تو آپ کوڈ کو خاموشی سے اور آہستہ آہستہ دوبارہ ترتیب دے سکتے ہیں، کام کو کاروباری ٹکٹوں میں پھیلاتے ہوئے یا گاہک کو قائل کریں کہ یہ، مثال کے طور پر، غلطیوں کو تلاش کرنے کے لیے درکار وقت کو کم کر دے گا، اور اس لیے بالآخر اخراجات کم ہو جائیں گے۔پرکھ
یہ واضح ہے کہ کسی بھی منصوبے میں جانچ ضروری ہے۔ لیکن میراثی نظاموں کے ساتھ کام کرتے وقت، جانچ پر بھی خصوصی توجہ دی جانی چاہیے کیونکہ تبدیلیوں کے اثرات کا ہمیشہ اندازہ نہیں لگایا جا سکتا۔ آپ کو کم از کم اتنے ٹیسٹرز کی ضرورت ہوگی جتنے ڈویلپرز، ورنہ آپ کو آٹومیشن میں ناقابل یقین حد تک اچھا ہونا چاہیے۔ ہمارے پروجیکٹ میں، جانچ درج ذیل مراحل پر مشتمل ہے:- تصدیق، جب کسی خصوصیت کی نافذ کردہ فعالیت کو علیحدہ برانچ میں چیک کیا جاتا ہے۔
- استحکام، جب ایک ریلیز برانچ کی جانچ پڑتال کی جاتی ہے جس میں تمام خصوصیات ایک ساتھ ضم ہوجاتی ہیں۔
- سرٹیفیکیشن، جب ایک ہی چیز کو سرٹیفیکیشن ماحول میں تھوڑا سا مختلف ٹیسٹ کیسز پر دوبارہ چلایا جاتا ہے جو ہارڈ ویئر کی خصوصیات اور ترتیب کے لحاظ سے پیداوار کے جتنا ممکن ہو.
ڈی او اوپس کو باقاعدہ بنائیں اور ریلیز کریں۔
رہائی کا طریقہ کار، مثال کے طور پر، مندرجہ ذیل ہو سکتا ہے۔ جب ڈیولپمنٹ مکمل ہو جاتی ہے اور دو یا تین ٹیسٹنگ مراحل مکمل ہو جاتے ہیں، تو ہم متوقع ریلیز کے وقت سے 36 گھنٹے پہلے DevOps ٹیم کو ای میل لکھتے ہیں۔ اس کے بعد، ہم ڈیوپس ٹیم کو کال کرتے ہیں اور ماحول میں ہونے والی تمام تبدیلیوں پر تبادلہ خیال کرتے ہیں (ہم انہیں ڈیٹا بیس اور کنفیگریشن میں ہونے والی تمام تبدیلیوں سے آگاہ کرتے ہیں)۔ ہر تبدیلی کے لیے ہمارے پاس ایک دستاویز ہے (جیرا میں ٹکٹ)۔ پھر، ریلیز کے دوران، اس میں شامل ہر شخص اکٹھا ہو جاتا ہے، اور ہر کوئی کہتا ہے کہ وہ اب کیا کر رہے ہیں: "ہم نے ڈیٹا بیس کو اپ لوڈ کیا،" "ہم نے فلاں فلاں سرورز کو دوبارہ شروع کیا،" "ہم پروڈکشن ماحول میں ریگریشن ٹیسٹ چلانے گئے۔ " اگر کچھ غلط ہو جاتا ہے تو، ریلیز رول بیک طریقہ کار شروع کیا جاتا ہے، بالکل اصل ریلیز دستاویز میں بیان کیا گیا ہے - ایسی دستاویز کے بغیر ہم یقینی طور پر کچھ بھول جائیں گے یا الجھن میں پڑ جائیں گے۔کوڈ کے معیار کو کنٹرول کریں۔
اور آخر میں، کوڈ کا جائزہ ایک ایسا عمل ہے جو کسی وجہ سے تمام منصوبوں میں استعمال نہیں ہوتا ہے۔ یہ بہت اچھا ہے اگر کوڈ کے ہر ٹکڑے کا ایک سے زیادہ افراد جائزہ لیں۔ یہاں تک کہ ایک بہت مضبوط ٹیم میں، کچھ کیڑے ہمیشہ کوڈ کے جائزے کے عمل کے دوران دریافت کیے جاتے ہیں، اور اگر بہت سے لوگ اس پر نظر ڈالیں، تو شناخت شدہ کیڑوں کی تعداد بڑھ جاتی ہے۔ مزید یہ کہ بعض اوقات تیسرے یا چوتھے جائزہ لینے والے کو بدترین چیز مل جاتی ہے۔ٹولز جو تکنیکی دستاویزات لکھنے کو آسان بناتے ہیں۔
ماخذ: Dzone زیادہ تر پروگرامرز تکنیکی دستاویزات لکھنا پسند نہیں کرتے۔ ماہر نفسیات جیرالڈ وینبرگ نے یہاں تک کہ دستاویزات کو "پروگرامنگ کا کیسٹر آئل" کہا: ڈویلپر اسے پڑھنا پسند کرتے ہیں، لیکن وہ اسے خود لکھنے سے نفرت کرتے ہیں۔
رہنمائی کی کمی یا خالی روڈ میپ کے نتیجے میں سافٹ ویئر کے مختلف حصوں کے کام کرنے کے بارے میں معلومات کی کمی ہوتی ہے۔ یہ بالآخر کوڈ کے آخری صارفین کے لیے تجربہ کو خراب کر دیتا ہے کیونکہ، دستاویزات کی عدم موجودگی میں، وہ پروڈکٹ کی درستگی اور افادیت پر بھروسہ نہیں کر سکتے۔ پروگرامرز کے لیے دستاویزات لکھنے کی عادت کو آسان بنانے کے لیے، میں چار بہترین ٹولز پر توجہ دینے کی تجویز کرتا ہوں جو اب تقریباً ہر ایک کے لیے دستیاب ہیں۔
GO TO FULL VERSION