نوسکھئیے پروگرامرز کی عام غلطیوں کا تجزیہ: حصہ 1

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

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

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

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

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

3. بلائنڈ کاپی پیسٹ

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

4. غلط حل پھینکنا

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

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

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

6. ٹیم کی قیادت سے بہت زیادہ توقعات رکھنا

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

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

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

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

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

8. حل کو غلط کرنے کا رجحان

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

9. سائیکل کی ایجاد

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

10. ٹیسٹ نہ لکھیں۔

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

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

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

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

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

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

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