کسی ایسی چیز کو تیار کرنے پر متفق نہ ہوں جو آپ نہیں سمجھتے ہیں۔

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

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

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

اگرچہ آپ کو ذیل میں کوڈ کی ایک بھی سطر نظر نہیں آئے گی، مجھے پھر بھی یقین ہے کہ یہاں جو کچھ بھی کہا گیا ہے وہ اعلیٰ معیار، اظہار خیال کوڈ لکھنے کے لیے بہت اہمیت رکھتا ہے۔

سمجھ کا پہلا درجہ: یہ کام کیوں نہیں کرتا؟

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

معیاری اسکیم اس طرح نظر آتی ہے:

1. کوڈ کا وہ ٹکڑا تلاش کریں جو مسئلہ پیدا کر رہا ہے (یہ کیسے کریں یہ ایک الگ موضوع ہے، میں نے اسے میراثی کوڈ کے بارے میں اپنی کتاب میں شامل کیا ہے)
2. اس ٹکڑوں میں تبدیلیاں کریں۔
3. اس بات کو یقینی بنائیں کہ بگ ٹھیک ہو گیا ہے اور کوئی رجعت کی خرابی نہیں ہوئی ہے۔

اب آئیے دوسرے نکتے پر توجہ مرکوز کرتے ہیں - کوڈ میں تبدیلیاں کرنا۔ اس عمل کے دو طریقے ہیں۔ سب سے پہلے یہ معلوم کرنا ہے کہ موجودہ کوڈ میں بالکل کیا ہو رہا ہے، غلطی کی نشاندہی کریں اور اسے ٹھیک کریں۔ دوسرا: احساس کے ذریعے منتقل کریں - مشروط بیان یا لوپ میں شامل کریں، بولیں، +1 کریں، دیکھیں کہ آیا فنکشن مطلوبہ منظر نامے میں کام کرتا ہے، پھر کچھ اور آزمائیں، وغیرہ وغیرہ۔

پہلا طریقہ درست ہے۔ جیسا کہ Steve McConnell اپنی کتاب Code Complete (جس کی میں بہت زیادہ سفارش کرتا ہوں، ویسے) میں وضاحت کرتا ہے، جب بھی ہم کوڈ میں کچھ تبدیل کرتے ہیں، تو ہمیں اعتماد کے ساتھ یہ پیش گوئی کرنے کے قابل ہونا چاہیے کہ اس کا اطلاق پر کیا اثر پڑے گا۔ میں میموری سے حوالہ دے رہا ہوں، لیکن اگر کوئی بگ فکس آپ کی توقع کے مطابق کام نہیں کرتا ہے، تو آپ کو بہت گھبرانا چاہیے اور آپ کو اپنے پورے ایکشن پلان پر سوال کرنا چاہیے۔

جو کچھ کہا گیا ہے اس کا خلاصہ کرنے کے لیے، ایک اچھے بگ فکس کو انجام دینے کے لیے جو کوڈ کے معیار کو خراب نہ کرے، آپ کو کوڈ کی پوری ساخت اور مخصوص مسئلے کے ماخذ دونوں کو سمجھنے کی ضرورت ہے۔

تفہیم کا دوسرا درجہ: یہ کیوں کام کرتا ہے؟

اس سطح کو پچھلی سطح سے بہت کم بدیہی طور پر سمجھا جاتا ہے۔ میں نے، جب کہ ابھی بھی ایک نیا ڈویلپر تھا، اسے اپنے باس کی بدولت سیکھا، اور اس کے بعد بار بار نئے آنے والوں کو اس معاملے کے جوہر کی وضاحت کی۔

اس بار، آئیے تصور کریں کہ آپ کو ایک ساتھ دو بگ رپورٹس موصول ہوئی ہیں: پہلی منظرنامہ A کے بارے میں ہے، دوسری منظرنامہ B کے بارے میں ہے۔ دونوں منظرناموں میں، کچھ غلط ہوتا ہے۔ اس کے مطابق، آپ پہلے پہلے بگ سے نمٹتے ہیں۔ لیول XNUMX کی تفہیم کے لیے ہم نے جو اصول تیار کیے ہیں ان کا استعمال کرتے ہوئے، آپ مسئلے سے متعلقہ کوڈ کی گہرائی میں کھوج لگائیں، یہ معلوم کریں کہ کیوں اس کی وجہ سے ایپلیکیشن کا برتاؤ منظر نامہ A میں ہوتا ہے، اور مناسب ایڈجسٹمنٹ کریں جو آپ کے مطلوبہ نتائج کو پیش کریں۔ . سب کچھ بہت اچھا چل رہا ہے۔

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

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

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

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

تفہیم کی تیسری سطح: یہ کیوں کام کرتا ہے؟

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

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

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

اور کسی موقع پر آپ کو اچانک احساس ہوتا ہے - یا شاید کسی سے سنتے ہیں - کہ شاید فریم ورک F آپ کو فیچر X کے ساتھ بالکل بھی مطابقت نہیں دے گا۔ ہو سکتا ہے کہ وہ سارا وقت اور کوشش اس میں بالکل غلط لگائی گئی ہو۔

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

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

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

فہم کا چوتھا درجہ: ???

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

ماخذ: www.habr.com