جونیئر ڈویلپرز کی غلطیاں
ایسا کوڈ فراہم کرنا جو کام کرے، یہ ایک بنیادی معیار ہے۔ یہ مقصد نہیں ہے۔
میں نے ایک بار ایک ایسا pull request ریویو کیا جسے سمجھنے میں 45 منٹ لگے۔ لاجک درست تھی۔ ٹیسٹ پاس ہو گئے تھے۔ لیکن کوڈ اس طرح لکھا گیا تھا جیسے اسے صرف لکھنے والا ہی پڑھے گا۔
جب میں نے فیڈ بیک دیا، تو ڈویلپر نے کہا، "لیکن یہ کام تو کر رہا ہے۔"
وہ درست تھے۔ یہ کام کر رہا تھا۔ مسئلہ بالکل یہی تھا۔
جونیئر ڈویلپرز اکثر تکنیکی مہارتوں پر توجہ دیتے ہیں۔ لیکن اصل کمی اکثر عادات اور سوچ (mindset) میں ہوتی ہے۔
یہاں وہ باریک غلطیاں ہیں جو آپ کی رفتار کم کر دیتی ہیں:
دوسروں کے بجائے اپنے لیے لکھنا کوڈ لکھنے کے مقابلے میں اسے پڑھا بہت زیادہ جاتا ہے۔ آج آپ جو فنکشن لکھتے ہیں، دو سالوں میں اسے تین مختلف لوگ استعمال کر سکتے ہیں۔ اگر کوئی اجنبی آپ کے کوڈ کو 30 سیکنڈ میں نہیں سمجھ سکتا، تو آپ ناکام ہو گئے۔
کوڈ کو سمجھے بغیر کاپی کرنا Stack Overflow کا استعمال کرنا ٹھیک ہے۔ لیکن یہ جانے بغیر کہ ایک regex pattern کیسے کام کرتا ہے، اسے کاپی کرنا خطرناک ہے۔ آپ اپنے codebase میں ایک 'black box' بنا دیتے ہیں۔ جب یہ خراب ہوگا تو آپ اسے debug نہیں کر سکیں گے۔
غیر ضروری پیچیدگی کا اضافہ کرنا جونیئرز اکثر پیچیدگی کو مہارت سمجھ لیتے ہیں۔ وہ سادہ کاموں پر بھی design patterns لاگو کر دیتے ہیں۔ غیر ضروری abstraction کوڈ کو debug کرنا اور تبدیل کرنا مشکل بنا دیتی ہے۔ abstraction صرف تب شامل کریں جب آپ اس کی کمی محسوس کریں۔
Error messages کو نظر انداز کرنا Error messages مفت دستاویزات (documentation) کی طرح ہوتے ہیں۔ جیسے ہی آپ stack trace دیکھیں، فوراً Google کی طرف نہ بھاگیں۔ پورا میسج پڑھیں۔ یہ اکثر آپ کو بالکل درست بتاتا ہے کہ کون سی لائن فیل ہوئی اور کیوں۔
بہت جلدی یا بہت دیر سے مدد مانگنا 10 منٹ کے مسئلے پر تین گھنٹے ضائع نہ کریں۔ یہ غیر موثر ہے۔ لیکن کسی senior کو صرف ایک اسکرین شاٹ بھیج کر اور بغیر کسی context کے میسج نہ کریں۔ 20 منٹ کا اصول اپنائیں: اسے حل کرنے کی کوشش میں 20 منٹ لگائیں۔ جو کچھ آپ نے کوشش کی اسے لکھ لیں۔ پھر اس دستاویز کے ساتھ مدد مانگیں۔
وہ چیز دوبارہ بنانا جو پہلے سے موجود ہے کوئی نئی utility لکھنے سے پہلے، codebase میں تلاش کریں۔ آپ کی ٹیم غالباً اس مسئلے کو پہلے ہی حل کر چکی ہوگی۔
ناقص commit messages "fix bug" جیسا commit message آپ کی ٹیم کو کچھ نہیں بتاتا۔ وضاحت کریں کہ کیا بدلا اور کیوں۔ Git history کو documentation کے طور پر استعمال کریں۔
Requirements کو قانون سمجھنا Requirements میں اکثر edge cases رہ جاتے ہیں۔ صرف وہی نہ کریں جو آپ کو بتایا گیا ہے۔ پوچھیں کہ اگر چیزیں غلط ہو گئیں تو کیا ہوگا۔
"Merged" بٹن پر رک جانا جب آپ کا PR merge ہو جائے تو ذمہ داری ختم نہیں ہوتی۔ اپنے فیچر کا QA تک پیچھا کریں۔ اسے production میں دیکھیں۔ error reports پڑھیں۔
سب سے بڑا فرق جوابدہی (accountability) کا ہے۔ Senior ڈویلپرز صرف کوڈ نہیں لکھتے۔ وہ نئے مسائل پیدا کیے بغیر مسائل حل کرتے ہیں۔
"کام مکمل" کرنے کے بجائے "بہترین کام" کرنے پر توجہ دیں۔