جاوا ڊولپر جا عام ڪم هڪ پروجيڪٽ تي

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

1. نئين حل جي ڊيزائن

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

2. نئين ڪارڪردگي لکڻ

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

3. لکڻ جا امتحان

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

4. ڪيچ ڳولڻ ۽ درست ڪرڻ

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

5. ڪوڊ جو جائزو

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

6. ڪوڊ تجزيو

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

7. ريفيڪٽرنگ ڪوڊ

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

8. دستاويز لکڻ

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

9. مختلف ملاقاتون

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

10. انٽرويو وٺڻ/ پاس ڪرڻ

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