نويس پروگرامرز جي عام غلطين جو تجزيو: حصو 1

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

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

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

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

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

3. بلائنڊ ڪاپي پيسٽ

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

4. غلط حل اڇلائڻ

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

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

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

6. ٽيم جي اڳواڻي کان تمام گهڻي اميد رکڻ

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

• ھن پروجيڪٽ جي دستاويزن جو وڌيڪ گہرا اڀياس ڪريو ته جيئن انڌن جي تعداد کي گھٽايو وڃي.
• ٻين ٽيم جي ميمبرن کان سوال پڇو. اهو بلڪل ممڪن آهي ته اهي هن ڪارڪردگيءَ کان واقف هجن جيترو اڳواٽ، يا ان کان به وڌيڪ، ڇاڪاڻ ته گهڻو ڪري انهن مان ڪنهن هڪ ان ڪارڪردگيءَ کي لکيو آهي.

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

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

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

8. حل ڪرڻ جو رجحان

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

9. سائيڪل جي ايجاد

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

10. ٽيسٽ نه لکو

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

11. گھڻو تبصرو

ڪيترائي ڊولپر تڪميلزم کان متاثر آهن، ۽ شروعات ڪندڙ ڪو به استثنا نه آهن. پر ڪڏهن ڪڏهن ان خواهش جو هڪ طرفو اثر اهو ٿيندو آهي ته هو هر ڪنهن ۽ هر شيءِ تي تبصرا ڪرڻ لڳندا آهن. جيتوڻيڪ ڇا گهربل نه آهي، ڇاڪاڻ ته اهو بلڪل واضح آهي:

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

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

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

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