نوسکھئیے پروگرامرز کی طرف سے کی جانے والی عام غلطیوں کا تجزیہ، pt. 1

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

1. زیادہ تجربہ کار ساتھیوں سے مدد لینے کا خوف

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

2. اپنے طور پر معلومات تلاش کرنے کی کوشش نہیں کرنا

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

3. آنکھیں بند کرکے کاپی اور پیسٹ کرنا

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

4. غلط حل کے ساتھ چپکی ہوئی

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

5. اپنی موجودہ تفویض کے بارے میں سوالات پوچھنے کا خوف

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

6. ٹیم کی قیادت پر غیر حقیقی طور پر زیادہ توقعات رکھنا

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

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

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

7. کوڈ کے جائزوں کا خوف

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

8. عجیب فیصلوں کا رجحان

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

9. پہیے کو دوبارہ ایجاد کرنا

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

10. ٹیسٹ لکھنے میں ناکامی

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

11. ضرورت سے زیادہ تبصرے

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

Cat cat = new Cat(); // Cat object

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

12. برا نام رکھنا

نوزائیدہ افراد اپنی کلاسوں، متغیرات، طریقوں وغیرہ کے نام دینے میں تیز اور ڈھیلے کھیلتے ہیں۔ مثال کے طور پر، ایک ایسی کلاس بنا کر جس کا نام بالکل بھی اس کے مقصد کو بیان نہیں کرتا ہے۔ یا وہ ایک مختصر نام کے ساتھ متغیر کا اعلان کرتے ہیں، جیسے کچھ x ۔ وہ جب n اور y نامی دو اور متغیرات بنائے جاتے ہیں، تو یاد رکھنا بہت مشکل ہو جاتا ہے کہ x کس چیز کے لیے ذمہ دار ہے۔ اس صورت حال کا سامنا کرتے ہوئے، آپ کو کوڈ کے بارے میں احتیاط سے سوچنا ہوگا، اسے مائکروسکوپ کے نیچے تجزیہ کرنا ہوگا (شاید ڈیبگر کا استعمال کرتے ہوئے)، فعالیت کا مطالعہ کرنا ہوگا تاکہ یہ سمجھ سکیں کہ کیا ہو رہا ہے۔ یہ وہ جگہ ہے جہاں نام دینے کے صحیح کنونشنز جن کا میں نے اوپر ذکر کیا ہے ہماری مدد کرتے ہیں۔ درست نام کوڈ کی پڑھنے کی اہلیت کو بہتر بناتے ہیں، اس طرح اپنے آپ کو کوڈ سے واقف کرنے کے لیے درکار وقت کو کم کرتے ہیں، کیونکہ کسی طریقہ کا استعمال اس وقت بہت آسان ہوتا ہے جب اس کا نام اس کی فعالیت کو تقریباً بیان کرتا ہو۔ کوڈ میں موجود ہر چیز ناموں (متغیرات، طریقے، کلاسز، اشیاء، فائلز وغیرہ) پر مشتمل ہوتی ہے، اس لیے درست، صاف کوڈ بناتے وقت یہ نکتہ بہت اہم ہو جاتا ہے۔ آپ کو یاد رکھنا چاہئے کہ نام کا مطلب ہونا چاہئے، مثال کے طور پر، متغیر کیوں موجود ہے، یہ کیا کرتا ہے، اور اسے کیسے استعمال کیا جاتا ہے۔ میں ایک سے زیادہ بار نوٹ کروں گا کہ متغیر کے لیے بہترین تبصرہ اسے اچھا نام دینا ہے۔ تبصروں اور درست ناموں کے گہرے مطالعہ کے لیے، میں لازوال کلاسیکی پڑھنے کی سفارش کرتا ہوں: "کلین کوڈ: اے ہینڈ بک آف ایگیل سافٹ ویئر کرافٹسمینشپ" از رابرٹ مارٹن ۔ اس نوٹ پر، اس مضمون کا پہلا حصہ (میرے مظاہر) ختم ہو گیا ہے۔ جاری ہے...