کسی پروجیکٹ پر جاوا ڈویلپر کے مخصوص کام

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

1. نئے حل کی ترقی

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

2. نئی فعالیت لکھنا

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

3. فعالیت کے لیے تحریری ٹیسٹ

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

4. بگ کو ڈھونڈنا اور ٹھیک کرنا

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

5. کوڈ کا جائزہ

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

6. کوڈ کا تجزیہ

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

7. کوڈ ری فیکٹرنگ

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

8. تحریری دستاویزات

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

9. مختلف ریلیوں میں شرکت

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

10. انٹرویو کرنا/ پاس کرنا

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