پہیے کو دوبارہ ایجاد کرنا کیوں مفید ہے؟

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

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

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

ڈویلپر تیار شدہ کوڈ کو خود واضح سمجھتے ہیں۔

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

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

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

return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});

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

جڑوں پر واپس جائیں۔

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

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

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

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

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

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

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

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

اس پہیے کو دوبارہ ایجاد کریں۔

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

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

ماخذ: www.habr.com