عام غلطين جو تجزيو نويس پروگرامرز پاران، پي ٽي. 1

هيلو، دنيا! هڪ دفعو توهان سڀ ڪجهه سکيو آهي جيڪو توهان کي ڄاڻڻ جي ضرورت آهي ۽ آخرڪار هڪ انٽرنيشنل يا جونيئر ديو جي حيثيت سان ڪم ڪرڻ لاء، توهان شايد آرام ڪري سگهو ٿا، صحيح؟ نه. سڀ ڪجھ توھان جي لاءِ شروع ٿي رھيو آھي... توھان گھيرو آھيو گھيرو جيڪو نئون ۽ سمجھ کان ٻاهر آھي. توهان ان کي دروازي کان ٻاهر ڪيئن نه ڇڪايو؟ اهو آهي جيڪو اسان اڄ بابت ڳالهائڻ وارا آهيون. هن آرٽيڪل ۾، آئون عام روڪي غلطين جو تجزيو ڪرڻ چاهيان ٿو ۽ ڪجهه صلاح ڏيان ٿو، منهنجي پنهنجي تجربي جي بنياد تي، انهن کان بچڻ جي باري ۾. تنهن ڪري، اچو ته بغير ڪنهن وڌيڪ اشتهار جي شروع ڪريون:

1. وڌيڪ تجربيڪار ساٿين کان مدد طلب ڪرڻ کان ڊپ

اسان سڀ انسان آهيون. اسان سڀ بيوقوف ڏسڻ کان ڊڄون ٿا، خاص طور تي اسان جي نئين، وڌيڪ تجربيڪار ساٿين جي نظر ۾. جڏهن ڊولپرز پنهنجي پهرين نوڪري وٺن ٿا، اهي اڪثر ڪري هن خوف جي رهنمائي ڪن ٿا ۽، ڳري ٻڌي، پاڻ ۾ واپس وٺي، هر شيء کي پنهنجي پاڻ تي سمجهڻ جي ڪوشش ڪري رهيا آهن. اضافي طور تي، ڪو ماڻهو وڌيڪ تجربيڪار ساٿين جي ڀرسان ٿي سگهي ٿو، جيڪي، موڙ ۾، هن کي يا ان کي سڀ کان وڌيڪ واعدو هدايت ۾ اشارو ڪرڻ جي قابل آهن، وڌيڪ غلطي ۽ غير ضروري "سر تي bumps" کان بچڻ ۾ مدد ڪن ٿيون. تنهن ڪري ياد رکو: سوال پڇڻ کان نه ڊڄو. توهان هڪ شروعاتي آهيو ۽ هرڪو اهو چڱي طرح سمجهي ٿو. جڏهن پڇيائين ته ڪو به توهان کي لٺن سان مارڻ وارو ناهي. ٿي سگهي ٿو ته ان جي ابتڙ به ٿي سگهي ٿو: توهان وڌيڪ جلدي پنهنجي ساٿين سان دوست بڻجي ويندا ۽ انهن سان وڌيڪ فعال رابطي جو لطف اندوز ٿيڻ شروع ڪيو. مان اڃا به وڌيڪ چوندس: جيترو وڌيڪ توهان مختلف ٽيڪنيڪل مسئلن کان پڇو ۽ بحث ڪيو، اوترو ئي تيز توهان پنهنجي سائي نئين چمڙي کي صاف ڪري سگهندا ۽ پنهنجي فيلڊ ۾ هڪ ماهر بڻجي ويندا. ۽ هڪ وڌيڪ صلاح. StackOverflow لاءِ اجنبي نه ٿيو . مان خاص طور تي هن وسيلن تي سوال پڇڻ بابت ڳالهائي رهيو آهيان. هڪ پاسي، اهو توهان جي سوال جو جواب حاصل ڪرڻ لاء ڪجهه وقت وٺندو آهي. پر ٻئي طرف، توهان شايد جلدي سکندا ڪيترائي طريقا توهان جي مسئلي کي حل ڪرڻ ۽ ان کي ٿوري مختلف زاوي کان ڏسو. مان اهو پڻ نوٽ ڪرڻ چاهيان ٿو ته تبصرو/جواب لکڻ ۽ ٻين ڊولپرز کان StackOverflow سوالن تي واضح سوالن کي لکڻ جا عملي فائدا آهن: توهان کي بحث ڪرڻ جو موقعو ملندو آهي ۽ مسئلن ۾ وڌيڪ گہرا غور ڪرڻ، نه ته ڪرما واڌ جو ذڪر ڪرڻ لاءِ.

2. پاڻ تي معلومات ڳولڻ جي ڪوشش نه ڪريو

هن غلطي کي پوئين هڪ جي flipside سمجهي سگهجي ٿو. هتي منهنجو مطلب اهو آهي ته جڏهن توهان پنهنجي ساٿين ۽ واقفڪارن کي هر مسئلي يا هچڪي جي باري ۾ پريشان ڪرڻ شروع ڪندا آهيو. پڇڻ سٺو آهي، پر سوالن سان گڏ نه وڃو. ٻي صورت ۾، ماڻهو شايد توهان کي پريشان ڪندڙ ڳولي سگھن ٿا. جيڪڏهن توهان ڪنهن شيءِ جي باري ۾ پريشان ٿي وڃو، سڀ کان پهرين ڪم ڪرڻ آهي توهان جي ڳولا جي صلاحيتن کي بهترين سرچ انجڻ - گوگل ۾. ڪو ٻيو ماڻهو اڳ ۾ ئي ناقابل فهم غلطين ۽ ٻين مسئلن جي وڏي اڪثريت کي منهن ڏئي چڪو آهي. ۽ توهان حيران ٿي ويندا جيڪڏهن توهان پنهنجو سوال گوگل ڪيو ۽ انهن ماڻهن جو تعداد ڏسو جيڪي هڪ جهڙي مسئلي کان واقف آهن، ۽ جن کي پهريان ئي مڪمل جواب ملي چڪا آهن جيڪي توهان پنهنجي ڪم ۾ لاڳو ڪري سگهو ٿا. اهو ئي سبب آهي ته توهان اڪثر ٻڌندا آهيو ته توهان جي ساٿين جو جواب "گوگل ان" سان. هن جواب تي ناراض نه ٿيو - توهان جو ساٿي توهان جو ذاتي استاد نه آهي جنهن کي توهان جي ڪم جي فيلڊ جي سڀني ذخيري کي پهچائڻ گهرجي. انٽرنيٽ جي لامحدود توسيع توهان جي مرشد هوندي. ڪڏهن ڪڏهن پروگرامرز کي گوگل سرچ ۾ بليڪ بيلٽ وارا ماڻهو به چيو ويندو آهي . تنهن ڪري جيڪڏهن اسان کي "هچڪي" آهي، اسان پهريون ڀيرو گوگل جو مسئلو آهي. جيڪڏهن ڪو حل نه ملي سگهي (اهو نادر آهي، پر اهو ٿئي ٿو)، صرف پوء اسان ساٿين کان پڇڻ شروع ڪريون ٿا. فوري سوال مشوري حاصل ڪرڻ لاءِ آهن ته توهان کي ڪنهن مسئلي کي حل ڪرڻ لاءِ ڪهڙو طريقو اختيار ڪرڻ گهرجي ان کان وڌيڪ ته توهان ڇا ڪندا جڏهن توهان هڪ اسپيڊ ٽمپ يا هڪ ناقابل فهم نقص پيغام کي ماريو. آخرڪار، اهي شايد توهان جي پسنديده طريقي کان ٻاهر ڏسڻ جي قابل هوندا ۽ فوري طور تي اڳڪٿي ڪن ٿا ته ڪنهن به ڏنل طريقي سان ڊگهي عرصي ۾ ڏسندي.

3. انڌي طرح ڪاپي ۽ پيسٽ ڪرڻ

پر گوگلنگ جا مسئلا ۽ انهن جا حل ان جا نقصان آهن. مثال طور، انڌا ڪاپي ۽ پيسٽ ڪرڻ . اهو عام طور تي ٿئي ٿو جڏهن توهان هڪجهڙائي وارو مسئلو ڳوليندا آهيو (پر شايد شايد ساڳيو نه هجي) ۽ هڪ لاڳاپيل حل، مثال طور، StackOverflow تي. توهان هن حل کي پڪڙيو ۽ ان کي ڪاپي ۽ پيسٽ ڪريو بغير تفصيل ۾ وڌيڪ ڊيلنگ ڪرڻ جي. ۽ پوءِ توهان يا توهان جا همراهه توهان جي ڪوڊ ۾ ڪجهه عجيب ڪيڙا يا غلط رويو ڳوليندا. ۽ ڪو به فوري طور تي اندازو نٿو ڪري سگهي ته اهي ڪٿان آيا آهن. آخرڪار، يقينا، ڪاپي ٿيل ڪوڊ سان جڳهه ملي ويندي، ۽ توهان کي يقيني طور تي توهان جي حل جي ساراهه نه ڪئي ويندي. تنهن ڪري، جڏهن توهان StackOverflow (يا ڪنهن ٻئي هنڌ) تي تيار ڪيل حل ڳوليندا آهيو، توهان کي پهريان چڱي طرح سمجهڻ گهرجي ته ڇا، ڪيئن، ۽ ڇو. شايد گوگل سان لاڳاپيل ڪارڪردگي ۽ ان لاءِ دستاويز پڙهو. ۽ صرف ان کان پوءِ جيڪو توھان ڪيو آھي توھان کي ان کي پنھنجي منصوبي ۾ شامل ڪرڻ گھرجي.

4. غلط حل سان لٺڻ

جڏهن هڪ حل لکندو، توهان کي ڪڏهن ڪڏهن اهو معلوم ٿيندو ته اهو مسلسل وڌيڪ ۽ وڌيڪ پيچيده ٿي رهيو آهي، آخرڪار هڪ مئل آخر تائين پهچي ٿو. ۽ پوءِ توھان ڪوشش ڪريو حل کي اڃا وڌيڪ تفصيلي بڻائڻ لاءِ ته جيئن اھو ڪم ڪري سگھي بجاءِ ٻيو ، وڌيڪ مناسب متبادل ڳولڻ جي. ٿي سگهي ٿو ته توهان محسوس ڪيو ته توهان تمام گهڻو وقت ۽ ڪوشش ڪئي آهي ۽ تنهن ڪري اهو فيصلو ڪيو آهي ته، ڪنهن به صورت ۾، توهان نه ڇڏيندؤ ۽ توهان پنهنجي موجوده طريقي سان مسئلو حل ڪنداسين. اهو بلڪل صحيح رويو ناهي. گهٽ ۾ گهٽ پروگرامنگ ۾. جيترو جلدي توهان هڪ مختلف طريقي جي ڪوشش ڪندا، وڌيڪ وقت توهان آخر ۾ بچائيندا. تنهن ڪري تجربا ڪرڻ کان نه ڊڄو ۽ ٻين طريقن جي ڪوشش ڪريو، قطع نظر ته توهان پنهنجي موجوده هڪ ۾ وقت جي رقم خرچ ڪيو آهي. وڌيڪ ڇا آهي، ڪيترن ئي طريقن جي ڪوشش ڪندي ۽ موضوع ۾ وڌيڪ گہرے ڊائيونگ ڪندي، توهان پنهنجي تجربي جي سور واري ڪناري ۾ پوائنٽون گڏ ڪندا.

5. توهان جي موجوده تفويض بابت سوال پڇڻ کان ڊپ

سافٽ ويئر ڊولپمينٽ پروجيڪٽ تي ڪم ڪرڻ عام طور تي خاص ڪمن کي انجام ڏيڻ لاءِ هيٺ اچي ٿو. مثال طور، جيرا ۾ . اهي ڪم هميشه واضح ۽ تفصيل سان بيان نه ڪيا ويا آهن. ٽاسڪ وضاحتون عام طور تي ٽيم جي اڳواڻن پاران لکيل آهن، جيڪي پڻ صرف مرڻ وارا آهن. اهي شايد ڪجهه شامل ڪرڻ وساري سگهن ٿا يا حقيقت جي حساب ۾ ناڪام ٿي سگهن ٿا ته توهان هن يا انهي ڪارڪردگي سان واقف نه آهيو. يا شايد توهان وٽ پروجيڪٽ تائين ڪا به رسائي نه آهي (مثال طور، ڊيٽابيس تائين رسائي، لاگ سرور، وغيره). ۽ هاڻي، توهان کي اهو ڪم ملي ويو آهي، ان کي ٻه ڪلاڪ کان وڌيڪ مطالعو ڪيو، پر توهان اڃا تائين اتي ويٺا آهيو، اسڪرين ڏانهن حيران ٿي ويا آهيو. انهي کي سمجهڻ جي ناڪام ڪوشش ڪرڻ جي بدران، توهان کي وضاحت ڪرڻ يا هدايت لاء پڇڻ شروع ڪرڻ گهرجي جنهن به ڪم ٺاهيو آهي. مثال طور، ايپ ۾ جيڪا توهان جي ٽيم ڪميونيڪيشن لاءِ استعمال ڪري ٿي (مثال طور Microsoft ٽيمون)، توهان شايد سوال پڇي سگهو ٿا يا ڪم جي حوالي سان سڌو تبصرو ڪري سگهو ٿا. هڪ پاسي، جيڪڏهن توهان پنهنجو سوال هڪ ذاتي پيغام ۾ لکندا، توهان کي شايد جلدي جواب ملندو، ڇو ته اهو شخص توهان جي سوال کي فوري طور تي ڏسي سگهندو. ٻئي طرف، جيرا ۾ هڪ سوال پڇڻ سان، توهان ثابت ڪيو ته توهان ڪجهه ڪري رهيا آهيو، يعني، مسئلي جو تجزيو. ھن عمل کي تيز ڪرڻ جو ھڪڙو طريقو آھي: پنھنجي سوال جيرا ۾ تبصري ۾ ۽ پوءِ DM ۾، پنھنجي تبصري جي لنڪ کي ڇڏي ڏيو ۽ ھڪ نظر وٺڻ لاءِ پڇو.

6. ٽيم جي اڳواڻي تي غير حقيقي طور تي وڏيون اميدون رکڻ

ٻيهر، هي پوئين نقطي جي فلپ طرف آهي. ٽيم جي اڳواڻي هڪ ترقياتي ٽيم جو سربراهه آهي. ضابطي جي طور تي، توهان جي ٽيم جي اڳواڻي پنهنجي وقت جو گهڻو حصو مختلف قسم جي مواصلات تي خرچ ڪري ٿو. اڃان تائين، هو يا هوء پڻ ڪوڊ لکي ٿو ته جيئن پروگرامنگ بابت سڀ ڪجهه نه وساريو. جئين توهان سمجهي سگهو ٿا، ٽيم جي اڳواڻي جي زندگي تمام مصروف آهي. توهان جي ٽيم جي ليڊ جي آستين تي ڇڪڻ هر وقت توهان کي ڇڪڻ جي ضرورت آهي واضح طور تي خوشگوار نه ٿيندو. تصور ڪريو ٽيم جي هر ميمبر جي اڳواڻي تي بمباري ڪندي ڪيترن ئي سوالن سان. اهو ڪنهن کي چريو ڪري سگهي ٿو، صحيح؟ ۽ جيڪڏھن توھان گھڻن سوالن تي ڍير ڪريو ٿا، ته توھان جي ٽيم جي اڳواڻي کي توھان کي جواب ڏيڻ ۾ گھڻو وقت خرچ ڪرڻو پوندو. ٽيم جي اڳواڻي ۾ هدايت ڪيل سوالن جي تعداد کي گهٽائڻ لاء ڇا ڪري سگهجي ٿو:

• پروجيڪٽ جي دستاويزن کي وڌيڪ کوٽائي ۾ ڳولھيو ته جيئن انڌن جي تعداد کي گھٽايو وڃي.
• پنھنجي سوالن کي پنھنجي ٽيم جي ٻين ميمبرن ڏانھن سڌو ڪريو. اهي شايد هن فنڪشنلٽي کان واقف هجن جيئن ليڊ آهي، يا ممڪن آهي ته ان کان به وڌيڪ، ڇاڪاڻ ته ڪارڪردگي گهڻو ڪري انهن مان هڪ طرفان لکيو ويو هو.

متبادل طور تي، توهان IDE ۾ تشريحون ڏسي سگهو ٿا ته ڪنهن مخصوص لائن ۾ ڪوڊ آخري ڀيرو تبديل ڪيو ويو. اهو خاص طور تي توهان ڪيئن ڳولي سگهو ٿا ته توهان جو سوال پڇڻ لاء سڀ کان وڌيڪ مناسب شخص ڪير آهي. جيئن ته توهان شايد اڳ ۾ ئي محسوس ڪيو آهي، جڏهن اهو سوالن جي ٽيم جي اڳواڻي ۾ اچي ٿو، جيئن ساٿين جي سوالن سان، توهان کي هڪ خوشگوار وچولي ڳولڻ جي ڪوشش ڪرڻ جي ضرورت آهي - سوال پڇڻ کان نه ڊڄو، پر تمام گهڻو نه پڇو. انهن مان.

7. ڪوڊ جي نظرثانين جو خوف

ڪوڊ جو جائزو هڪ اهڙو مرحلو آهي جيڪو توهان کان اڳ ٿئي ٿو توهان جو ڪوڊ هڪ عام ايپليڪيشن ۾ جمع ڪرايو (هڪ گڏيل شاخ ڏانهن، مثال طور، ماسٽر يا ديو). هي چيڪ هڪ ڊولپر طرفان ڪيو ويو آهي جيڪو ڪم ۾ شامل نه آهي، جنهن جون تازيون اکيون توهان جي ڪوڊ جي انداز ۾ غلطيون، غلطيون، يا خاميون ڳولي سگهن ٿيون جيڪي توهان جي ڪوڊ جي شروعات ۾ توهان جي ڪوڊ جي انداز ۾ نظر نه آيا. جيڪڏهن اتي تنقيدون آهن، اهي ڪوڊ جي ڪجهه حصن تي تبصرن جي طور تي ڇڏي ويا آهن. انهي صورت ۾، ڊولپر جيڪو ڪوڊ لکيو آهي ان کي درست ڪرڻ گهرجي نظرثاني ۾ سڃاڻپ ٿيل غلطيون (يا نظرثاني ڪندڙ سان سندس فيصلن تي بحث ڪندي، ممڪن آهي ته هن کي قائل ڪري ته اهي صحيح آهن). پوءِ ڪوڊ ٻيهر نظرثاني لاءِ پيش ڪيو ويندو آهي جيستائين نظرثاني ڪندڙ وڌيڪ تبصرو نه ڪندو آهي. نظر ثاني ڪندڙ "گيٽ وي" جي طور تي ڪم ڪري ٿو ان کان اڳ جو ڪوڊ انجام ڏنو وڃي. چيلنج اهو آهي ته ڪيترائي نوان پروگرامر سمجهن ٿا ڪوڊ جو جائزو تنقيد ۽ مذمت جي طور تي. اهي ڪوڊ جي جائزي جي ساراهه نٿا ڪن ۽ انهن کان ڊڄن ٿا. انهن کي نه گهرجي. ڪوڊ جائزو بلڪل اھي آھن جيڪي اسان کي اسان جي ڪوڊ کي بهتر ڪرڻ ڏيو. آخرڪار، اسان کي اهم معلومات ملي ٿي ته اسان ڇا ڪري رهيا آهيون غلط آهي ۽ ڇا ڌيان ڏيڻ جي قابل آهي. توھان کي غور ڪرڻ گھرجي ھر ڪوڊ جي نظرثاني کي سکيا واري وکر جي حصي طور، ڪجھھ جيڪو توھان کي بھتر حاصل ڪرڻ ۾ مدد ڪري سگھي ٿو. جڏهن ڪو ماڻهو توهان جي ڪوڊ تي تبصرو ڪري ٿو، ته هو توهان سان تجربو ۽ بهترين طريقا شيئر ڪري رهيو آهي. مان ذاتي طور تي نه ٿو سمجهان ته توهان ڪوڊ جا جائزو وٺڻ کان سواءِ سٺو پروگرامر بڻجي سگهو ٿا. ڇو ته توهان پنهنجي ڪوڊ جي معيار کان به واقف نه آهيو ۽ ڇا هڪ تجربيڪار ٻاهران غلطين ڏانهن اشارو ڪندو.

8. عجيب فيصلا ڪرڻ جي صلاحيت

مختلف ڪم/مسئلا اڪثر ڪري سگھن ٿا مختلف حل. ۽ سڀني موجود حلن مان، شروعات ڪندڙ سڀ کان وڌيڪ پيچيده ۽ آرڪين وارا استعمال ڪندا آهن. ۽ اھو سمجھ ۾ اچي ٿو: نوان پروگرامر صرف ڪالهه ڪيترائي مختلف الگورتھم، نمونن، ۽ ڊيٽا جي جوڙجڪ سکيا، تنھنڪري انھن جي ھٿن کي انھن مان ڪجھ تي عمل ڪرڻ لاء خارش آھي. مون کي يقين ڪر، مان ائين ئي هو، تنهنڪري مون کي خبر آهي ته مان ڇا ڳالهائي رهيو آهيان :) مون وٽ هڪ صورتحال هئي جتي آئون ڊگهي وقت تائين ڪجهه ڪارڪردگي تي عمل ڪري رهيو آهيان. اهو ظاهر ٿيو تمام گهڻو، تمام پيچيده. پوءِ سينيئر ڊولپر منهنجو ڪوڊ ٻيهر لکيو. يقينن، مون کي ڏسڻ ۾ ڏاڍي دلچسپي هئي ته ڇا ۽ ڪيئن هن ان کي تبديل ڪيو. مون هن جي عمل کي ڏٺو ۽ حيران ٿي ويو ته اهو ڪيترو آسان هو. ۽ اتي ٽي ڀيرا گهٽ ڪوڊ هو. ۽ حيرت انگيز طور تي، هن ڪارڪردگي لاء خودڪار ٽيسٽ کي هٽايو يا تبديل نه ڪيو ويو! ٻين لفظن ۾، عام منطق ساڳي رهي. ان مان، مان ان نتيجي تي پهتو آهيان ته سڀ کان وڌيڪ ذهين حل هميشه سادو هوندا آهن . هن احساس کان پوء، ڪوڊنگ تمام گهڻو آسان ٿي ويو، ۽ منهنجي ڪوڊ جي معيار کي تمام گهڻو اعلي سطح تي ٽپو ڏنو. پوء جڏهن اهو قابل قدر آهي ته ڊزائن جي نمونن ۽ فينسي الگورتھم لاڳو ڪرڻ لاء، توهان پڇو؟ جڏهن انهن کي لاڳو ڪرڻ آسان ۽ سڀ کان وڌيڪ جامع حل هوندو.

9. ڦيٿي کي بحال ڪرڻ

ڦيٿي هڪ پائيدار حل آهي جيڪو هڪ ڊگهو وقت اڳ ايجاد ڪيو ويو هو. هن مخالف نموني ۾، ڊولپر ان مسئلي لاء پنهنجي ذاتي ملڪيت جو حل لاڳو ڪري ٿو جيڪو اڳ ۾ ئي حل ڪيو ويو آهي. ڪڏهن ڪڏهن اهي موجوده حل بهتر آهن جيڪي پروگرامر سان گڏ ايندا آهن. ضابطي جي طور تي، ڦيٿي کي بحال ڪرڻ وقت ضايع ٿيڻ ۽ پيداوار جي گھٽتائي جو سبب بڻجندو، ڇاڪاڻ ته جيڪو حل توهان ڳوليندا اهو ٿي سگهي ٿو تمام بهترين کان پري هجي، يا، چڱو، توهان کي شايد هڪ به نه ملي. اهو چيو ته، اسان پنهنجي آزاد حل ٺاهڻ جي امڪان کي رد نه ٿا ڪري سگهون: جيڪڏهن اسان ڪيو، ته پوء اهو سڀ ڪجهه ڇڏي ويندو ڪاپي ۽ پيسٽ پروگرامنگ. پروگرامر کي خاص پروگرامنگ ڪمن جي صحيح رهنمائي ڪرڻ گهرجي جيڪي پيدا ٿين ٿا انهن کي قابليت ۽ فوري طور تي حل ڪرڻ لاءِ، چاهي تيار ڪيل حل استعمال ڪندي يا ڪسٽم حل ٺاهي. هڪ طرف، يونيورسٽين ۾ ۽ آن لائين ڪورسز ۾، اسان کي مختلف قسمن جي ڪمن سان بمباري ڪئي وئي آهي، جيڪي اسان جي مدد ڪرڻ لاء ٺهيل نظر اچن ٿا. پر صرف پهرين نظر ۾: هتي اصل مقصد آهي الورورٿمڪ سوچ کي ترقي ڪرڻ ۽ ٻوليء جي نحو جي گهڻي مهارت. اھڙا ڪم توھان کي بھتر سمجھڻ ۾ مدد ڏين ٿا الورورٿمز ۽ ڊيٽا جي ڍانچي کي، ۽ جيڪڏھن ضروري ھجي ته وڌيڪ نفيس هم منصبن تي عمل ڪرڻ لاءِ توھان کي صلاحيتون ڏين (اھو ڪڏھن ڪڏھن ضروري آھي، پر اھو انتهائي ناياب آھي). حقيقي زندگي ۾، توهان کي ضرورت نه آهي ته توهان جي پنهنجي ڦيٿي کي وڏي اڪثريت ۾ ايجاد ڪيو وڃي، ڇو ته اهي ڦڙا جيڪي توهان جي ضرورتن کي پورا ڪن ٿا، ڪافي عرصي کان موجود آهن. ٿي سگهي ٿو توهان جي ناتجربيڪاري توهان کي گهربل ڪارڪردگي جي عملن جي وجود بابت ڄاڻڻ کان روڪي ٿي. هي اهو آهي جتي توهان کي هن مضمون جي پهرين نقطي ۾ ڏنل صلاح وٺڻ جي ضرورت آهي، يعني، مدد لاء وڌيڪ تجربيڪار ساٿين کان پڇو. اهي توهان جي رهنمائي ڪرڻ جي قابل هوندا (مثال طور، توهان کي توهان جي گوگل سرچ ۾ صحيح هدايت ڏانهن اشارو ڪيو) يا هڪ مخصوص عمل جي تجويز (مثال طور، ڪجهه لائبريري).

10. ٽيسٽ لکڻ ۾ ناڪامي

سڀئي نوان نوان لکڻ جي ٽيسٽ کي ناپسند ڪن ٿا. پر اسان کي هتي نوان نوان ڇو ڌار ڪرڻ گهرجن؟ وڌيڪ تجربيڪار ڊولپر به ٽيسٽ لکڻ پسند نٿا ڪن، پر اهي بهتر سمجهن ٿا ته ٽيسٽن جي ضرورت ڇو آهي. جڏهن توهان مڪمل طور تي سائي آهيو، توهان حيران ٿي رهيا آهيو ته توهان انهن کي ڇو لکڻ گهرجي. هر شي ڪم ڪري ٿي، تنهنڪري اتي ڪا غلطي نه ٿي سگهي. پر توهان ڪيئن پڪ ڪندا ته توهان جون تبديليون سسٽم ۾ ڪنهن ٻئي هنڌ کي ٽوڙي نه سگهندا؟ توهان جا ساٿي ان جي ساراهه نه ڪندا جيڪڏهن توهان انهن تبديلين کي وڌايو جيڪي سٺي کان وڌيڪ نقصان جو سبب بڻجن. هي آهي جتي ٽيسٽ اسان جي بچاء لاء ايندا آهن. وڌيڪ ايپليڪيشن جو ڪوڊ ٽيسٽن سان ڍڪيل آهي، بهتر (هن کي ڪوڊ ڪوريج يا ٽيسٽ ڪوريج سڏيو ويندو آهي). جيڪڏهن ايپليڪيشن ۾ سٺي ٽيسٽ ڪوريج آهي، ته پوءِ توهان انهن هنڌن کي ڳولڻ لاءِ سڀئي ٽيسٽ هلائي سگهو ٿا جيڪي توهان جي ڪوڊ سان ٽوڙيا ويندا. ۽ جيئن مون مٿي ڏنل مثال ۾ چيو، جڏهن سينئر ڊولپر ڪوڊ کي ريفڪٽر ڪيو، ٽيسٽ ناڪام نه ٿيا. اهو ئي سبب آهي جو عام منطق تبديل نه ڪيو. اسان ٽيسٽ استعمال ڪندا آهيون اهو ظاهر ڪرڻ لاءِ ته ڇا ڪي خاص ڪارڪردگيءَ جو منطق بدلجي ويو آهي يا نه. پوءِ به جيڪڏهن توهان ٽيسٽ لکڻ پسند نٿا ڪريو، اهي ضرور ڪارآمد آهن ۽ انهن تي خرچ ڪيل وقت جي لائق آهن.

11. گھڻو تبصرو

ڪيترائي ڊولپر تڪميل پسندي کان متاثر آهن، ۽ نوان نوان ڪو به استثنا نه آهن. اهي ڪڏهن ڪڏهن ظاهر ڪن ٿا صرف هڪ پاسو هن جذبي جو جڏهن اهي هر ڪنهن تي تبصرو ڪرڻ شروع ڪن ٿا. جيتوڻيڪ تبصرو ڪرڻ جيڪي غير ضروري آهن، ڇاڪاڻ ته ڪوڊ بلڪل واضح آهي:

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

نه سڀئي نوان پروگرامر فوري طور تي اهو محسوس ڪن ٿا ته تبصرو ڪوڊ هميشه سٺو ناهي، ڇاڪاڻ ته ضرورت کان وڌيڪ تبصرو ڪوڊ کي ڇڪيندا آهن ۽ پڙهڻ ڏکيو بڻائيندا آهن. ۽ ڇا جيڪڏهن ڪوڊ تبديل ٿي وڃي، پر پراڻا رايا اپڊيٽ نه ڪيا ويا آهن؟ پوءِ اھي رڳو اسان کي گمراھ ۽ گمراھ ڪندا. پوءِ آخر اهڙو تبصرو ڇو ڪجي؟ عام طور تي، سٺو لکيل ڪوڊ تبصرو ڪرڻ جي ضرورت ناهي ، ڇاڪاڻ ته ان ۾ هر شيء اڳ ۾ ئي واضح ۽ پڙهڻ جي قابل آهي. جيڪڏهن توهان کي هڪ تبصرو لکڻ جي ضرورت آهي، ته توهان اڳ ۾ ئي ڪوڊ جي پڙهڻ جي صلاحيت کي خراب ڪري ڇڏيو آهي ۽ ڪوشش ڪري رهيا آهيو ڪنهن به صورت ۾ صورتحال کي حل ڪرڻ جي. بهترين طريقو اهو آهي ته لکڻ جي قابل ڪوڊ شروع کان، يعني ڪوڊ جنهن کي تبصرن جي ضرورت نه هجي. مان پڻ مدد نه ٿو ڪري سگهان پر طريقن، متغيرن ۽ طبقن لاءِ صحيح نالو ڏيڻ واري ڪنوينشن جي پيروي ڪرڻ جي ضرورت جو ذڪر ڪري سگهان ٿو. هتي منهنجو قاعدو آهي: بهترين تبصرو يا ته ڪوبه تبصرو يا صحيح نالو نه آهي جيڪو واضح طور تي بيان ڪري ٿو توهان جي ايپليڪيشن ۾ ڪارڪردگي.

12. خراب نالو رکڻ

نوان نوان ڪلاس، متغير، طريقا، وغيره جي نالي ۾ تيز ۽ سست راند ڪندا آهن. مثال طور، هڪ ڪلاس ٺاهڻ جنهن جو نالو ان جي مقصد کي بيان نٿو ڪري. يا اهي هڪ مختصر نالو سان هڪ متغير جو اعلان ڪن ٿا، جهڙوڪ x . اهي جڏهن n ۽ y نالي ٻه وڌيڪ متغير ٺاهيا وڃن ٿا، ته ياد رکڻ ڏاڍو ڏکيو ٿي پوي ٿو ته ڪهڙي x لاءِ ذميوار آهي. هن صورتحال سان منهن ڏيڻ، توهان کي ڪوڊ بابت احتياط سان سوچڻو پوندو، ان کي خوردبيني جي تحت تجزيو ڪرڻ (شايد ڊيبگر استعمال ڪندي)، ڪارڪردگي جو مطالعو ڪرڻ لاء صرف اهو سمجهڻ لاء ڇا ٿي رهيو آهي. اھو اھو آھي جتي صحيح نالو ڏيڻ وارا ڪنوينشن جن جو مون مٿي ذڪر ڪيو آھي اسان جي مدد لاءِ ايندا آھن. صحيح نالا ڪوڊ پڙهڻ جي صلاحيت کي بهتر بڻائي ٿو، اهڙيء طرح ڪوڊ سان پاڻ کي واقف ڪرڻ لاء گهربل وقت گھٽائي ٿو، ڇاڪاڻ ته هڪ طريقو استعمال ڪرڻ تمام آسان آهي جڏهن ان جو نالو تقريبا ان جي ڪارڪردگي کي بيان ڪري ٿو. ڪوڊ ۾ هر شي نالن تي مشتمل آهي (متغير، طريقا، ڪلاس، شيون، فائلون، وغيره)، تنهنڪري اهو نقطو تمام ضروري آهي جڏهن صحيح، صاف ڪوڊ ٺاهي. توهان کي ياد رکڻ گهرجي ته نالو مطلب پهچائڻ گهرجي، مثال طور، متغير ڇو موجود آهي، اهو ڇا ڪندو آهي، ۽ اهو ڪيئن استعمال ڪيو ويندو آهي. مان هڪ کان وڌيڪ ڀيرا نوٽ ڪندس ته هڪ متغير لاءِ بهترين تبصرو اهو آهي ته ان کي سٺو نالو ڏيو. رابرٽ مارٽن پاران ڏنل تبصرن ۽ صحيح نالي جي باري ۾ وڌيڪ گہرا مطالعو ڪرڻ لاءِ، مان پڙهڻ جي صلاح ڏيان ٿو لازوال ڪلاسڪس: ”ڪلين ڪوڊ: اي هينڊ بڪ آف ايجائل سافٽ ويئر ڪرافٽسمينشپ“ . ان نوٽ تي، هن مضمون جو پهريون حصو (منهنجا عڪس) پڄاڻي تي پهتو آهي. جاري رکڻ گهرجي...