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

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

1. نئين حل جي ترقي

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

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

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

3. ڪارڪردگي لاء ٽيسٽ لکڻ

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

4. بگ ڳولڻ ۽ درست ڪرڻ

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

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

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

6. ڪوڊ تجزيو

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

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

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

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

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

9. مختلف ريلين ۾ شرڪت

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

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

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